Cosmos DB継続トークンはどのように機能しますか？
一見すると、継続トークンがCosmos DBで何をするかは明らかです。それを次のクエリにアタッチすると、次の結果セットが得られます。しかし、「次の一連の結果」とは正確にはどういう意味ですか？
それはどういう意味ですか：
- 次の一連の結果は、最初のクエリ時にページングせずに元のクエリが完全に実行されたかのようになりますか（適切な数のドキュメントをスキップします）？
- 元のクエリが今実行されたかのように次の結果セット（適切な数のドキュメントをスキップ）？
- 何か完全に違う？
回答1.は望ましいように見えますが、サーバーが無制限の量の状態を格納する必要があることを考えると、ありそうにありません。ただし、回答2は、ページクエリ間で基になるデータが変更された場合に、同じドキュメントがページ間で複数回提供されるなど、不整合が発生する可能性があるため、問題もあります。
回答
Cosmos DBクエリの実行は、サーバー側ではステートレスです。継続トークンは、インデックスの状態を再作成し、実行の進行状況を追跡するために使用されます。
「次の結果セット」とは、前回の実行の「ブックマーク」からクエリが再度実行されることを意味します。このブックマークは、継続トークンによって提供されます。
- 継続中に作成されたドキュメント
実行される挿入とクエリの位置に応じて、返される場合と返されない場合があります。
例：
SELECT * FROM c ORDER BY c.someValue ASC
ブックマークのsomeValue = 10であると仮定すると、クエリエンジンはsomeValue = 10の継続トークンを使用して処理を再開します。
クエリの実行の間にsomeValue = 5の新しいドキュメントを挿入した場合、次の結果セットには表示されません。
>ブックマークである「ページ」に新しいドキュメントが挿入されると、次の結果セットに表示されます
- 継続中に更新されたドキュメント
上記と同じロジックが更新にも適用されます（＃4を参照）
- 継続中に削除されたドキュメント
それらは次の結果セットには表示されません。
- 重複の可能性
以下のクエリの場合、
SELECT * FROM c ORDER BY c.remainingInventory ASC
残りのインベントリが最初の結果セットの後に更新され、2ページ目のORDER BY基準を満たしている場合、ドキュメントは再び表示されます。
Cosmos DBは、クエリページ間でスナップショットアイソレーションを提供しません。ただし、製品チームによると、これは非常にまれなシナリオです。継続に対するクエリは非常に高速であり、ほとんどの場合、すべてのクエリ結果が最初のページに返されるためです。
予備実験に基づくと、答えはオプション＃2、より正確には次のように思われます。
- 最初のページを提供した後に作成されたドキュメントは、後続のページで確認できます
- 最初のページを提供した後に更新されたドキュメントは、後続のページで確認できます
- 最初のページを提供した後に削除されたドキュメントは、後続のページでは省略されます
- ドキュメントが2回提供されることはありません
上記の最初のステートメントは、MSFTからの情報と矛盾します（Kalyanの回答を参照）。ページを取得するセマンティクスを正確に指定して、CosmosDBチームからより適切な回答を得ることができれば素晴らしいと思います。これは、UI内のデータを表示するために非常に重要ではないかもしれないが、のいずれかの方法があるように思われないことを考えると、バックエンドでのデータ処理のために不可欠であり無効にクエリを実行する際にページングを（参照が トランザクションの照会です可能でCosmos DB？）。
実験方法
SachaBruttinのCosmosDB Explorerを使用して、5つのドキュメントを含むコレクションをクエリしました。このツールを使用すると、ページサイズやその他のリクエストオプションを試すことができるからです。
ページサイズは1に設定され、クロスパーティションクエリが有効になりました。SELECT * FROM cまたはなど、さまざまなクエリが試行されましたSELECT * FROM c ORDER BY c.name。
ページ1を取得した後、新しいドキュメントが挿入され、一部の既存のドキュメント（後続のページに表示されるドキュメントを含む）が更新および削除されました。次に、後続のすべてのページが順番に取得されました。
（ツールのソースコードをざっと見てみると、ResponseContinuationTokenLimitInKb設定されていないことが確認されました。）