説明
Azure Cosmos DB 統合キャッシュは、Azure Cosmos DB 専用ゲートウェイに組み込まれているメモリ内キャッシュです。専用ゲートウェイは、キャッシュされたデータを保存し、リクエストをバックエンド データベースにルーティングするフロントエンド コンピューティングです。ワークロードに必要なコアとメモリの数に基づいて、さまざまな専用ゲートウェイ サイズから選択できます1。統合キャッシュは、バックエンド コンテナーではなくキャッシュから読み取り操作を提供することにより、読み取り操作の RU 消費と待ち時間を削減できます2。
このシナリオでは、App1 が統合キャッシュを使用できるようにするには、次の 2 つのアクションを実行する必要があります。
* アカウントのエンドポイントを https://account1.sqlx.cosmos.azure.com に変更します。これは、Azure Cosmos DB アカウントに接続し、統合キャッシュを利用するために使用する必要がある専用のゲートウェイ エンドポイントです。標準ゲートウェイ エンドポイント (https://account1.documents.azure.com) は統合キャッシュ 2 を使用しません。
* セッションへのリクエストの整合性レベルを変更します。これは、統合キャッシュでサポートされる最高の整合性レベルです。より高い一貫性レベル (強力な、または期限付きの失効性など) を使用すると、リクエストは統合キャッシュをバイパスし、バックエンド コンテナーに直接送信されます。

説明

ボックス 1: いいえ
各物理パーティションには独自のインデックスが必要ですが、インデックスが使用されないため、クエリはパーティションにまたがりません。
ボックス 2: いいえ
インデックス使用率は 0% で、インデックス検索時間もゼロです。
ボックス 3: はい
パーティション キー インデックスが作成され、クエリはパーティション間で実行されます。
参考: https://docs.microsoft.com/en-us/azure/cosmos-db/sql/how-to-query-container

Explanation:

境界付きの失効性は、書き込みレイテンシが低いことを期待しながらも全体的なグローバル順序の保証を必要とする、グローバルに分散されたアプリケーションでよく選択されます。期限付きの古さは、グループのコラボレーションと共有、株価表示機能、パブリッシュ/サブスクライブ/キューイングなどを特徴とするアプリケーションに最適です。
シナリオ: 製品内のアプリケーションの更新により、HTTP ステータス コード 429「要求が多すぎます」が頻繁に発生します。
ステータス コード 429 が、更新中の過剰なリクエスト ユニット (RU) の消費に関連していることがわかりました。
参照：
https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels

説明
代わりに、Azure Cosmos DB Core (SQL) API 変更フィードをトリガーとして、Azure イベント ハブを出力として使用する Azure 関数を作成します。
Azure Cosmos DB 変更フィードは、レコードが作成または変更されるときに、Azure Cosmos コンテナーからレコードの継続的かつ増分フィードを取得するメカニズムです。変更フィードのサポートは、コンテナーで変更をリッスンすることによって機能します。次に、変更されたドキュメントのソートされたリストを、変更された順序で出力します。
次の図は、ソリューションに関係するデータ フローとコンポーネントを表しています。

参考: https://docs.microsoft.com/en-us/azure/cosmos-db/sql/changefeed-ecommerce-solution