DocumentDbクロスパーティションのクエリ戦略

Question

、私は戦略の疑問を持っています？例えば。 PartitionKey = CustomerIdの

OR

B）文書は、まだ効率的に複数の（多くの）パーティションを横断するクエリを処理していますか？例えば。 PartitionKey =「のCustomerId +コンテキスト名+型名」

我々は現在、「A」は実施しているが、理由の記事の「B」を議論してきたことで、この引用符を持っています

持っていることがベストプラクティスです多くの別個の 値を持つパーティションキー（最低100〜1000秒）。

「少なくとも」を強調します。私たちのCustomerIdsは2〜3,000を超えるパーティションキーを生成するボリュームではありません。私たちは、1つのクエリが

SELECT * FROM c 
WHERE(MyPartition = "1+ContextA+TypeA" 
    OR MyPartition = "1+ContextA+TypeB" 
    OR MyPartition = "1+ContextA+TypeC" 
    ...) 
    AND <some other conditions> 

記事にレイアウトされたシナリオがあると推定しているようです（特に「型ID」に加えIE）30-50パーティションを打つことを知って、それ（「B」）へのより多くの情報を追加する必要があります顧客またはユーザーはたくさんの鍵を生成します。これは私たちには当てはまりません。

Answer 1

Docdb Sdkは、クロスパーティションクエリを実行すると並列呼び出しを行います。 ネットワークトラフィックを確認すると、最初に物理パーティションのキー範囲を照会し、各パーティションキー範囲に個別に呼び出しを行うことに気づくでしょう。 それは並列でそれをしない、それが

は、考慮すべき二つの側面があると言ってmaxdegreeofparallelismなどを制御することができます：データ

の

• ボリュームは、ボリューム場合1 TBと言うと、少なくとも100個の物理パーティション（各パーティションは10 GB）を必要とするため、少なくとも100個の呼び出しを行うことになります。 データ量が増えた場合、通話を増やすとパフォーマンスが低下する可能性があります。あなたが現在ドキュメントのdb SUM/AVG/COUNT/MIN/MAXでサポートされている集計を使用している場合は、集計

の照会

• 。これらはパーティション間では実行できません。