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

Question

我当时正忙着使用Azure Cosmos DB（通过.NET SDK），发现有些奇怪。

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

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

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

1. 这种行为可靠吗？我很乐意看到有关此问题的一些文档。
2. 较大的延续令牌节省的RU数量是否重要？
3. 是否有另一种方法可以使新文档包含在结果中？
4. 我的假设完全错误吗？

Answer 1

我来自CosmosDB工程团队。

1. 这种行为可靠吗？我很乐意看到有关此问题的一些文档。

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

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

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

3. 是否有另一种方法可以使新文档包含在结果中？

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

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

您的假设就在:)