파티션 키 선택
JSON 문서의 데이터는 컨테이너 내의 Azure Cosmos DB 데이터베이스에 저장되며, 물리적 파티션에 분산됩니다. 여기서 데이터는 파티션 키의 값에 따라 적절한 물리적 파티션으로 라우팅됩니다.
파티션 키는 동일한 파티션 키 값을 가진 문서가 특정 물리적 파티션으로 라우팅되고 저장되도록 하는 필수 문서 속성입니다. 물리적 파티션은 고정된 최대 스토리지 및 처리량(RU/s)을 지원합니다. Azure Cosmos DB는 사용 가능한 물리적 파티션에 논리 파티션을 자동으로 배포하고, 다시 파티션 키 값을 사용하여 예측 가능한 방식으로 배포합니다.
이번 단원에서는 논리 파티션에 대해 자세히 알아보고 핫 파티션을 방지하는 방법을 설명합니다. 이 정보는 해당 시나리오에서 고객 데이터에 적합한 파티션 키를 선택하는 데 도움이 됩니다.
Azure Cosmos DB에서 데이터에 액세스하고 데이터를 저장하기 위해 더 많은 물리적 파티션을 추가하면 스토리지 및 처리량이 증가합니다. 물리적 파티션의 최대 스토리지 크기는 50GB이고 최대 처리량은 10,000RU/s입니다.
Azure Cosmos DB의 논리 파티션
논리 파티션은 기본 실제 파티션 위의 추상화입니다. 여러 논리 파티션을 단일 실제 파티션 내에 저장할 수 있습니다. 컨테이너에는 논리 파티션이 무제한으로 있을 수 있습니다. 개별 논리 파티션은 최적의 스토리지 사용률과 증가를 보장하기 위해 크기가 커짐에 따라 새 실제 파티션으로 이동됩니다. 논리 파티션을 하나의 단위로서 이동하면 논리 파티션 내의 모든 문서가 동일한 물리적 파티션에 상주합니다. 논리 파티션의 최대 크기는 20GB입니다. 카디널리티가 높은 파티션 키를 사용하면 더 많은 수의 논리 파티션에 데이터를 분산하여 이 20GB 제한을 방지할 수 있습니다. 계층 구조에서 파티션 키 값을 구성하는 계층적 파티션 키를 사용하여 이 제한을 방지할 수도 있습니다. 이러한 내용은 다른 학습 경로에서 다룹니다.
파티션 키를 사용하면 논리 파티션의 데이터를 라우팅할 수 있습니다. 이는 데이터를 라우팅하는 컨테이너의 모든 문서 내에 존재하는 속성입니다. 컨테이너는 동일한 파티션 키로 저장된 모든 데이터에 대한 또 다른 추상화입니다. 파티션 키는 컨테이너를 만들 때 정의됩니다.
다음 예제에서 컨테이너의 파티션 키는 /username입니다.
핫 파티션 방지
Azure Cosmos DB의 데이터를 모델링할 때, 선택한 파티션 키가 컨테이너의 실제 파티션인 논리 및 확장 모두에서 데이터와 요청을 균등하게 배포하는 것이 매우 중요합니다. 컨테이너가 더 커지고 물리적 파티션 수가 증가하는 경우에 특히 그렇습니다.
개발 중에 로드되는 데이터베이스의 디자인을 테스트하지 않는 경우 애플리케이션을 생산하고 중요한 데이터를 이미 쓴 후에야 파티션 키를 잘못 선택한 사실이 드러날 수 있습니다.
데이터가 올바르게 분할되지 않은 경우 핫 파티션이 발생할 수 있습니다. 핫 파티션은 애플리케이션 워크로드가 스케일링되지 못하게 하며 스토리지와 처리량 모두에서 발생할 수 있습니다.
스토리지 핫 파티션
스토리지의 핫 파티션은 매우 비대칭적인 스토리지 패턴을 초래하는 파티션 키가 있는 경우에 발생합니다. 예를 들어 TenantId를 6개의 테넌트가 있는 파티션 키로 사용하는 다중 테넌트 애플리케이션을 고려합니다. A~F. Tenants B, C, E 및 F는 매우 작으며 테넌트 D에는 좀 더 많은 데이터가 있습니다. 그렇지만 테넌트 A는 매우 커서 파티션의 20GB 한도에 빠르게 도달합니다. 이 시나리오에서는 스토리지를 더 많은 논리 파티션으로 분산시킬 다른 파티션 키를 선택해야 합니다.
처리량 핫 파티션
요청 대부분 또는 모든 요청이 동일한 논리 파티션으로 이동하는 경우 처리량에서 핫 파티션 문제가 발생할 수 있습니다.
요청이 파티션 키 값에 최대한 균일하게 분산되도록 하려면 애플리케이션에 대한 액세스 패턴을 이해하는 것이 중요합니다. Azure Cosmos DB에서 컨테이너에 대해 처리량이 프로비저닝되면 컨테이너 내의 모든 물리적 파티션에 균등하게 할당됩니다.
예를 들어 30,000RU/s를 갖는 컨테이너가 있는 경우, 이 워크로드는 앞서 설명한 세 테넌트에 대한 6개의 물리적 파티션으로 분산됩니다. 따라서 각 실제 파티션은 10,000 RU/s를 얻게 됩니다. 테넌트 D가 10,000RU/s를 모두 소비한 경우, 다른 파티션에 할당된 처리량을 소비할 수 없으므로 속도가 제한됩니다. 이로 따라 테넌트 C 및 D의 성능이 저하되고 사용되지 않는 컴퓨팅 용량이 다른 물리적 파티션 및 나머지 테넌트에 남아 있습니다. 궁극적으로 이 파티션 키는 애플리케이션 워크로드를 스케일링할 수 없는 데이터베이스 디자인을 생성합니다.
데이터와 요청이 균등하게 분산된 경우, 데이터베이스는 스토리지와 처리량 모두를 최대한 활용하는 방식으로 커질 수 있습니다. 이를 통해 최고의 성능과 효율성을 달성할 수 있습니다. 간단히 말해서 데이터베이스 디자인을 스케일링할 수 있습니다.
읽기 및 쓰기 고려
파티션 키를 선택하는 경우에는 데이터의 읽기 또는 쓰기 작업이 많은지 여부도 고려해야 합니다. 쓰기가 많은 요청의 경우 카디널리티가 높은 파티션 키를 사용하여 데이터를 배포해야 합니다.
읽기가 많은 워크로드의 경우 파티션 키에 대한 같음 필터를 사용하는 WHERE 절을 포함하거나 쿼리에서 파티션 키 값의 하위 집합에 대해 IN 연산자를 포함하여 쿼리를 하나 또는 제한된 수의 파티션으로 처리해야 합니다.
애플리케이션 워크로드의 읽기와 쓰기가 모두 많은 시나리오에 솔루션이 있습니다. 다음 모듈에서 이러한 솔루션을 살펴볼 것입니다.
다음 그림에서는 사용자 이름으로 분할된 컨테이너를 보여 줍니다. 이 쿼리는 단일 논리적 파티션만을 대상으로 하므로 성능은 항상 적절하게 유지됩니다.
favoriteColor 등의 다른 속성에서 필터링된 쿼리는 컨테이너 내의 모든 파티션으로 “팬 아웃”합니다. 이를 ‘크로스 파티션’이라고도 합니다. 컨테이너가 작고 단일 파티션만 사용할 때는 이러한 쿼리가 예상대로 수행됩니다. 그러나 컨테이너가 커지고 물리적 파티션 수가 증가함에 따라 물리적 파티션에 쿼리와 관련된 데이터가 포함되어 있는지 여부를 확인하기 위해 모든 파티션을 검사해야 하므로 더 느리고 비용이 많이 듭니다.
고객에 대한 파티션 키 선택
이제 Azure Cosmos DB의 분할에 대해 이해했으므로 고객 데이터에 대한 파티션 키를 결정할 수 있습니다. 앞에서 설명한 것처럼 고객에 대해 수행하는 세 가지 작업이 있습니다. 고객 생성, 고객 업데이트, 고객 검색입니다. 이 경우에는 id를 기준으로 고객을 검색하게 됩니다. 해당 작업이 가장 많이 호출될 것이므로 고객의 ID를 컨테이너의 파티션 키로 만드는 것이 좋습니다.
ID를 파티션 키로 만들면 고객 수만큼 많은 논리 파티션을 갖게 되고 각 논리 파티션은 오직 하나의 문서만 포함한다는 뜻이므로 우려스러울 수 있습니다. 고객이 수백만 명이면 논리 파티션도 수백만 개가 될 수 있습니다.
완전히 괜찮습니다. 논리 파티션은 가상 개념이며 포함할 수 있는 논리 파티션 수에도 제한이 없습니다. Azure Cosmos DB는 동일한 물리적 파티션에 다수의 논리 파티션을 배치합니다. 논리 파티션의 개수 또는 크기가 커지면 Cosmos DB는 필요한 경우에 논리 파티션을 새 물리적 파티션으로 이동합니다.