azure - 为什么 ContinuationToken 不能用于 Azure 搜索 API 中的分页？

Question

阅读 Azure Search .NET SDK 的文档，我发现 ContinuationToken 属性不应该用于分页(这与 @odata.nextLink 和 @ 相同) REST API 中的 search.nextPageParameter 属性)。

Note that this property is not meant to help you implement paging of search results. You can implement paging using the Top and Skip search parameters. Source

为什么我不能用它来分页？我遇到一种情况，我想运行查询，然后逐页逐步浏览结果的静态副本。然而，当我浏览它们时，随着新文档添加到底层数据库中，我不希望这些查询结果在我脚下发生变化。就我而言，在提交初始查询和导航到另一个页面之间的一两分钟内可能会添加数百或数千个结果。我怎样才能做到这一点？

Answer 1

您的问题可以分为两部分解决:

1. 为什么不建议使用ContinuationToken实现分页？
2. 如何实现分页以使页面之间的结果保持完全稳定？

这些实际上是不相关的问题，因为 ContinuationToken 无法保证搜索结果的稳定性。无论使用 $top 和 $skip 还是 ContinuationToken，Azure 搜索都不保证分页的一致性。

对于问题 1，不建议将 ContinuationToken 用于分页的原因是 Azure 搜索控制何时返回 token ，而不是您的应用程序代码。如果你对 Azure 搜索决定如何以及何时返回 token 做出假设，则这些假设可能会随着 future 的服务更新而被打破。 ContinuationToken 的目的是防止请求太多文档而导致服务不堪重负，因此您应该假设服务是否会返回 token 完全由服务决定。

对于问题 2，由于 Azure 搜索不提供一致性保证，因此您无法完全避免诸如同一文档出现在多个页面中、文档丢失或文档在查看时已被删除等问题。结果。即使您想构建自己的结果快照并在应用程序代码中对它们进行分页，构建一致的快照一开始也是不可能的。但是，如果您唯一关心的是避免在结果中显示新文档，则可以在索引中包含创建的时间戳字段，并在每个搜索请求中对其进行过滤。

坦率地说，除非您尝试导出索引的全部内容，否则我会质疑是否需要围绕分页提供如此强大的一致性保证。谷歌和必应没有做出这样的保证，因此可以说用户的期望已经围绕这一点设定了。如果您想导出数据，不幸的是，现在的 Azure 搜索并不容易做到这一点。在这种情况下，请对此投票User Voice帮助团队优先考虑此场景的项目。