干货 | 全方位深度解读 Elasticsearch 分页查询

 • 问题1：想请问下，一次性获取索引上的某个字段的所有值（100 万左右），除了把 max_result_window 调大 ，还有没有啥方法？

 

 • 问题2：关于 es 的分页，每次拿 20 条展示在前台，然后点击下一页，在查询后面的20条数据，应该要怎么写？

 

 • 问题3：From+size、Scroll、search_after 的本质区别和应用场景分别是什么？

 

 • From + Size 查询

 

 • Search After 查询

 

 • Scroll 查询

 

2.1.1 From + size 分页查询定义与实战案例
如下基础查询：

默认返回前10个匹配的匹配项。其中：

 

 • from：未指定，默认值是 0，注意不是1，代表当前页返回数据的起始值。
 • size：未指定，默认值是 10，代表当前页返回数据的条数。

如下指定条件查询和排序：

共返回 20 条数据。

 

其中：from + size 两个参数定义了结果页面显示数据的内容。

 

2.1.2 From + size 查询优缺点及适用场景

From + size 查询优点

 • 支持随机翻页。

From + size 查询缺点

 • 受制于 max_result_window 设置，不能无限制翻页。

 • 存在深度翻页问题，越往后翻页越慢。

From + size 查询适用场景

 • 第一：非常适合小型数据集或者大数据集返回 Top N（N <= 10000）结果集的业务场景。

 

 • 第二：类似主流 PC 搜索引擎（谷歌、bing、百度、360、sogou等）支持随机跳转分页的业务场景。

2.1.3 深度翻页不推荐使用 From + size

Elasticsearch 会限制最大分页数，避免大数据量的召回导致性能低下。

 

Elasticsearch 的 max_result_window 默认值是：10000。也就意味着：如果每页有 10 条数据，会最大翻页至 1000 页。

 

实际主流搜索引擎都翻不了那么多页，举例：百度搜索“上海”，翻到第 76 页，就无法再往下翻页了，提示信息如下截图所示：

 

什么原因？超过了最大窗口的限制，index.max_result_window 默认值为10000。

 

报错信息还同时给出了两个解决方案：

 

 • 方案一：大数据集召回数据使用：scroll api。后面会详细讲解。

 

 • 方案二：调大 index.max_result_window 默认值。

官方建议：避免过度使用 from 和 size 来分页或一次请求太多结果。

 

不推荐使用 from + size 做深度分页查询的核心原因：

 

 • 搜索请求通常跨越多个分片，每个分片必须将其请求的命中内容以及任何先前页面的命中内容加载到内存中。

 • 对于翻页较深的页面或大量结果，这些操作会显著增加内存和 CPU 使用率，从而导致性能下降或节点故障。

什么意思呢？

共 10 条数据加载到内存吗？不是的！

 

共：10011 条数据加载到内存，然后经过后台处理后返回了最后 10 条我们想要的数据。

 

那也就意味着，越往后翻页（也就是深度翻页）需要加载的数据量越大，势必会越耗费 CPU + 内存资源，响应也会越慢！

 

2.2.1 search_after 查询定义与实战案例

search_after 查询本质：使用前一页中的一组排序值来检索匹配的下一页。

 

前置条件：使用 search_after 要求后续的多个请求返回与第一次查询相同的排序结果序列。也就是说，即便在后续翻页的过程中，可能会有新数据写入等操作，但这些操作不会对原有结果集构成影响。

 

如何实现呢？

 

可以创建一个时间点 Point In Time（PIT）保障搜索过程中保留特定事件点的索引状态。

 

Point In Time（PIT）是 Elasticsearch 7.10 版本之后才有的新特性。

 

PIT的本质：存储索引数据状态的轻量级视图。

 

如下示例能很好的解读 PIT 视图的内涵。

有了 PIT，search_after 的后续查询都是基于 PIT 视图进行，能有效保障数据的一致性。

 

search_after 分页查询可以简单概括为如下几个步骤。

 

步骤 1：创建 PIT 视图，这是前置条件不能省。

步骤 2：创建基础查询语句，这里要设置翻页的条件。

 • 设置了PIT，检索时候就不需要再指定索引。

 • id 是基于步骤1 返回的 id 值。

 • 排序 sort 指的是：按照哪个关键字排序。

在每个返回文档的最后，会有两个结果值，如下所示：

 • 其中，“200”就是我们指定的排序方式：基于 {"response.keyword": "asc"} 升序排列。

而 4 代表什么含义呢？

 

 • 4 代表——隐含的排序值，是基于_shard_doc 的升序排序方式。

官方文档把这种隐含的字段叫做：tiebreaker （决胜字段），tiebreaker 等价于_shard_doc。

 

tiebreaker 本质含义：每个文档的唯一值，确保分页不会丢失或者分页结果数据出现重复（相同页重复或跨页重复）。

 

步骤3：实现后续翻页。

后续翻页都需要借助 search_after 指定前一页的最后一个文档的 sort 字段值。

 

如下代码所示：

显然，search_after 查询仅支持向后翻页。

 

2.2.2 search_after 查询优缺点及适用场景

search_after 优点

 • 不严格受制于 max_result_window，可以无限制往后翻页。

ps：不严格含义：单次请求值不能超过 max_result_window；但总翻页结果集可以超过。

 

search_after 缺点

 • 只支持向后翻页，不支持随机翻页。

search_after 适用场景

 • 类似：今日头条分页搜索  https://m.toutiao.com/search
不支持随机翻页，更适合手机端应用的场景。

2.3.1 Scroll 遍历查询定义与实战案例
相比于 From + size 和 search_after 返回一页数据，Scroll API 可用于从单个搜索请求中检索大量结果（甚至所有结果），其方式与传统数据库中游标（cursor）类似。

 

如果把  From + size 和 search_after 两种请求看做近实时的请求处理方式，那么 scroll 滚动遍历查询显然是非实时的。数据量大的时候，响应时间可能会比较长。

 

scroll 核心执行步骤如下：

 

步骤 1：指定检索语句同时设置 scroll 上下文保留时间。

实际上，scroll 已默认包含了 search_after 的PIT 的视图或快照功能。

 

从 Scroll 请求返回的结果反映了发出初始搜索请求时索引的状态，类似在那一个时刻做了快照。随后对文档的更改（写入、更新或删除）只会影响以后的搜索请求。

步骤 2：向后翻页继续获取数据，直到没有要返回的结果为止。

scroll_id 值是步骤 1 返回的结果值。

 

2.3.2 Scroll 遍历查询优缺点及适用场景

    scroll 查询优点

 • 支持全量遍历。

ps：单次遍历的 size 值也不能超过 max_result_window 大小。

    scroll 查询缺点

 • 响应时间非实时。

 • 保留上下文需要足够的堆内存空间。

scroll 查询适用场景

 

 • 全量或数据量很大时遍历结果数据，而非分页查询。

 • 官方文档强调：不再建议使用scroll API进行深度分页。如果要分页检索超过 Top 10,000+ 结果时，推荐使用：PIT + search_after。

 • From+ size：需要随机跳转不同分页（类似主流搜索引擎）、Top 10000 条数据之内分页显示场景。

 • search_after：仅需要向后翻页的场景及超过Top 10000 数据需要分页场景。

 • Scroll：需要遍历全量数据场景 。

 • max_result_window：调大治标不治本，不建议调过大。

 • PIT：本质是视图。
 

 

本文说法有不严谨的地方，以官方文档为准。

欢迎大家就自己的分页实践进行留言讨论。