MySQL 클러스터(NDB) 대 MySQL 복제(InnoDB) for Rails 3 앱: 찬성/반대?

MySQL 클러스터(NDB) 대 MySQL 복제(InnoDB) for Rails 3 앱: 찬성/반대?

성능과 신뢰성을 개선할 수 있는지 확인하기 위해 현재 시스템에 대한 개요를 설명하고 있습니다.

현재 우리는 수많은 내부 Rails 앱과 Rails 기반 웹사이트를 운영하고 있습니다.일부는 이미 레일 3이고 일부는 레일 3으로 변환 중입니다.모두 다음 MySQL 설정에 연결됩니다.

mysql01 ( master server) => mysql02 (slave)=> (드라이브에 매일, 매주, 매월, 반기별로 DB 백업).

모든 쓰기 작업은 mysql01에서 이루어지며 대부분의 짧은 읽기 작업도 mysql01로 이동합니다. 일부 "더 많은 리소스를 소비하는 읽기 작업"(예: 데이터를 실행하고 csv 또는 백업에 덤프하는 데 3-10분 소요되는 월별/주별 보고서)은 mysql02 서버로 이동합니다.우리는 하루에 약 3-5,000건의 방문을 받고 있으며, 재고, 주문 처리 등을 위해 매일 다양한 앱을 사용하는 약 20-30명의 내부 사용자가 있습니다.따라서 이러한 서버는 슬레이브에서 실행되는 보고서 외에는 특별히 무거운 부하를 받지 않습니다.

모든 서버는 다음에서 실행됩니다.virtualized XENVM의 . VM의 풀입니다.

그래서 우리는 시스템을 검토하고 있고, 누군가는 다음으로 전환하자는 제안을 했습니다.MySQL Cluster (NDB)이론적으로는 알고 있지만 실제로 실행해 본 적은 없습니다.그렇다면 현재 설정과 비교하여 찬성/반대되는 점, 그리고 Ruby/Rails 애플리케이션과 관련된 특정 주의 사항에 대해 알고 있는 사람이 있습니까?

최근 문서에 게시된 InnoDB와 MySQL 클러스터(ndb)를 잘 비교하고 있습니다...볼 가치가 있습니다: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

클러스터 아키텍처는 애플리케이션에서 액세스하는 MySQL 서버 풀로 구성됩니다. 이러한 MySQL 서버는 실제로 클러스터 데이터를 저장하지 않으며 데이터는 아래의 데이터 노드 풀을 통해 분할됩니다.모든 MySQL 서버는 모든 데이터 노드의 데이터에 액세스할 수 있습니다.하나의 MySQL 서버가 데이터를 변경하면 다른 모든 MySQL 서버에 즉시 표시됩니다.

이 아키텍처를 통해 데이터베이스를 매우 쉽게 확장할 수 있습니다.샤딩과 달리 애플리케이션은 데이터가 저장된 위치를 알 필요가 없으며 사용 가능한 모든 MySQL 서버 간에 로드 밸런싱만 수행할 수 있습니다.MySQL 복제 클러스터를 사용하여 스케일아웃하는 것과 달리, 클러스터를 사용하면 읽기뿐만 아니라 쓰기도 스케일아웃할 수 있습니다.애플리케이션에 대한 서비스 손실 없이 새 데이터 노드 또는 MySQL 서버를 기존 클러스터에 추가할 수 있습니다.

MySQL 클러스터의 공유 없음 아키텍처는 매우 높은 가용성(99.999% 이상)을 제공할 수 있음을 의미합니다.데이터를 변경할 때마다 두 번째 데이터 노드로 동기화되어 복제됩니다. 한 데이터 노드에서 장애가 발생하면 백업 데이터 노드에서 애플리케이션 읽기 및 쓰기 요청을 자동으로 처리합니다.

MySQL 클러스터의 분산된 특성으로 인해 일부 작업(예: 수천 개의 중간 결과를 가진 JOIN)은 속도가 느릴 수 있지만, 다른 작업은 매우 빠르고 확장성이 뛰어날 수 있습니다(예: 기본 키 읽기 및 쓰기).테이블(또는 열)을 메모리 또는 디스크에 저장할 수 있는 옵션이 있으며, 메모리 옵션(백그라운드에서 디스크에 대한 변경 사항 확인)을 선택하면 트랜잭션이 매우 빠르게 수행될 수 있습니다.

MySQL 클러스터는 단일 MySQL 서버보다 설정이 복잡할 수 있지만 애플리케이션에서 샤딩 또는 읽기/쓰기 분할을 구현해야 하는 것을 방지할 수 있습니다.스윙과 라운드 어라운드.

MySQL 클러스터의 성능과 확장성을 극대화하려면 애플리케이션을 조정해야 합니다(클러스터 성능 조정 백서: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php) 참조).응용프로그램을 소유하고 있다면 일반적으로 큰 문제가 되지 않지만 수정할 수 없는 다른 사용자의 응용프로그램을 사용하는 경우 문제가 발생할 수 있습니다.

마지막으로, 일부 테이블은 클러스터에 저장하고 일부 테이블은 다른 스토리지 엔진을 사용하도록 선택할 수 있습니다. 이 옵션은 테이블별 옵션입니다.또한 클러스터와 다른 스토리지 엔진 간에 복제할 수 있습니다(예: 런타임 데이터베이스에 클러스터를 사용한 다음 InnoDB로 복제하여 복잡한 보고서를 생성).

언급URL : https://stackoverflow.com/questions/5300490/mysql-cluster-ndb-vs-mysql-replication-innodb-for-rails-3-apps-pros-cons