elasticsearch - 源数据频繁变化时如何处理分页

Question

具体来说，我正在使用 Elasticsearch 进行分页，但这个问题可能适用于任何数据库。

Elasticsearch 提供了 paginate search results 的方法使用方便的 from 和 to 参数。

所以我运行一个查询获取结果 1 到 10 的最新数据

效果很好。

用户点击“下一页”，查询为:获取结果 11 到 20 的最新数据

问题是，在两次查询之间，有 2 条新记录被添加到后备数据库中，这意味着分页结果将重叠(第一页的最后 2 条在第二页上显示为前两条).

避免这种情况的最佳解决方案是什么？现在，我正在向查询添加一个过滤器，告诉它只包含比上一个查询的最后一个结果晚的结果。但这似乎很老套。

Answer 1

如果您已经在为相关时间戳建立索引，那么过滤器是个不错的选择。您必须在客户端跟踪该时间戳才能正确准备您的查询。您还必须知道何时摆脱它。但这些都不是无法克服的问题。

Scroll API 是一个可靠的选择，因为它在 Elasticsearch 端有效地及时快照。 Scroll API 的目的是为深度分页提供稳定的搜索查询，它必须处理您遇到的确切变化问题。

你开始一个Scrolling Search通过提供您的查询和 scroll 参数，Elasticsearch 为此返回一个 scroll_id。然后，您向 /_search/scroll 发出请求并提供该 ID，每个请求都会为下一个请求返回一页结果和一个新的 scroll_id。

(请注意，您不希望在此处使用扫描搜索类型。这用于整体提取文档，并且不适用任何排序。)

与过滤相比，您仍然需要跟踪一个值:下一页结果的 scroll_id。这是否比跟踪时间戳更容易取决于您的应用。

还有其他潜在的缺点需要考虑。 Elasticsearch 在集群中的单个节点上保存您的搜索上下文。可以想象，这些可能会在您的集群中累积，具体取决于您对滚动搜索的依赖程度。您需要在那里测试性能影响。如果我没记错的话，滚动搜索也不会在节点故障或重启后持续存在。

Scroll API 的 ES 文档提供了有关上述所有方面的详细信息。

底线:按时间戳过滤实际上是个不错的选择。 Scroll API 是另一个有效选项，专为类似的用例而设计，但并非没有缺点。