Azure Cosmos DB の変更フィード
適用対象: NoSQL MongoDB Cassandra Gremlin
Azure Cosmos DB の変更フィードは、コンテナーに対して行われた変更が発生した順番で記録されている永続的な記録です。 Azure Cosmos DB の変更フィードのサポートは、Azure Cosmos DB コンテナーの変更をリッスンすることで機能します。 変更されたドキュメントは、変更された順に並べ替えられた一覧に出力されます。 永続的な変更は非同期的に増分処理できます。また、出力を 1 つ以上のコンシューマーに分散させて並列処理することもできます。
変更フィードの設計パターンについて、さらに学習します。
サポートされる API とクライアント SDK
変更フィード機能は現在、次の Azure Cosmos DB SDK でサポートされています。
クライアント ドライバー | NoSQL | Apache Cassandra | MongoDB | Apache Gremlin | Table | PostgreSQL |
---|---|---|---|---|---|---|
.NET | ||||||
Java | ||||||
Python | ||||||
Node/JavaScript |
変更フィードの操作
次のオプションを使用して変更フィードを操作できます。
変更フィードは、Azure Cosmos DB コンテナーのパーティション キー範囲で使用できます。 これにより、次の図のように 1 つまたは複数のコンシューマーに分散して並列処理できます。
注意
パーティション キー範囲は、変更フィード プロセッサを使用する場合は物理パーティションにマップされ、プル モデルを使用する場合は FeedRanges
にマップされます。
変更フィードの特徴
変更フィードは、すべての Azure Cosmos DB アカウントで既定で有効になっています。
複数の変更フィード モードがあり、一部のモードを有効にするには追加の構成が必要です。
他の Azure Cosmos DB の操作と同様、Azure Cosmos DB アカウントに関連付けられているどのリージョンにおいても、変更フィードからの読み取りには、プロビジョニング スループットを使用できます。
変更フィードには、コンテナー内の項目に対して行われた挿入操作と更新操作が含まれます。 すべてのバージョンと削除モード (プレビュー) を使用している場合は、削除操作と TTL の有効期限からも変更を受け取ります。
変更はそれぞれ変更フィード内に 1 回だけ出現し、クライアントがそれらのチェックポイント処理ロジックを管理しなければなりません。 チェックポイントの管理の複雑さを回避する必要がある場合は、変更フィード プロセッサによって、自動チェックポイント処理と "最低 1 回" というセマンティクスが提供されます。 詳細については、変更フィードと変更フィード プロセッサの併用に関する記事を参照してください。
Azure Cosmos DB コンテナーのパーティション キー範囲で並行して変更を使用可能です。 この機能により、大規模なコンテナーの変更を複数のコンシューマーで並行処理できるようになります。
アプリケーションは、同じコンテナーに対して複数の変更フィードを同時に要求できます。
変更フィードの開始点はカスタマイズでき、モードごとに異なるオプションを使用できます。
変更フィードの項目の並べ替え順序
変更フィードの項目の順序は変更時刻順です。 この並べ替え順序はパーティション キーごとに保証されますが、パーティション キー値全体での順序は保証されません。
Note
複数リージョンの書き込みアカウントには、次の 2 つのタイムスタンプがあります。
- レコードがローカル リージョンに書き込まれたサーバー エポック時間。 これは
_ts
のように記録されます。 - 競合が確認されなかったか、そのレコードのハブ リージョンで競合が解決されたエポック時間。 これは
crts
のように記録されます。
変更フィード項目は、crts
によって記録された順序で表示されます。
複数リージョンの Azure Cosmos DB アカウントの変更フィード
複数リージョンの Azure Cosmos DB アカウントでは、1 つのリージョンの変更をすべてのリージョンで利用できます。 書き込みリージョンがフェールオーバーすると、変更フィードは手動のフェールオーバー操作をまたいで機能し、隣接したままになります。 複数の書き込みリージョンを持つアカウントの場合、変更がいつ利用可能になるのかは保証されません。 別のリージョンで新しい変更があった場合、同じドキュメントに対する受信変更が最新バージョン モードで削除される可能性があり、すべての変更がすべてのバージョンと削除モードでキャプチャされます。
変更フィードのモード
使用できる変更フィード モードには、最新バージョン モードとすべてのバージョンと削除モードの 2 つがあります。 変更フィードを読み取るモードによって、どの操作の変更がキャプチャされ、各変更で使用可能なメタデータが決まります。 同じ Azure Cosmos DB コンテナーの複数のアプリケーションにわたって、異なるモードで変更フィードを使用することができます。
最新バージョン モード
最新バージョンの変更フィード モードでは、フィード内のすべての項目の挿入または更新からの最新の変更が表示され、フィードはコンテナーの有効期間中使用できます。 特定の変更が挿入操作によるものか、更新操作によるものであるかを示すものはなく、削除はキャプチャされません。 変更は、コンテナーの始まりまでさかのぼって任意の時点から読み取ることができます。 ただし、項目が削除されると、変更フィードから削除されます。 詳細については、最新バージョンの変更フィード モードに関する記事を参照してください。
すべてのバージョンと削除モード (プレビュー)
すべてのバージョンと削除モードでは、作成、更新、削除による項目へのすべての変更を確認できます。 項目の各変更のレコードを発生順に取得します。これには、変更フィードの読み取りの間に発生した項目の中間変更も含まれます。 すべてのバージョンと削除モードで変更フィードから読み取るには、Azure Cosmos DB アカウントに対して継続的バックアップが構成されている必要があります。これにより、Azure Cosmos DB のすべてのバージョンが作成され、変更フィードが削除されます。 このモードでは、アカウントに対して構成された継続的バックアップ期間内に発生した変更のみを読み取ることができます。 プレビューに登録する方法など、詳細については、すべてのバージョンと削除の変更フィード モードに関する記事を参照してください。
Cassandra と MongoDB の API の変更フィード
変更フィード機能は、MongoDB 用 API では変更ストリームとして表示され、Cassandra 用 API では述語を含むクエリとして表示されます。 MongoDB 用 API の実装の詳細については、Azure Cosmos DB API for MongoDB の変更ストリームに関するページを参照してください。
ネイティブ Apache Cassandra には、変更データ キャプチャ (CDC) が用意されています。これは、特定のテーブルに対してアーカイブのフラグを設定し、CDC ログ用に構成可能なディスク上のサイズに達すると、そのテーブルへの書き込みを拒否するメカニズムです。 Azure Cosmos DB for Apache Cassandra の変更フィード機能により、CQL を介して述語を使って変更をクエリする機能が向上します。 実装の詳細については、Azure Cosmos DB for Apache Cassandra の変更フィードに関するページを参照してください。
変更フィード要求ユニットの消費量の測定
変更フィードは、利用されているかどうかに関係なく、すべてのコンテナーで使用可能です。 変更フィードの唯一のコストは、リース コンテナーのプロビジョニングされたスループットと各要求の RU です。 Azure Monitor を使用して、変更フィードの要求ユニット (RU) 消費量を測定します。 詳細については、Azure Cosmos DB でのスループットまたは要求ユニットの使用状況の監視に関するページを参照してください。
次のステップ
以下の記事で、変更フィードに関してさらに詳しく知ることができます。