DocumentDB内のパーティションにハッシュする

Question

私はDocumentDBの上にシステムを構築しています。私たちはパーティションコレクションを使用しています。パーティションキーでは、乱数を使用して、基礎となるパーティションの均等な使用率を保証します（したがって、RUは基本パーティション間で均等に分割されるため、RUの均等利用）。

私たちは識別子で要求が行われたときに文書を後で "見つける"方法を知るために、識別子の中にパーティションキーを格納します。

これで、私たちは乱数範囲のトレードオフを理解しようとしています。 1つの文字（私たちのユースケースでは重要です）を保存する場合は、[0-999]や[0-99]のような選択肢があります。

基本パーティションが99個を超える場合は、配布がすべての「バケット」をカバーしないため、おそらくパーティションが不十分である可能性があります。私は反対の理由、すなわち99未満の物理的なパーティションで、ランダム分布範囲を[0-99]に減らすことのトレードオフを考えようとしていますか？

Answer 1

同じパーティションキーを持つすべてのドキュメントは、DocumentDBによって同じ物理パーティションに配置されます。したがって、粗いパーティションキー（99のユニークなバケットを持つ）の利点は、より大きなセットに対する非プライマリキーのクエリ、つまり同じバケットを持つデータが局所性を持ち、非常に低い（1桁のms）レイテンシでクエリできることですバケット+ IDのプライマリキークエリと同様です。トランザクションが必要なシナリオにとって重要な、より大きなトランザクション境界もあります。

粗いパーティションキーの欠点は、あなたが質問で述べたようにスケーラビリティです。データ/スループットは、99個のDocumentDBパーティションでサポートできるものを超えることはできません。また、ハッシングの性質（https://en.wikipedia.org/wiki/Birthday_problem）のために、99より小さいパーティション数でもスキューを実行することができます。つまり、データ/スループット要件がローエンドにある場合、99はかなり妥当な数値です。

アプリケーションに2桁と3桁の数字が必要な理由を理解するのに役立ちます。さらなるサポート/ディスカッションについては、DocumentDBチーム（askdocdb@microsoft.com）にお問い合わせください。