거대한 컬렉션이 있으면 데이터베이스 샤딩이 훌륭해 보입니다. 적당한 크기의 컬렉션이 많이 있다면 어떻게해야합니까? 1 억 개의 문서 (큰 주석은 아님)의 1 모음에 대해 샤딩이 효과적이라고 가정 해 봅시다. 또한 10,000 개의 문서가 각각있는 10,000 개의 컬렉션에도 효과적입니까?
(이 질문은 컬렉션을 테이블로 바꾸고 문서를 행으로 바꾸면 테이블 지향 데이터베이스에 여전히 유효하다고 생각합니다. 가능하면 이론적 대답과 특정 MongoDB 시나리오의 대답을 알고 싶습니다. 대답.)
답변:
또한 10,000 개의 문서가 각각있는 10,000 개의 컬렉션에도 효과적입니까?
대부분의 사람들은 "단일 대규모 수집"문제가 있으므로 샤딩은이 데이터의 균형을 맞추는 데 도움이되는 두통을 줄이는 데 분명히 유용합니다.
그러나 10 000 개의 작은 모음이 있으면 두통이 "데이터 균형 조정"이 아닐 수 있습니다. 이 작은 컬렉션을 사용하면 이러한 컬렉션을 추적하는 데 문제가있을 수 있습니다. 문서 크기에 따라 샤딩의 실제 하한값을 초과하지 않을 수도 있습니다.
매우 작은 컬렉션의 경우 거의 알려진 movePrimary 명령 을 사용하여 데이터 위치를 관리 할 수 있습니다.
물론 이것을 보는 다른 방법은 왜 10k 모음이 있습니까? 컬렉션에는 동종 개체가 필요하지 않으며 10k 컬렉션으로 대부분의 개체를 생성해야합니다. 동일한 콜렉션에 서로 다른 "유형"의 데이터를 저장하고 콜렉션 수를 줄인 다음 샤드 키의 일부로 유형을 포함 할 수 있습니다.
foo와 bar동일한 데이터 구조, 당신은로 병합 할 수 있습니다 baz수집 및 오버라이드 _ids(코드) : { _id: "foo123" }, { _id: "bar123" }. 색인이 더 크지 만 유형을 포함하는 색인이 하나만 있습니다. 요구 사항이 아니라 단지 "생각을위한 음식".
MongoDB 샤딩은 컬렉션을 더 작은 '청크'로 나누고 여러 머신에서 고르게 분배하여 작동합니다. 일반적으로 가장 효율적인 기본 청크 크기는 200MB입니다. 따라서 컬렉션이 200MB보다 크게 커지지 않으면 청크로 분할되지 않으므로 샤딩에 적합하지 않으므로 이점이 없습니다.
일반적으로 여러 시스템의 데이터 샤딩은 읽기, 쓰기 및 쿼리를 확장하는 매우 효과적인 방법입니다. 여러 CPU, 하드 디스크 및 메모리 스토리지의 이점을 활용하여 데이터를 읽고 쓰고 처리하기 위해 병렬로 작업합니다. 메모리 확장은 특히 메모리의 데이터 피팅에 매우 민감한 고성능 MongoDB에 중요합니다.