MySQL 샤딩 및 MySQL 클러스터

성능 만 고려 하면 MySQL 클러스터가 맞춤형 데이터 샤딩 MySQL 솔루션을 능가 할 수 있습니까? 샤딩 = 수평 파티셔닝

샤딩을 언급 할 때, 애플리케이션 계층에서 만들어진 샤딩을 고려하고 있습니다. 예를 들어 독립 MySQL 인스턴스에 레코드를 고르게 분배하는 것입니다. 두 서버의 경우 (key mod 2) 일 수 있습니다.

공개 : 저는 MySQL 클러스터에서 일하는 MySQL 직원입니다.

MySQL 클러스터는 샤드 MySQL + InnoDB보다 높은 처리량 / 호스트를 달성 할 수 있다고 말합니다.

• 쿼리는 간단합니다
• 모든 데이터는 인 메모리에 적합

지연 시간 측면에서 MySQL 클러스터는 샤딩 된 MySQL보다 지연 시간이 더 안정적이어야합니다. 순수한 인 메모리 데이터의 실제 대기 시간은 비슷할 수 있습니다.

쿼리가 더욱 복잡해지고 데이터가 디스크에 저장되면 성능 비교가 더욱 혼란스러워집니다. 보다 구체적인 답변을 얻으려면 호스트 수와 데이터 양뿐만 아니라 응용 프로그램 및 수행하는 쿼리에 대해 더 자세히 설명해야합니다. MySQL 클러스터는 최근 병렬 로컬 라이즈 된 쿼리 실행 (AQL)을 얻었으며 이는 여러 호스트에 데이터를 분산 시켜도 독립형 MySQLD와 경쟁 할 수 있음을 의미합니다.

MySQL 클러스터는 현재 48 개 이상의 호스트에 대한 '샤딩'으로 제한됩니다. 이론상 Sharded MySQL에는 제한이 없습니다. 그러나 주어진 대상 처리량에 대해 샤드 MySQL 호스트보다 적은 수의 MySQL 클러스터 호스트가 필요할 수 있습니다.

더 흥미로운 차이점은 성능 이외의 영역을 볼 때입니다.

• MySQL 클러스터는 모든 샤드에서 임의의 쿼리를 지원합니다
• MySQL 클러스터는 모든 샤드에서 임의의 트랜잭션을 지원합니다
• MySQL 클러스터는 자동 장애 조치 및 복구로 샤드의 동기식 복제를 지원합니다
• MySQL 클러스터는 온라인 추가 노드 (클러스터 확장)를 지원합니다
• Sharded MySQL은 더 '자신의 롤'입니다

응용 프로그램에 샤딩을 내장하면 확장 가능성이 극대화되지만 샤드 쿼리 및 작업 측면에서 복잡성이 추가되고 유연성이 제한됩니다. 샤딩이 너무 이른 경우 문제의 원인 일 수 있습니다. MySQL Cluster를 사용하면 애플리케이션을 단일 샤드 전용으로 제한하지 않고도 샤딩의 이점을 얻을 수 있습니다.

이전 답변과 관련하여 몇 가지 설명이 있습니다.

"MySQL Cluster는 ACID를 준수하지만 복합 키가있는 데이터에 적합한 스토리지 엔진을 제공하지는 않습니다."

MySQL Cluster는 복합 기본 및 보조 키를 지원합니다. '적합하지 않은'것이 무엇인지 확실하지 않습니다. 아마도 이전 포스터가 설명 할 수 있습니까?

"특정 데이터 노드 세트에 동일한 키 특성을 가진 데이터를 저장하려면 다음을 수행 할 수 있습니다.

1. 모든 데이터 노드를 오프라인으로 전환하여 동일한 키 특성을 가진 데이터를 저장하려는 데이터 노드 만 남겨 둡니다.
2. 선택한 데이터 노드 만 채우는 MySQL 클러스터에 데이터를로드합니다.
3. 모든 데이터 노드를 다시 온라인 상태로 전환 "

이것은 올바르지 않습니다. 데이터 분배는 언제든지 어떤 노드가 온라인 상태가되는지에 관계없이 독립적입니다. MySQL Cluster는 설명하는 최적화를 지원하기 위해 다양한 데이터 배포 체계를 지원합니다. 블로그 게시물에서 MySQL 클러스터의 데이터 배포에 대해 설명합니다 .MySQL Cluster의 데이터 배포