源数据频繁变化时如何处理分页答案

【问题标题】：How to handle pagination when the source data changes frequently源数据频繁变化时如何处理分页
【发布时间】：2015-01-15 17:11:06
【问题描述】：

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

Elasticsearch 通过方便的from 和to 参数为paginate search results 提供方法。

所以我运行一个查询get me the most recent data from result 1 to 10

这很好用。

用户点击“下一页”，查询为： get me the most recent data from result 11 to 20

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

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

【问题讨论】：

【解决方案1】：

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

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

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

（请注意，您不在此处需要scan 搜索类型。这用于批量提取文档，并且不应用任何排序。）

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

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

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

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

【讨论】：

【解决方案2】：

意识到这有点老了，但在 ElasticSearch 6.3 中，现在为请求正文添加了 search_after 功能，允许光标类型分页：

它与滚动 API 非常相似，但不同的是，search_after 参数是无状态的，它总是针对最新版本的搜索器进行解析。

【讨论】：

【解决方案3】：

您需要为此使用扫描 API。扫描和滚动 API 让您可以进行时间点搜索和分页。扫描 API -

【讨论】：