Azure Cosmos DB - 파티션 키 이해

Azure Cosmos DB - 파티션 키 이해

첫 번째 Azure Cosmos DB를 셋업합니다.첫 번째 컬렉션으로 데이터를 Import합니다.SQL Server 데이터베이스 중 하나의 테이블에서 데이터를 Import합니다.컬렉션을 셋업할 때 파티션 키의 의미와 요건을 이해하는 데 어려움을 겪고 있으며, 이 초기 컬렉션을 셋업할 때 특별히 이름을 지정해야 합니다.

다음 문서를 읽었습니다.https://learn.microsoft.com/en-us/azure/cosmos-db/documentdb-partition-data) 에서 이 파티션 키의 명명 규칙을 어떻게 진행해야 하는지 아직 잘 모르겠습니다.

이 파티션 키에 이름을 붙일 때 어떻게 생각해야 하는지 아는 사람이 있나요?입력하려는 필드에 대해서는 아래 스크린샷을 참조하십시오.

Import하는 테이블은 7개의 컬럼으로 구성되어 있습니다.여기에는 일의의 프라이머리 키, 구조화되지 않은 텍스트 열, URL 열 및 그 외의 레코드의 URL의 세컨더리 식별자가 포함되어 있습니다.이 정보 중 파티션 키에 이름을 붙이는 방법이 포함되어 있는지 알 수 없습니다.

편집: Import할 테이블의 여러 레코드의 스크린샷을 @Porschiey의 요청에 따라 추가했습니다.

여기*의 비디오는 CosmosDb의 파티션을 이해하는 데 큰 도움이 되었습니다.

하지만 한마디로:PartitionKey는 유사한 개체를 그룹화하는 데 가장 적합한 모든 개체에 존재하는 속성입니다.

좋은 예로는 위치(도시 등), 고객 ID, 팀 등이 있습니다.물론 솔루션에 따라 크게 달라지므로 오브젝트의 외관을 게시할 경우 적절한 파티션 키를 권장합니다.

편집: 10GB 미만의 수집에는 PartitionKey가 필요하지 않습니다.(David Makogon 감사합니다)

---

* 이 MS 문서 페이지에 "Azure Cosmos DB의 파티션 분할 및 수평 확장"이라는 제목의 동영상이 저장되었지만 이후 삭제되었습니다.위에 다이렉트 링크가 제공되었습니다.

파티션 키는 논리 파티션으로 기능합니다.

논리 파티션이란 무엇입니까?논리 파티션은 요건에 따라 다를 수 있습니다.고객에 따라 분류할 수 있는 데이터가 있다고 가정합니다.이 데이터는 고객 ID가 논리 파티션으로 기능하며 사용자의 정보는 고객 ID에 따라 배치됩니다.

이것이 쿼리에 어떤 영향을 미칩니까?

쿼리하는 동안 파티션 키를 피드 옵션으로 넣고 필터에 포함하지 않습니다.

예: 당신의 쿼리가

SELECT * FROM T WHERE T.CustomerId= 'CustomerId';

지금 당장

var options = new FeedOptions{ PartitionKey = new PartitionKey(CustomerId)};

var query = _client.CreateDocumentQuery(CollectionUri,$"SELECT * FROM T",options).AsDocumentQuery(); 

Azure Cosmos DB. Partitioning에 대한 자세한 기사를 정리했습니다.

논리 파티션이 뭐죠?

Cosmos DB는 물리적 파티션(PP)과 논리 파티션 - 동일한 PP에 완전히 저장되어야 하는 특성(파티션 키)을 가진 문서의 버킷 간의 데이터 분포를 기반으로 수평으로 확장되도록 설계되었습니다.그래서 LP는 PP1과 PP2에 있는 데이터의 일부를 가질 수 없습니다.

물리 파티션에는 다음 두 가지 주요 제한이 있습니다.

• 최대 스루풋: 10,000 RU
• 최대 데이터 크기(이 PP에 저장된 모든 LP 크기 합계): 50GB

논리 파티션의 크기 제한은 1 - 20GB입니다.

메모: Cosmos DB의 초기 릴리즈에서 크기 제한이 증가했기 때문에 곧 크기 제한이 증가할 수 있다는 사실에 놀라지 않을 것입니다.

---

컨테이너의 올바른 파티션 키를 선택하려면 어떻게 해야 합니까?

를 선택할 필요가 ( 「」등).Id(문서 또는 복합 필드).주된 이유:

요구 유닛(RU)의 소비량과 데이터 스토리지를 모든 논리 파티션에 균등하게 분산합니다.이렇게 하면 물리적 파티션 전체에 균등하게 RU 소비 및 스토리지를 분산할 수 있습니다.

올바른 파티션 키를 검토할 때는 애플리케이션 데이터 소비 패턴을 분석하는 것이 중요합니다.매우 드문 시나리오이지만 대규모 파티션이 작동하는 경우도 있지만 동시에 이러한 솔루션은 처음부터 DB 크기를 유지하기 위해 데이터 아카이브를 구현해야 합니다(이유를 설명하는 예 참조).그렇지 않으면 동일한 DB 성능과 잠재적인 PP 데이터 왜곡, 예상치 못한 "분할" 및 "핫" 파티션을 유지하기 위해 운영 비용을 증가시킬 준비가 되어 있어야 합니다.

매우 세밀하고 작은 파티션 전략을 사용하면 물리적 파티션(PP) 간에 분산된 데이터의 소비에서 RU 오버헤드가 발생하지만(RU의 곱셈이 아니라 요청당 추가 RU가 2개) 데이터가 50GB, 100GB, 150GB 이상으로 증가하기 시작할 때 발생하는 문제에 비하면 무시할 수 있습니다.

---

대부분의 경우 큰 파티션이 좋지 않은 이유는 설명서에 "고객에게 가장 적합한 것을 선택하십시오"라고 되어 있는데도 말이다.

주요 이유는 Cosmos DB가 수평으로 확장되도록 설계되어 있으며 PP당 프로비저닝된 throughput은[total provisioned per container (or DB)] / [number of PP].

50GB를 초과하여 PP 분할이 발생하면 기존 PP 및 새로 생성된 2개의 PP에 대한 최대 스루풋이 분할 전보다 낮아집니다.

따라서 다음과 같은 시나리오를 상상해 보십시오(작업 간격의 척도로 일수를 고려).

1. 10k RU가 프로비저닝된 컨테이너를 만들고CustomerIdpartition key(기본 PP1을 클릭합니다.PP당 최대 스루풋은
2. 컨테이너에 데이터를 단계적으로 추가함으로써 C1[10GB], C2[20GB] 및 C3[10GB]의 청구서를 가진 3개의 대규모 고객사가 탄생합니다.
3. 다른 고객이 C4[15GB]의 데이터를 시스템에 탑재한 경우 코스모스 DB는 PP1 데이터를 2개의 새로 생성된 PP2(30GB)와 PP3(25GB)로 분할해야 합니다.PP당 최대 스루풋은
4. 2개의 고객 C5[10GB] C6[15GB]가 시스템에 추가되어 두 고객 모두 PP2가 되었습니다.그 결과 PP4(20GB)와 PP5(35GB)가 분할되었습니다.PP당 최대 스루풋은 다음과 같습니다.

중요: 그 결과[Day 2] C1최대 10k RU로 데이터를 쿼리했지만[Day 4] 쿼리 실행 시간에 직접 영향을 미치는 최대 3.333k RU만 사용할 수 있습니다.

현재 버전의 Cosmos DB(12.03.21)에서 파티션 키를 설계할 때 주의해야 할 사항입니다.

---

CosmosDB는 어떤 데이터 제한도 저장할 수 있습니다.백엔드에서는 파티션 키를 사용합니다.프라이머리 키와 같습니까?-아니요.

프라이머리 키: 데이터 샤딩에 도움이 되는 데이터 파티션 키를 일의로 식별합니다(예를 들어 도시가 파티션 키인 경우 뉴욕시의 파티션 1개).

파티션에는 10GB의 제한이 있으며 데이터를 파티션에 더 잘 분산시킬수록 더 많은 데이터를 사용할 수 있습니다.그러나 모든 파티션에서 데이터를 가져오려면 결국 더 많은 연결이 필요합니다.예: 쿼리의 동일한 파티션에서 데이터를 가져오는 것이 여러 파티션에서 데이터를 가져오는 것보다 항상 빠릅니다.

파티션 키는 샤딩에 사용되며 데이터의 논리 파티션 역할을 하며 파티션 간에 데이터를 분배하기 위한 자연스러운 경계를 Cosmos DB에 제공합니다.

자세한 것은, https://learn.microsoft.com/en-us/azure/cosmos-db/partition-data 를 참조해 주세요.

표의 각 파티션은 최대 10GB를 저장할 수 있습니다(또한 단일 테이블은 원하는 개수의 문서 스키마 유형을 저장할 수 있습니다).파티션 키를 선택해야 합니다.단, 파티션에 저장되어 있는 모든 문서가 이 10GB 제한 이하가 되도록 파티션 키를 선택해야 합니다.

저도 지금 이 문제에 대해 생각하고 있습니다.파티션 키는 날짜 범위로 해야 하나요?이 경우 일정 기간 동안 저장되는 데이터의 양에 따라 달라집니다.

논리 파티션을 정의하고 있습니다.기본적으로 데이터는 Azure에 의해 물리적으로 물리적 파티션으로 분할됩니다.

partitionKey는 프라이머리 키 또는 적절한 배포를 위해 높은 카디널리티를 가진 필드로 하는 것이 이상적입니다.또, 그 파티션내의 자기 생성 ID 필드도 프라이머리 키로 설정되어 있기 때문에, 문서 작성에 도움이 됩니다.FetchById가 훨씬 빠릅니다.

컨테이너가 생성되면 partitionKey를 변경할 수 없습니다.

데이터셋을 보면 captureId는 partitionKey에 적합한 후보이며 ID는 이 필드에 수동으로 설정되어 있으며 자동 생성된 코스모스가 아닙니다.

파티션 키에 대해서는, Microsoft 로부터 입수할 수 있는 메뉴얼이 있습니다.당신이 cosmos DB로 수행할 계획인 쿼리나 작업을 확인해야 한다고 합니다.읽기 헤비입니까, 쓰기 헤비입니까?읽기 헤비인 경우 쿼리에서 사용할 파티션 키를 선택하는 것이 이상적입니다.쓰기 헤비인 경우 카디널리티가 높은 키를 찾습니다.

다른 쿼리를 실행하는 것보다 RU를 훨씬 적게 소비하므로 항상 포인트 읽기/쓰기가 더 좋습니다.

언급URL : https://stackoverflow.com/questions/45067692/azure-cosmos-db-understanding-partition-key