CosmosDbのパーティションキーに/ idを使用することの影響
毎分1000のエントリ（一意のキー）がコスモスに入るシナリオでは、/ idをパーティションキーとして使用しても安全ですか？
特に、論理パーティションの概念があります https://docs.Microsoft.com/en-us/Azure/cosmos-db/partition-data ここのグラフィックは少し怖くて、論理パーティションが実際のエンティティであること（例： "city"： "London"）。 8時間TTL=および1分あたり1000のエントリがある場合、cosmosが管理する必要がある480,000の論理パーティションが必ずしも必要ではありません。
私が想像するのは、パーティションキーの値が単純にハッシュされ、物理パーティションの数でモジュロされることです。 https://docs.Microsoft.com/en-us/Azure/cosmos-db/partitioning-overview#choose-partitionkey は、「論理パーティション管理」セクションでこれが当てはまることを示しています。さらに、「パーティションキーの選択」セクションでは、/ idが10GBの制限、スループットの制限、ホットスポットなし、ワイド（広い）（値の範囲が非常に大きい。アプリケーションはID以外をフィルタリングする必要がないため、この使用例ではパーティション間クエリは問題になりません。
要約すると、何十万ものパーティションキー値（論理パーティション）のメモリ/ CPU /その他のオーバーヘッドについて心配する必要がありますか？ドキュメントでは、パーティションキーの値が多いほど良いと示されていますが、値が多すぎる可能性があるかどうかは言わないでください。
Cosmos DBエンジニアリングチームの出身です。
Cosmos DBコレクション/コンテナーで作成される論理パーティションキーの数を気にする必要はありません。パーティションキーが書き込み（論理パーティションキーの上限は10 GB）とクエリに適している限り、問題はありません。
影響は次のとおりです。
- 最高のカーディナリティ
簡単で高速で安価なドキュメントの読み取り
トランザクションスコープはパーティションキーであるため、トランザクションはありません
id以外のクエリはクロスパーティションになります
PS。 id読み取り/クエリ以外に何も必要としない場合は、ほとんど想像できません。おそらくドキュメントキャッシュ（TTLと組み合わせて）を除いて。