1. 홈
  2. 질의 응답
  3. DocumentDB의 파티션 키

DocumentDB의 파티션 키

2016-11-03 4 views
0

DocumentDB 파티션 키 choise에 대한 질문이 있습니다. UserId, DeviceId 및 WhateverId가있는 데이터가 있습니다. UserId 매개 변수는 항상 쿼리에 있으므로 UserId를 파티션 키로 선택했습니다. 하지만 한 사용자 (수백만 개의 엔티티)에 대해 많은 데이터를 가지고 있는데 파티션 키를 지정하여 "SELECT * FROM c WHERE c.DeviceId = @DeviceId"과 같은 불안정한 작업을 수행하면 많은 시간 (약 220 000의 반환 된 엔티티에 대해 약 6 분)이 소요됩니다. 예를 들어 DeviceId를 파티션 키로 선택하고 병렬로 몇 개의 파티션에 대해 쿼리를 수행하는 것이 더 효과적 일 수 있습니다 (EnableCrossPartitionQuery = true 및 MaxDegreeOfParallelism = partition count를 지정) ? 또는 모든 사용자에게 별도의 컬렉션을 사용하는 것이 좋습니다.DocumentDB의 파티션 키

출처

2016-11-03 Paval

+0

이 질문에 대한 답변은 아니지만, 25 만 개 항목을 검색하려고 할 때마다 데이터 액세스 패턴을 다시 생각해 보는 것이 좋습니다. 또한 "SELECT *'는 아직 또 다른 코드 - 냄새입니다. 많은 양의 데이터를 앱 계층으로 옮기려한다면 파티션 키를 어떻게 선택해야하는지 알 수 없습니다. –

+0

감사합니다. 'SELECT *'는 간단한 예제 일뿐입니다. 죄송합니다. 나는 SELECT c.Value를 사용할 것이다. 그리고이 질문은 푸른 문서화 사이트에 대한 정보가 나에게있어 조금 추상적이기 때문에 파티션 키를 선택하는 것입니다. 이 모든 측정은 쿼리에 따라 성능을 비교하기위한 것입니다. – Paval

답변

1

약간 도움이 될지 모르지만 기본적으로 커버 아래에 있기 때문에 각 사용자의 파티션이 문제를 해결할 것이라고 생각하지 않습니다.

parrallism을 개선하기 위해 파티션 키를 시험해 볼 수는 있지만 경험상 최대 2 배에서 5 배까지 향상시킬 수 있습니다. 충분하니?

극적인 개선을 위해 일반적으로 선택적인 비정규 화 및/또는 캐싱에 의존해야합니다.

출처

2016-11-03 10:42:01

+0

파티션 키를 DeviceId로 변경했으며'SELECT c.Value FROM c WHERE c.UserId = @userId and c.WhateverId = @ WhateverId'와 같은 쿼리를 만들려고했습니다. 19845 년 반환 된 개체에 대해서는 4.6이었다. 괜찮아. 그러나 SELECT 키와 같은 쿼리 키를 사용하여 쿼리하려고 시도했을 때 c.UserId = @userId와 c.DeviceId = @ DeviceId와 거의 같은 양의 반환 된 엔티티가 약 27 초 걸렸습니다. DeviceId를 사용한 쿼리가 자주 사용되기 때문에 좋지 않습니다. 파티션 키를 지정할 때 병렬 처리가 없기 때문에 이런 일이 발생했음을 이해합니다. 다른 pk를 고려해야합니까? – Paval

+1

열쇠는 실험을 계속해야한다는 것입니다. 실험에 인덱스 조정 기능을 포함시키는 것을 잊지 마십시오. 데이터의 처음 3 바이트에서 벗어난 기본 색인 키입니다. 그 정도면 충분하지 않다면, 인덱스 핫스팟을 가질 수 있습니다. –

+0

키가 많은 경우 같은 문자로 시작하면됩니다. – Paval

0

나는이 조금 오래 알고 있지만, 당신의 설명에서이 주제에 오는 다른 사람의 이익을 ...

위해 나는 장치가 사용자에게 대부분 고유 한 것으로 가정합니다. 주어진 사용자 ID에 대해 많은 쿼리를 사용하고 콜 센터 응용 프로그램을 말하고 몇 백 개 이상의 항목을 조회하고 싶다면 좋은 사용자 ID와 같은 항목으로 파티션하는 것이 좋습니다. 이러한 경우 파티션간에 데이터를 대조해야하는 오버 헤드없이 단일 파티션에서 데이터를 신속하게 추출 할 수 있습니다. 그러나 사용자를 위해 수백만 개의 레코드가있는 경우 단일 파티션에서 많은 양의 데이터를 추출하면 곧 데이터 정렬의 오버 헤드를 초과하므로 사용자 ID를 기준으로 분할하는 것이 최악의 방법 일 수 있습니다. 이 경우 모든 파티션에서 가능한 한 균등하게 사용자 데이터를 배포하려고합니다. 각 사용자가 유사한 사용법을 가진 25 개 이상의 기기를 보유하지 않는 한 기기 ID는 아마도 좋은 선택이 아닙니다.

귀하의 경우 일반적으로 시스템에서 생성 된 증분 키 (예 : 이벤트 ID 또는 거래 ID)가 최선의 선택입니다.

출처

2017-06-22 06:50:33

 관련 문제

  • 관련 문제 없음^_^