Azure Cosmos DB의 분할 및 수평적 크기 조정

적용 대상: Nosql Mongodb 카산드라 그렘린 (미국) 테이블

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는 기존 파티션을 분할하여 새 실제 파티션을 자동으로 만듭니다. 실제 파티션 분할은 애플리케이션의 가용성에 영향을 주지 않습니다. 실제 파티션이 분할된 후에도 단일 논리 파티션 내의 모든 데이터는 동일한 실제 파티션에 저장됩니다. 실제 파티션 분할은 단순히 논리 파티션을 실제 파티션에 매핑하는 새 매핑을 만듭니다.

컨테이너에 대해 프로비전된 처리량은 실제 파티션 간에 균등하게 분할됩니다. 요청을 고르게 분배하지 않는 파티션 키 디자인은 너무 많은 요청을 "핫"하게 되는 파티션의 작은 하위 집합으로 보낼 수 있습니다. 핫 파티션은 프로비저닝된 처리량의 비효율적인 사용으로 이어져 속도 제한 및 비용이 증가할 수 있습니다.

Azure Portal 메트릭 블레이드의 스토리지 섹션에서 컨테이너의 실제 파티션을 확인할 수 있습니다.

예를 들어 파티션 키로 지정된 경로 /foodGroup 가 있는 컨테이너를 고려합니다. 컨테이너에는 수의 실제 파티션이 있을 수 있지만 이 예제에서는 3개가 있다고 가정합니다. 단일 실제 파티션에는 여러 파티션 키가 포함될 수 있습니다. 예를 들어 가장 큰 실제 파티션에는 상위 3개의 가장 중요한 크기 논리 파티션 Beef Products인 , Vegetable and Vegetable Products및 Soups, Sauces, and Gravies.

초당 18,000개 요청 단위(RU/s)의 처리량을 할당하는 경우 세 개의 실제 파티션 각각은 프로비전된 총 처리량의 1/3을 활용할 수 있습니다. 선택한 실제 파티션 내에서 논리 파티션 키, 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는 실제 파티션에서 파티션 키 해시의 키 공간을 균등하게 할당합니다.

트랜잭션(저장 프로시저 또는 트리거)은 단일 논리 파티션의 항목에 대해서만 허용됩니다.

복제본 세트

각 실제 파티션은 복제본 세트로도 불리는 일련의 복제본으로 구성됩니다. 각 복제본은 데이터베이스 엔진의 인스턴스를 호스팅합니다. 복제본(replica) 집합을 사용하면 실제 파티션 내의 데이터 저장소가 지속적이고 가용성이 높으며 일관성이 있습니다. 실제 파티션을 구성하는 각 복제본(replica) 파티션의 스토리지 할당량을 상속합니다. 실제 파티션의 모든 복제본(replica) 실제 파티션에 할당된 처리량을 전체적으로 지원합니다. Azure Cosmos DB는 복제본(replica) 집합을 자동으로 관리합니다.

일반적으로 작은 컨테이너에는 단일 실제 파티션만 필요하지만 여전히 4개 이상의 복제본(replica) 있습니다.

다음 이미지는 논리 파티션이 전역적으로 분산된 실제 파티션에 매핑되는 방법을 보여 줍니다. 이미지의 파티션 집합 은 여러 지역에서 동일한 논리 파티션 키를 관리하는 물리적 파티션 그룹을 나타냅니다.

파티션 키 선택

파티션 키에는 파티션 키 경로와 파티션 키 값의 두 가지 구성 요소가 있습니다. 예를 들어 { "userId" : "Andrew", "worksFor": "Microsoft" } 항목이 있는데 파티션 키로 "userId"를 선택하면 다음과 같은 두 가지 파티션 키 구성 요소가 있습니다.

• 파티션 키 경로(예: "/userId")입니다. 파티션 키 경로는 영숫자 및 밑줄(_) 문자를 허용합니다. 또한 표준 경로 표기법(/)을 사용하면 중첩된 개체를 사용할 수도 있습니다.

• 파티션 키 값입니다(예: "Andrew"). 파티션 키 값은 문자열 또는 숫자 형식일 수 있습니다.

파티션 키의 처리량, 스토리지 및 길이 제한에 대한 자세한 내용은 Azure Cosmos DB 서비스 할당량 문서를 참조하세요.

Azure Cosmos DB에서 파티션 키를 선택하는 것은 간단하지만 중요한 디자인 선택 사항입니다. 파티션 키를 선택하면 현재 위치에서 변경할 수 없습니다. 파티션 키를 변경해야 하는 경우에는 필요한 새 파티션 키를 사용하여 새 컨테이너로 데이터를 이동해야 합니다. (컨테이너 복사 작업은 이 프로세스에 도움이 됩니다.)

모든 컨테이너에 대해 파티션 키는 다음과 같아야 합니다.

• 변경되지 않는 값이 있는 속성이어야 합니다. 속성이 파티션 키인 경우 해당 속성의 값을 업데이트할 수 없습니다.

• IEEE 754 binary64에 String따라 이중 정밀도 숫자의 경계 밖에 있을 가능성이 있는 경우 값만 포함 String 하거나 숫자로 변환하는 것이 이상적입니다. Json 사양은 상호 운용성 문제로 인해 일반적으로 이 경계 밖의 숫자를 사용하는 것이 좋지 않은 방법인 이유를 설명합니다. 이러한 문제는 변경할 수 없으며 나중에 변경하려면 데이터 마이그레이션이 필요하기 때문에 파티션 키 열과 특히 관련이 있습니다.

• 카디널리티가 높습니다. 즉, 속성에는 다양한 값을 사용할 수 있어야 합니다.

• 모든 논리 파티션에 RU(요청 단위) 사용량과 데이터 스토리지를 균등하게 분산합니다. 이 분산을 통해 실제 파티션에서 균등한 RU 사용량과 스토리지 배포가 가능합니다.

• 일반적으로 2048바이트 이하의 값이 있거나 큰 파티션 키를 사용하지 않는 경우 101바이트입니다. 자세한 내용은 큰 파티션 키를 참조 하세요.

Azure Cosmos DB에서 다중 항목 ACID 트랜잭션이 필요한 경우 저장 프로시저 또는 트리거를 사용해야 합니다. 모든 JavaScript 기반 저장 프로시저 및 트리거는 단일 논리 파티션으로 범위가 지정됩니다.

참고 항목

실제 파티션이 하나만 있는 경우 모든 쿼리가 동일한 실제 파티션을 대상으로 하므로 파티션 키의 값은 관련이 없을 수 있습니다.

읽기 작업이 많은 컨테이너에 대한 파티션 키

대부분의 컨테이너에서 위의 조건은 파티션 키를 선택할 때 고려해야 할 사항입니다. 그러나 읽기가 많은 대규모 컨테이너의 경우 쿼리에서 필터로 자주 표시되는 파티션 키를 선택할 수 있습니다. 필터 조건자에 파티션 키를 포함하여 쿼리를 관련 물리 파티션에만 효율적으로 라우팅할 수 있습니다.

워크로드 요청의 대부분이 쿼리이고 대부분의 쿼리에 동일한 속성에 대한 같음 필터가 있는 경우 이 속성은 적절한 파티션 키 선택일 수 있습니다. 예를 들어 필터링UserID하는 쿼리를 자주 실행하는 경우 파티션 키로 선택하면 UserID 파티션 간 쿼리 수가 줄어듭니다.

그러나 컨테이너가 작은 경우 파티션 간 쿼리의 성능에 대해 걱정할 필요가 있는 실제 파티션이 충분하지 않을 수 있습니다. Azure Cosmos DB의 대부분의 작은 컨테이너에는 하나 또는 두 개의 실제 파티션만 필요합니다.

컨테이너가 몇 개의 실제 파티션으로 확장될 수 있는 경우 파티션 간 쿼리를 최소화하는 파티션 키를 선택해야 합니다. 다음 중 하나가 true인 경우 컨테이너에 몇 개 이상의 실제 파티션이 필요합니다.

• 컨테이너에 프로비전된 RU가 30,000개 이상 있습니다.

• 컨테이너는 100GB 이상의 데이터를 저장합니다.

항목 ID를 파티션 키로 사용

참고 항목

이 섹션은 주로 API for NoSQL에 적용됩니다. API for Gremlin 등의 다른 API는 파티션 키로 고유 식별자를 지원하지 않습니다.

컨테이너에 다양한 가능한 값이 있는 속성이 있는 경우 파티션 키를 선택하는 것이 좋습니다. 이러한 속성의 가능한 한 가지 예는 항목 ID입니다. 읽기 작업이 많은 작은 컨테이너 또는 크기에 관계 없이 쓰기 작업이 많은 컨테이너의 경우, 기본적으로 항목 ID(/id)는 파티션 키에 적합합니다.

컨테이너의 모든 항목에 시스템 속성 항목 ID가 있습니다. 항목의 논리적 ID를 나타내는 다른 속성이 있을 수 있습니다. 대부분의 경우 이러한 ID는 항목 ID와 동일한 이유로 훌륭한 파티션 키 선택입니다.

항목 ID는 다음과 같은 이유로 적합한 파티션 키입니다.

• 가능한 값이 광범위합니다(항목당 하나의 고유 항목 ID).
• 항목당 고유한 항목 ID가 있기 때문에 항목 ID는 RU 사용량 및 데이터 스토리지를 균등하게 분산하는 데 큰 역할을 합니다.
• 항목 ID를 알고 있는 경우 항목의 파티션 키를 항상 알고 있으므로 효율적인 지점 읽기를 쉽게 수행할 수 있습니다.

항목 ID를 파티션 키로 선택하는 경우 고려해야 할 몇 가지 사항은 다음과 같습니다.

• 항목 ID가 파티션 키인 경우 전체 컨테이너에서 고유 식별자가 됩니다. 중복 항목 ID가 있는 항목은 만들 수 없습니다.
• 실제 파티션이 많은 읽기가 많은 컨테이너가 있는 경우 항목 ID가 있는 같음 필터가 있는 경우 쿼리가 더 효율적입니다.
• 여러 논리 파티션을 대상으로 하는 저장 프로시저 또는 트리거를 실행할 수 없습니다.

다음 단계

• Azure Cosmos DB에서 프로비전된 처리량에 대해 알아봅니다.
• Azure Cosmos DB의 글로벌 배포에 대해 알아봅니다.
• Azure Cosmos DB에서 데이터를 모델링하고 분할하는 방법에 관한 학습 모듈을 참조하세요.