次の方法で共有

Azure Cosmos DB 統合キャッシュについてよく寄せられる質問

  • [アーティクル]

適用対象: NoSQL

Azure Cosmos DB 統合キャッシュは、Azure Cosmos DB に組み込まれているインメモリ キャッシュです。 この記事では、Azure Cosmos DB 統合キャッシュについてよく寄せられる質問に回答します。

よく寄せられる質問

統合キャッシュに専用ゲートウェイが必要なのはなぜですか?

ゲートウェイ モードを使用して Azure Cosmos DB に接続している場合は、標準ゲートウェイを使用しています。 Azure Cosmos DB バックエンド (プロビジョニング済みのスループットとストレージ) ではコンテナーごとに専用容量が備わっていますが、標準ゲートウェイは多くのお客様の間で共有されます。 個々のお客様によって消費されるコンピューティング リソースは最小限であるため、多くのお客様が標準ゲートウェイを共有するのは実用的です。 統合キャッシュは Azure Cosmos DB アカウントに固有であり、大量の CPU とメモリを必要とするため、専用ゲートウェイ ノードが必要です。

専用ゲートウェイとは何ですか?

専用ゲートウェイは、Azure Cosmos DB アカウント内にあるデータのフロントエンドであるサーバー側のコンピューティングです。 ゲートウェイ モードを使用して専用ゲートウェイ エンドポイントに接続すると、その専用ゲートウェイに対してアプリケーションから要求が送信され、その要求が別のバックエンド パーティションにルーティングされます。 専用ゲートウェイで直接モードを使用することはできますが、そのような要求では、統合キャッシュが使用されません。

専用ゲートウェイを使用すると、標準ゲートウェイを使用した場合よりもパフォーマンス上の利点が得られますか?

一般に、専用ゲートウェイによってルーティングされた要求の遅延は、標準ゲートウェイによってルーティングされた要求よりも若干低く、一貫性があります。 統合キャッシュを使用しない要求でも、標準ゲートウェイよりわずかに低遅延となります。

統合キャッシュでは、どのような待ち時間の種類が予想されますか?

キャッシュ データがバックエンドではなく専用ゲートウェイ上のインメモリに格納されるため、統合キャッシュによって処理される要求の方が高速になります。

キャッシュされたポイント読み取りでは、予想される待ち時間の中央値は 2 から 4 ミリ秒です。 キャッシュされたクエリの場合、待ち時間はそのクエリに依存します。 クエリ キャッシュは、特定のクエリに対するクエリ エンジンの応答をキャッシュすることで機能します。 その後、この応答は、処理のためにクライアント側で SDK に返されます。 単純なクエリの場合、SDK で必要な処理が最小限であるため、待ち時間の中央値は 2 から 4 ミリ秒が一般的です。 GROUP BY または DISTINCT を使用するより複雑なクエリでは、SDK でさらに多くの処理が必要になるため、クエリ キャッシュを使用した場合でも待ち時間が長くなる可能性があります。

以前に直接モードで Azure Cosmos DB に接続していて、専用ゲートウェイでの接続に切り替える場合は、一部の要求の待ち時間がわずかに長くなる可能性があります。 ゲートウェイ モードを使用するには、要求をゲートウェイ (この場合は専用ゲートウェイ) に送信し、バックエンドに適切にルーティングする必要があります。 直接モードでは、その名前のとおり、クライアントがバックエンドと直接通信でき、余分なホップは削除されます。 専用ゲートウェイを使用する要求に対する待機時間の SLA はありません。

自分のアプリで以前に直接モードを使用していた場合、統合キャッシュの待ち時間の利点は、次のシナリオでのみ顕著に表れます。

  • 大きな項目 (16 KB より大きい) のポイント読み取りの待ち時間
  • 高 RU または複雑なクエリ

自分のアプリで以前に標準ゲートウェイによるゲートウェイ モードを使用していた場合、統合キャッシュを使用すると、ほぼすべてのシナリオで待ち時間が短縮されます。

Azure Cosmos DB の可用性 SLA は、専用ゲートウェイと統合キャッシュまで拡張されますか?

高可用性を必要とし、Azure Cosmos DB の可用性 SLA でカバーされる必要があるシナリオでは、少なくとも 3 つの専用ゲートウェイ ノードをプロビジョニングする必要があります。 たとえば、運用環境で専用ゲートウェイ ノードが 1 つ必要な場合は、ダウンタイム、停止、アップグレードの可能性を考慮して、追加で 2 つの専用ゲートウェイ ノードをプロビジョニングする必要があります。 専用ゲートウェイ ノードが 1 つだけプロビジョニングされている場合、これらのシナリオでは一時的に可用性が失われます。 さらに、ワークロードに対応する十分なノードが専用ゲートウェイにあることを確認してください。

現在、統合キャッシュは NoSQL 用 API でのみ使用できます。 他の API 向けにもリリースする予定はありますか?

NoSQL 用 API 以外への統合キャッシュの拡張は、長期的なロードマップにおいては計画されていますが、統合キャッシュの初期スコープの範囲を越えています。

統合キャッシュではどのような整合性がサポートされますか?

統合キャッシュでは、セッションと最終的な整合性の両方がサポートされます。 また、オプションの MaxIntegratedCacheStaleness を構成することもできます。これにより、キャッシュされたデータに上限が設定されます。

次の手順