elasticsearch翻页优化

ES 翻页优化

ES翻页

ES 翻页，有下面几种方案

1. from + size 翻页
2. scrool 翻页
3. scrool scan 翻页
4. search after 翻页

from + size 翻页

POST /xxx_index/_search
{
   "query": { "match_all": {}},
   "from": 100,
   "size":  10
}

使用 from + size 可进行翻页

• from 参数定义了需要跳过的 hits 数，默认 0
• size 参数定义了需要返回的 hits 数目的最大值

ES 默认的单页查询最大限制（max_result_window）为10000。

该方案在翻页数目较多（即 from 较大）或者 size 特别大的情况，会出深翻页问题（deep pagination)。

该方案的优点

1. 实现较为简单
2. 可以指定任意合理的页码，实现跳页查询

该方案的缺点

1. 深翻页时，耗时较长

scrool翻页

scrool翻页方案，主要用于「一次性查询大量的数据（甚至是全部数据）」，适合「非实时处理大量数据」的场景，该方案并不适合用来做「实时数据查询」。

1. 第一次查询时，会生成一个 scrollId，并将所有符合搜索条件的搜索结果缓存起来。注意，这里只是缓存的 doc_id，并不是真的缓存了所有的文档数据，取数据是在 fetch 阶段完成的。

from+ size 翻页方案中，我们可以指定任意合理的页码，实现跳页查询；但在 scroll 方案中，无法实现跳页面查询，因为该方案中除了第一次查询，其余的查询都需要上一次查询返回的 scrollId。

该方案的优点

1. 性能较好，适合一次性查询大量的数据

该方案的缺点

1. 使用了 scrollId，会占用大量的资源（特别是排序的请求）
2. 生成的 scrollId 是基于历史数据的快照，若此时数据发生了变化，则不会反映在快照上，所以不适合用作「实时数据查询」

scroll scan 翻页

scroll scan 方式在单纯 scroll 方式的基础上，进一步提升了性能，适合「非实时处理大量数据」的场景。

单纯的使用 scroll 方式查询，可支持排序。若使用 scroll + scan 的方式，则不支持排序。

search after 翻页

search after 是 ES 5 引入的一种分页查询机制，其原理和 scroll 类似。

• 请求时，会返回一个包含 sort 排序值的数组
• 在下一次请求时，可以将包含 sort 排序值的数组用于请求入参，以便抓取下一页的数据

该方案的优点

1. 不需要维护 scrollId，不需要维护快照，因此可以避免消耗大量的资源

该方案的缺点

1. 至少需要指定一个唯一的不重复字段来排序
2. 不适用于大幅度跳页查询，或者全量导出

翻页方案对比

翻页方式	性能	优点	缺点	场景
from + size	低	灵活性好，简单实现	深度分页问题	数据量比较小， 能容忍深度分页问题
scroll	中	解决了深度分页问题	需要维护一个 scrollID (快照版本)， 无法反应数据的实时性；可排序，但无法跳页查询	查询海量数据
scroll scan	中	基于 scroll 方案，进一步 提升了海量数据查询性能	无法排序，其余缺点同	查询海量数据
search after	高	性能最好，不存在深度分页的问题， 能够反映数据的实时变更	实现复杂，需要有一个全局唯一的字段。 连续分页的实现会比较复杂，因为每一次 查询都需要上次查询的结果。	不适用于大幅度跳页查询, 适用于海量数据分页