azure-cosmosdb - Cosmos DB 延续 token 大小影响查询是否返回新文档

Question

我在使用 Azure Cosmos DB(通过 .NET SDK)时发现了一些奇怪的东西。

通常，当我使用延续 token 逐页请求查询时，我永远不会获得在创建第一个延续 token 之后创建的文档。我可以观察到更改的文档，缺少已删除(或者说是新过滤掉的)文档，但不能观察到新文档。
然而，如果我只允许 1kB 的延续 token (我可以设置的最小的)，我也会得到新的文档。显然，只要它们最终排序到剩余的页面。

这种是有道理的，因为有大小限制，我阻止 Cosmos DB 将序列化索引查找和诸如此类的内容包含在延续 token 中。不利的一面是，Cosmos DB 必须为我请求的每个页面重新创建恢复状态，这将花费一些额外的 RU。至少根据 this discussion .作为副作用，新文档最终会出现在结果中。

现在，我实际上有几个关于此的问题。

这种行为可靠吗？我很想看到一些关于这个的文档。

更大的延续 token 节省的 RU 数量是否重要？

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

我的假设完全错误吗？

Answer 1

我来自 CosmosDB 工程团队。

这种行为可靠吗？我很想看到一些关于这个的文档。

由于客户要求帮助减少响应延续大小，我们引入了此功能(限制延续 token 大小)。我们认为，揭示修剪延续的影响过于详细，因为对于大多数客户来说，细微的行为变化应该无关紧要。

更大的延续 token 节省的 RU 数量是否重要？

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

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

不，除非您通过将 header 设置为 1 来强制 CosmosDB 在每次延续时重新评估索引。通常查询意味着在延续时执行得相当快，因此用户看到新文档的机会应该相当小。理想情况下，我们应该实现快照隔离以从第一个延续中使用 session token 检索结果，但我们还没有这样做。

我的假设完全错误吗？

你的假设是正确的:)