데이터 집약적 애플리케이션 설계

6장. 파티셔닝

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

분명한 것은 순차적인 방식에서 벗어나 컴퓨터를 제한하지 않아야 한다는 것입니다. 정의를 명시하고 데이터의 우선순위와 설명을 제공해야 합니다. 절차가 아닌 관계를 명시해야 합니다.

그레이스 머레이 호퍼, 경영과 미래의 컴퓨터 (1962)

5장에서는 복제, 즉 서로 다른 노드에 동일한 데이터의 복사본을 여러 개 두는 것에 대해 설명했습니다. 매우 큰 데이터 세트 또는 매우 높은 쿼리 처리량의 경우, 이것만으로는 충분하지 않습니다. 데이터를 파티션으로 분할하는샤딩이라고도 하는 방법이 필요합니다.ⁱ

용어 혼동

여기서 파티션이라고 부르는 것은 MongoDB, Elasticsearch, SolrCloud에서는 샤드라고 하며, HBase에서는리전, Bigtable에서는 태블릿, Cassandra와 Riak에서는 vnode, Couchbase에서는 vBucket으로 알려져 있습니다. 그러나 파티셔닝이 가장 널리 알려진 용어이므로 이 용어를 그대로 사용하겠습니다.

일반적으로 파티션은 각 데이터 조각(각 레코드, 행 또는 문서)이 정확히 하나의 파티션에 속하는 방식으로 정의됩니다. 이를 달성하는 방법에는 여러 가지가 있으며, 이 장에서 자세히 설명합니다. 데이터베이스가 동시에 여러 파티션에 영향을 미치는 작업을 지원할 수도 있지만 사실상 각 파티션은 자체적으로 작은 데이터베이스입니다.

데이터를 파티션하려는 주된 이유는 확장성 때문입니다. 공유 없음 클러스터의 여러 노드에 서로 다른 파티션을 배치할 수 있습니다( 공유 없음의 정의는 2부의소개를 참조하세요). 따라서 대규모 데이터 세트를 여러 디스크에 분산할 수 있으며 쿼리 부하를 여러 프로세서에 분산할 수 있습니다.

단일 파티션에서 작동하는 쿼리의 경우, 각 노드는 자체 파티션에 대한 쿼리를 독립적으로 실행할 수 있으므로 노드를 더 추가하여 쿼리 처리량을 확장할 수 있습니다. 크고 복잡한 쿼리는 여러 노드에서 병렬화할 수 있지만, 이는 훨씬 더 어려워집니다.

파티셔닝된 데이터베이스는 1980년대에 Teradata 및 Tandem NonStop SQL [1] 같은 제품에 의해 개척되었으며, 최근에는 NoSQL 데이터베이스와 Hadoop 기반 데이터 웨어하우스에 의해 재발견되었습니다. 일부 시스템은 트랜잭션 워크로드용으로, 다른 시스템은 분석용으로 설계되었습니다( "트랜잭션 처리 또는 분석?" 참조). 이러한 차이는 시스템 조정 방법에 영향을 미치지만 파티셔닝의 기본은 두 종류의 워크로드 모두에 적용됩니다.

이 장에서는 먼저 대규모 데이터 세트를 분할하는 다양한 접근 방식을 살펴보고 데이터 인덱싱이 분할과 어떻게 상호 작용하는지 관찰합니다. 그런 다음 클러스터에서 ...