解决 Elastic Search 的深分页问题

Elastic Search 为了避免深分页，不允许使用分页（from + size）查询 10000 条以后的数据，因此如果要查询第 10000 条以后的数据，要使用 Elastic Search 提供的 scroll 游标 来查询

1. 为什么不能使用 from + size 进行深分页查询？

之所以 Elastic Search 不支持使用 from + size 来查询 10000 条以后的数据，是因为假设取的页数较大时（深分页），像是请求第 20 页，Elastic Search 不得不取出所有分片上的第 1 页到第 20 页的所有文档，并做排序，最终再取出 from 后的 size 条结果作爲最终的返回值

假设你有 16 个分片，则需要在 coordinate node 彙总到 shards * (from + size) 条记录，即需要 16 * (20 + 10) 记录后做一次全局排序，而当索引非常非常大（千万或亿）时，是无法使用 from + size 做深分页的，分页越深则越容易 Out Of Memory，即使你运气很好没有发生 Out Of Memory，也会非常消耗 CPU 和内存资源

为了保护机器，Elastic Search 使用 index.max_result_window:10000 这个设定作爲保护措施 ，即默认 from + size 不能超过 10000，虽然这个参数可以动态修改，也可以在配置文件配置，但是最好不要这么做，应该改用 Elastic Search 提供的 scroll 方法来取得数据

2. scroll 游标原理

可以把 scroll 理解爲关係型数据库里的 cursor，因此，scroll 并不适合用来做实时搜索，而更适用于后台批处理任务，比如群发，使用 scroll 可以增加性能的原因，是因为如果做深分页，每次搜索都必须重新排序，非常浪费，而使用 scroll 就是一次把要用的数据都排完了，分批取出，因此比使用 from + size 还好

scroll 具体分爲初始化和遍历两步

• 初始化时将所有符合搜索条件的搜索结果缓存起来，可以想象成快照
• 在遍历时，从这个快照里取数据

也就是说，在初始化后对索引插入、删除、更新数据都不会影响遍历结果

3. 具体实例

初始化 - 请求

GET my_index/_search?scroll=1m
{
    "query":{