Azure Cosmos DB는 분할을 사용하여 애플리케이션의 성능 요구 사항을 충족하기 위해 데이터베이스의 컨테이너 크기를 조정합니다. 컨테이너의 항목은 논리 파티션이라는 별개의 하위 집합으로 나뉩니다. 논리 파티션은 컨테이너의 각 항목과 연결된 파티션 키 의 값을 기반으로 형성됩니다. 논리 파티션의 모든 항목은 동일한 파티션 키 값을 갖습니다.
예를 들어 컨테이너는 항목을 포함합니다. 각 항목에는 UserID 속성에 대한 고유한 값이 있습니다.
UserID가 컨테이너에 있는 항목의 파티션 키 역할을 하고 1,000개의 고유한 UserID 값이 있다면 컨테이너에 대해 1,000개의 논리 파티션이 생성됩니다.
컨테이너의 각 항목에는 논리 파티션을 결정하는 파티션 키 와 해당 파티션 내에서 고유한 항목 ID 가 있습니다. 파티션 키와 항목 ID를 결합하면 항목의 인덱스가 생성되며 이를 통해 항목을 고유하게 식별할 수 있습니다. 파티션 키를 선택하는 것은 애플리케이션 성능에 영향을 주는 중요한 결정입니다.
이 문서에서는 논리 파티션과 실제 파티션 간의 관계를 설명하고, 분할에 대한 모범 사례를 설명하고, Azure Cosmos DB에서 수평 크기 조정이 작동하는 방식을 자세히 설명합니다. 파티션 키를 선택하기 위해 이러한 내부 세부 정보를 이해할 필요는 없지만 이 문서에서는 Azure Cosmos DB의 작동 방식을 명확히 설명합니다.
논리 파티션
논리 파티션은 동일한 파티션 키를 공유하는 항목 집합입니다. 예를 들어 식품 영양에 대한 데이터가 포함된 컨테이너의 모든 항목에는 foodGroup 속성이 포함됩니다. 컨테이너의 파티션 키로 사용합니다 foodGroup .
foodGroup에 대해 Beef Products, Baked Products 및 Sausages and Luncheon Meats 등의 특정 값을 갖는 항목 그룹은 고유한 논리 파티션을 형성합니다.
또한 논리 파티션은 데이터베이스 트랜잭션의 범위를 정의합니다. 스냅샷 격리가 있는 트랜잭션을 사용하여 논리 파티션 내의 항목을 업데이트할 수 있습니다. 컨테이너에 새 항목이 추가되면 시스템에서 새 논리 파티션이 투명하게 만들어집니다. 기본 데이터를 삭제하는 경우 논리 파티션 삭제에 대해 걱정할 필요는 없습니다.
컨테이너의 논리 파티션 수에는 제한이 없습니다. 각 논리적 파티션에는 최대 20GB의 데이터를 저장할 수 있습니다. 유효 파티션 키에는 다양한 가능한 값이 있습니다. 예를 들어 모든 항목에 foodGroup 속성이 포함된 컨테이너에서 Beef Products 논리 파티션 내의 데이터는 최대 20GB까지 증가할 수 있습니다. 다양한 값을 사용할 수 있는 파티션 키를 선택하면 컨테이너 크기를 조정할 수 있습니다.
Azure Monitor 경고를 사용하여 논리 파티션의 크기가 20GB에 근접하는지 모니터링합니다.
실제 파티션
컨테이너는 실제 파티션에 데이터 및 처리량을 분산하여 확장됩니다. 내부적으로 하나 이상의 논리 파티션이 단일 실제 파티션에 매핑됩니다. 일반적으로 작은 컨테이너에는 논리 파티션이 많지만 단일 실제 파티션만 필요합니다. 논리 파티션과 달리 실제 파티션은 내부 시스템 구현이며 Azure Cosmos DB는 이를 완전히 관리합니다.
컨테이너의 실제 파티션 수는 다음과 같은 특성에 따라 달라집니다.
프로비전된 처리량(각 개별 실제 파티션은 초당 최대 10,000개의 요청 단위의 처리량을 제공할 수 있습니다). 실제 파티션에 대한 10,000RU/s 제한은 각 논리 파티션이 하나의 실제 파티션에만 매핑되므로 논리 파티션에도 10,000RU/s 제한이 있음을 의미합니다.
총 데이터 스토리지(각 개별 실제 파티션은 최대 50GB의 데이터를 저장할 수 있습니다).
참고 항목
물리적 파티션은 Azure Cosmos DB에서 완전히 관리되는 내부 시스템 구현입니다. 솔루션을 개발할 때는 실제 파티션을 제어할 수 없으므로 실제 파티션에 집중하지 않도록 하세요. 대신 파티션 키에 집중합니다. 논리 파티션 간에 처리량 소비를 균등하게 분산하는 파티션 키를 선택하면 실제 파티션 간에 분산된 처리량 소비가 보장됩니다.
컨테이너의 총 실제 파티션 수에는 제한이 없습니다. 프로비전된 처리량 또는 데이터 크기가 증가하면 Azure Cosmos DB는 자동으로 기존 파티션을 분할하여 새 물리적 파티션을 만듭니다. 물리적 파티션 분할은 애플리케이션의 가용성에 영향을 주지 않습니다. 실제 파티션이 분할된 후에도 단일 논리 파티션 내의 모든 데이터는 여전히 동일한 실제 파티션에 저장되어 있습니다. 실제 파티션을 분할하면 단순히 실제 파티션에 대한 논리 파티션의 새로운 매핑이 생성됩니다.
컨테이너에 대해 프로비전된 처리량은 실제 파티션 간에 균등하게 나눕니다. 요청을 균등하게 분산하지 않는 파티션 키 디자인으로 인해 너무 많은 요청이 "핫"이 되는 파티션의 작은 하위 집합으로 전송될 수 있습니다. 핫 파티션은 프로비전된 처리량을 비효율적으로 사용하게 하므로 속도 제한 및 비용이 높아질 수 있습니다.
예를 들어 파티션 키로 경로 /foodGroup이 지정된 컨테이너를 생각해 보겠습니다. 컨테이너에 원하는 수의 물리적 파티션을 포함할 수 있지만 이 예제에서는 세 개의 파티션이 있다고 가정합니다. 하나의 물리적 파티션에 여러 개의 파티션 키가 포함될 수 있습니다. 예를 들어, 가장 큰 물리적 파티션은 크기를 기준으로 상위 3개의 논리적 파티션(Beef Products, Vegetable and Vegetable Products 및 Soups, Sauces, and Gravies)을 포함할 수 있습니다.
초당 18,000개 요청 단위(RU/s)의 처리량을 할당하는 경우 세 개의 실제 파티션 각각은 프로비전된 총 처리량의 3분의 1을 사용합니다. 선택한 실제 파티션 내에서 논리 파티션 키, Beef Products, Vegetable and Vegetable Products 및 Soups, Sauces, and Gravies는 전체적으로 실제 파티션의 초당 6,000개의 프로비전된 RU를 활용할 수 있습니다. 프로비전된 처리량은 컨테이너의 물리적 파티션 간에 균등하게 분할되므로 소비되는 처리량을 균등하게 분산하는 파티션 키를 선택하는 것이 중요합니다. 자세한 내용은 올바른 논리 파티션 키 선택을 참조하세요.
논리 파티션 관리
Azure Cosmos DB는 컨테이너의 확장성 및 성능 요구 사항을 충족하기 위해 물리적 파티션에 논리 파티션의 배치를 자동으로 관리합니다. 애플리케이션의 처리량 및 스토리지 요구 사항이 증가하면 Azure Cosmos DB는 논리 파티션을 이동하여 더 많은 실제 파티션에 부하를 분산합니다. 실제 파티션에 대해 자세히 알아봅니다.
Azure Cosmos DB는 해시 기반 분할을 사용하여 물리적 파티션에 논리 파티션을 분산합니다. Azure Cosmos DB는 항목의 파티션 키 값을 해시합니다. 해시된 결과에 따라 논리 파티션이 결정됩니다. 그런 다음, Azure Cosmos DB는 실제 파티션에 걸쳐 균등하게 파티션 키 해시의 주요 공간을 할당합니다.
저장 프로시저 또는 트리거의 트랜잭션은 단일 논리 파티션의 항목에 대해서만 허용됩니다.
복제본 세트
각 물리적 파티션은 복제본 집합이라고도 하는 복제본 집합으로 구성됩니다. 각 복제본은 데이터베이스 엔진의 인스턴스를 호스팅합니다. 복제본 세트는 물리적 파티션 내의 데이터 저장소를 내구성과 가용성이 높고 일관되게 만듭니다. 실제 파티션의 각 복제본은 파티션의 스토리지 할당량을 상속합니다. 실제 파티션의 모든 복제본은 해당 실제 파티션에 할당된 처리량을 전체적으로 지원합니다. Azure Cosmos DB는 복제본 세트를 자동으로 관리합니다.
컨테이너가 작을수록 일반적으로 단일 실제 파티션이 필요하지만 복제본이 4개 이상 있습니다.
이 이미지는 논리 파티션이 전역적으로 분산된 실제 파티션에 매핑되는 방법을 보여 줍니다. 이미지의 파티션 세트는 여러 지역에서 동일한 논리 파티션 키를 관리하는 실제 파티션 그룹을 나타냅니다.
파티션 키 선택
파티션 키에는 파티션 키 경로와 파티션 키 값의 두 가지 구성 요소가 있습니다. 예를 들어 { "userId" : "Andrew", "worksFor": "Microsoft" } 항목이 있는데 파티션 키로 "userId"를 선택하면 다음과 같은 두 가지 파티션 키 구성 요소가 있습니다.
파티션 키 경로(예: "/userId"). 파티션 키 경로에는 영숫자 및 밑줄(_) 문자가 허용됩니다. 또한 표준 경로 표기법(/)을 사용하면 중첩된 개체를 사용할 수도 있습니다.
파티션 키 값(예: "Andrew"). 파티션 키 값은 문자열 또는 숫자 형식일 수 있습니다.
Azure Cosmos DB 서비스 할당량 문서의 처리량, 스토리지 및 파티션 키 길이 제한에 대해 알아봅니다.
Azure Cosmos DB에서 파티션 키를 선택하는 것은 간단하지만 중요한 디자인 선택 사항입니다. 파티션 키를 선택하면 현재 위치에서 변경할 수 없습니다. 파티션 키를 변경해야 하는 경우 원하는 파티션 키를 사용하여 데이터를 새 컨테이너로 이동합니다. (컨테이너 복사 작업은 이 프로세스에 도움이 됩니다.)
모든 컨테이너의 경우 파티션 키는 다음을 수행해야 합니다.
값이 변경되지 않는 속성이어야 합니다. 속성이 파티션 키인 경우 해당 속성의 값을 업데이트할 수 없습니다.
String에 따르면 값만String포함하거나 숫자를 이중 정밀도 숫자의 경계를 초과할 수 있는 경우 숫자로 변환합니다. Json 사양은 상호 운용성 문제로 인해 이 경계 외부의 숫자를 사용하는 것이 잘못된 사례인 이유를 설명합니다. 이러한 문제는 변경할 수 없으며 나중에 변경하려면 데이터 마이그레이션이 필요하기 때문에 파티션 키 열과 특히 관련이 있습니다.카디널리티가 높습니다. 즉, 속성에는 다양한 값을 사용할 수 있어야 합니다.
모든 논리 파티션에 RU(요청 단위) 사용량과 데이터 스토리지를 균등하게 분산합니다. 이 분산을 통해 실제 파티션에서 균등한 RU 사용량과 스토리지 배포가 가능합니다.
값은 일반적으로 2048바이트 이하이거나 큰 파티션 키가 사용되지 않은 경우 101바이트입니다. 자세한 내용은 큰 파티션 키를 참조하세요.
Azure Cosmos DB에서 다중 항목 ACID 트랜잭션이 필요한 경우에는 저장 프로시저 또는 트리거를 사용해야 합니다. 모든 JavaScript 기반 저장 프로시저와 트리거는 단일 논리 파티션으로 범위가 한정됩니다.
참고 항목
실제 파티션이 하나만 있는 경우 모든 쿼리가 동일한 실제 파티션을 대상으로 하므로 파티션 키 값이 관련이 없을 수 있습니다.
파티션 키 유형
| 분할 전략 | 사용 시기 | 장점 | 단점 |
|---|---|---|---|
| 일반 파티션 키 (예: CustomerId, OrderId) | 파티션 키의 카디널리티가 높고 쿼리 패턴(예: CustomerId별 필터링)과 일치하는 경우에 사용합니다. 쿼리가 주로 단일 고객의 데이터를 대상으로 하는 워크로드에 적합합니다(예: 고객에 대한 모든 주문 검색). | 관리가 간단합니다. 액세스 패턴이 파티션 키와 일치하는 경우 효율적인 쿼리(예: CustomerId별 모든 주문 쿼리). 액세스 패턴이 일관된 경우 파티션 간 쿼리를 방지합니다. | 트래픽이 많은 일부 값(예: 트래픽이 많은 고객)이 다른 값보다 더 많은 데이터를 생성하는 경우 핫 파티션의 위험이 있습니다. 특정 키의 데이터 볼륨이 빠르게 증가하는 경우 논리 파티션당 20GB 제한에 도달할 수 있습니다. |
| 가상 파티션 키 (예: CustomerId + OrderDate) | 카디널리티가 높고 쿼리 패턴과 일치하는 단일 필드가 없는 경우에 사용합니다. 데이터가 실제 파티션에 균등하게 분산되어야 하는 쓰기가 많은 워크로드에 적합합니다(예: 동일한 날짜에 배치된 많은 주문). | 파티션 간에 데이터를 균등하게 분산하여 핫 파티션을 줄입니다(예: CustomerId 및 OrderDate의 주문 분산). 여러 파티션에 쓰기를 분산하고 처리량을 향상시킵니다. | 한 필드(예: CustomerId만)로만 필터링하는 쿼리는 파티션 간 쿼리를 생성할 수 있습니다. 파티션 간 쿼리는 더 높은 RU 사용(존재하는 모든 실제 파티션에 대해 2-3RU/초의 추가 요금)을 발생시키고 대기 시간을 추가할 수 있습니다. |
| HPK(계층적 파티션 키) (예: CustomerId/OrderId, StoreId/ProductId) | 대규모 데이터 세트를 지원하기 위해 다단계 분할이 필요한 경우에 사용합니다. 쿼리가 계층 구조의 첫 번째 수준과 두 번째 수준을 필터링하는 경우에 이상적입니다. | 여러 수준의 분할을 만들어 20GB 제한을 방지할 수 있습니다. 계층 수준 모두에서 효율적인 쿼리(예: CustomerID별 필터링, OrderID별 필터링) 최상위 수준을 대상으로 하는 쿼리에 대한 파티션 간 쿼리를 최소화합니다(예: 특정 CustomerID에서 모든 데이터 검색). | 첫 번째 수준 키의 카디널리티가 높고 대부분의 쿼리에 포함되도록 신중하게 계획해야 합니다. 일반 파티션 키보다 관리가 더 복잡합니다. 쿼리가 계층 구조에 맞지 않는 경우(예: CustomerID가 첫 번째 수준인 경우 OrderID로만 필터링) 쿼리 성능이 저하될 수 있습니다. |
읽기 작업이 많은 컨테이너에 대한 파티션 키
대부분의 컨테이너에서 이러한 조건은 파티션 키를 선택할 때 고려해야 할 사항입니다. 그러나 읽기 작업이 많은 컨테이너의 경우 쿼리에 필터로 자주 나타나는 파티션 키를 선택하는 것이 좋습니다. 필터 조건자에서 파티션 키를 포함하면 쿼리를 관련 실제 파티션으로만 효율적으로 라우팅할 수 있습니다.
워크로드 요청의 대부분이 쿼리이고 대부분의 쿼리가 동일한 속성에 같음 필터를 사용하는 경우 이 속성은 적절한 파티션 키 선택입니다. 예를 들어 UserID를 필터링하는 쿼리를 자주 실행하는 경우 UserID를 파티션 키로 선택하면 파티션 간 쿼리 수가 줄어듭니다.
컨테이너가 작은 경우 파티션 간 쿼리의 성능에 대해 걱정할 실제 파티션이 충분하지 않을 수 있습니다. Azure Cosmos DB에서 대부분의 작은 컨테이너는 하나 또는 두 개의 실제 파티션만 필요합니다.
컨테이너가 몇 개의 실제 파티션으로 확장될 수 있는 경우 파티션 간 쿼리를 최소화하는 파티션 키를 선택해야 합니다. 다음 시나리오 중 하나에 해당하는 경우 컨테이너에 몇 개 이상의 실제 파티션이 필요합니다.
컨테이너에 프로비전된 요청 단위가 30,000개 이상 있습니다.
컨테이너가 100GB 이상의 데이터를 저장하는 경우
항목 ID를 파티션 키로 사용
참고 항목
이 섹션은 주로 API for NoSQL에 적용됩니다. Gremlin용 API와 같은 다른 API는 파티션 키로 고유 식별자를 지원하지 않습니다.
컨테이너에 가능한 값이 다양한 속성이 있는 경우 파티션 키를 선택하는 것이 좋습니다. 이러한 속성의 예는 항목 ID입니다. 읽기 작업이 많은 작은 컨테이너 또는 크기에 관계 없이 쓰기 작업이 많은 컨테이너의 경우, 기본적으로 항목 ID(/id)는 파티션 키에 적합합니다.
시스템 속성 항목 ID 는 컨테이너의 모든 항목에 있습니다. 항목의 논리적 ID를 나타내는 다른 속성이 있을 수 있습니다. 대부분의 경우 이러한 고유 식별자는 항목 ID와 동일한 이유로 훌륭한 파티션 키 선택 사항이기도 합니다.
항목 ID는 다음과 같은 이유로 적합한 파티션 키입니다.
- 가능한 값이 광범위합니다(항목당 하나의 고유 항목 ID).
- 항목별 고유 항목 ID가 있기 때문에 항목 ID는 RU 소비와 데이터 스토리지를 균등하게 조정하는 데 큰 역할을 합니다.
- 항목 ID를 알고 있는 경우 항상 항목의 파티션 키를 알 수 있으므로 효율적인 시점 읽기를 쉽게 수행할 수 있습니다.
파티션 키로 항목 ID 를 선택할 때 다음 주의 사항을 고려합니다.
- 항목 ID가 파티션 키인 경우 전체 컨테이너에 대한 고유 식별자가 됩니다. 중복 식별자를 사용하여 항목을 만들 수 없습니다.
- 물리적 파티션이 많은 읽기 작업이 많은 컨테이너가 있는 경우 항목 ID가 있는 같음 필터가 있는 경우 쿼리가 더 효율적입니다.
- 저장 프로시저 또는 트리거는 여러 논리 파티션을 대상으로 지정할 수 없습니다.