Cosmos DB延续令牌大小会影响查询是否返回新文档

Question

我正通过Azure .NET SDK弄乱Azure Cosmos DB，发现有些奇怪。

通常，当我使用连续令牌逐页请求查询时，我从不会获得在创建第一个连续令牌之后创建的文档。我可以观察到已更改的文档，缺少已删除（或新过滤出的文档）的文档，但没有新文档。 但是，如果我只允许使用1kB连续令牌（可以设置的最小令牌），那么我也将获得新文档。很显然，只要它们最终排序到其余页面即可。

这是有道理的，因为有大小限制，所以我阻止Cosmos DB在连续令牌中包括序列化索引查找和其他内容。缺点是，Cosmos DB必须为我请求的每个页面重新创建恢复状态，这将花费一些额外的RU。至少根据this discussion。副作用是，新文档最终出现在结果中。

现在，我实际上对此有两个疑问。

1. 这种行为可靠吗？我希望看到一些有关此文档的信息。
2. 较大的延续令牌节省的RU数量是否重要？
3. 还有另一种方法来获取包含在结果中的新文档吗？
4. 我的假设完全错误吗？

Answer 1

我来自CosmosDB工程团队。

1. 这种行为可靠吗？我希望看到一些有关此文档的信息。

由于客户的要求，我们引入了此功能（限制了连续令牌的大小），以帮助减少响应的连续大小。我们认为，太多细节无法揭示修剪连续性的影响，因为对于大多数客户而言，微妙的行为更改无关紧要。

1. 较大的延续令牌节省的RU数量是否重要？

这取决于从索引生成状态所完成的工作量。例如，如果我们必须评估范围谓词（例如_ts>一些离散的秒），则保存的RU可能很重要，因为我们有可能避免扫描与_ts对应的整堆索引键（这可以是O（文档），假设最坏的情况是每秒最多插入1个文档）。在这种情况下，假设有X个连续，我们可以节省（X-1）* O（文档数）个工作量。

1. 还有另一种方法来获取包含在结果中的新文档吗？

否，除非您通过将标头设置为1强制CosmosDB对每个连续进行重新评估索引，否则通常不会在连续上相当快地执行查询，因此用户看到新文档的机会应该很小。理想情况下，我们应该实现快照隔离以从第一个延续中检索带有会话令牌的结果，但是我们还没有这样做。

1. 我的假设完全错误吗？

您的假设在：）