2017-11-09 15 views
1

私は、azure cosmos dbのidプロパティに基づいて単一のドキュメントを取得する必要があるというシナリオがあります。唯一の問題は私がパーティションキーを知らないので、それにアクセスするためにドキュメントURIを使うことができないことです。cosmos dbのパーティション間でIDを取得するのが遅い

私の理解から

SELECT * from c WHERE c.id = "id here" 

のような単純なクエリを書くことは行く方法でなければなりませんが、私はこのクエリで深刻なパフォーマンスの問題が発生しています。ほとんどのクエリは完了するのに30秒から60秒を要し、RU /秒の狂った量を消費するようです。 10の同時クエリを実行すると、パーティションあたりの最大RU/sは30.000と高くなりました。 (パーティションあたり10.00がプロビジョニングされました)スロットリングが発生し、さらに応答が遅くなりました。

このコレクションは、パーティションあたり約3Mbの10個のパーティションで構成されているため、全体で30Mb、ドキュメント数は約1,00,000です。私のインデックスのポリシーでは、次のようになります。

{ 
    "indexingMode": "lazy", 
    "automatic": true, 
    "includedPaths": [ 
     { 
      "path": "/*", 
      "indexes": [ 
       { 
        "kind": "Range", 
        "dataType": "Number", 
        "precision": -1 
       }, 
       { 
        "kind": "Hash", 
        "dataType": "String", 
        "precision": 3 
       } 
      ] 
     } 
    ], 
    "excludedPaths": [] 
} 

そして、私は本当に、読み取り/書き込み順序を気にしないので、一貫性がEVENTUALに設定されています。コレクションには1分あたり約30件の書き込みがある書き込み圧力がかかり、各ドキュメントには1年のTTLがありますが、RUには大きな影響はありません。私はこの種の問題を、ドキュメントを照会するときだけ経験します。

誰もが同様の問題を抱えていて、修正/緩和を提供できますか?クエリやインデックス作成のポリシーに何か問題がありますか?なぜ私のクエリが多くのリソースを消費しているのか分かりません。私はこれだけ

SELECT * FROM c where c.id = 'xxx' 

のようにIDを選択しようとすると

+0

私は同じ問題を経験しましたが、書き込み圧力はまったくありません。他の索引フィールドによる照会は、実際にはIDによる照会よりも高速です。 –

答えて

0

私のテストDBについて300Kのレコード それは時間とRU

のたくさん私を取るしかし、私はその中のパーティション・キーをしようとすると

SELECT * FROM c where c.id = 'xxx' AND c.partitionField = 'yyy' 

はそれは非常に高速です

だから私は、Yを考えますあなたのデータベースを再構築し、パーティションを作るためにどのフィールドを考えなければならないのですか?

関連する問題