· 更多精彩内容，请下载阅读全本《Elastic Stack实战手册》

· 加入创作人行列，一起交流碰撞，参与技术圈年度盛事吧

创作人：张超

在查询场景中，从 Elasticsearch 中取得结果，根据不同场景，有多种不同的方式。

• 通过 from 、size 进行分页
• 通过 scroll 拉取大量数据
• 通过 search_after 拉取大量数据

每种方式有其各自的使用场景，或者说他们是为了解决某种场景而设计的。

from + size

搜索引擎的场景，类似 google 搜索，翻页操作一般是人为触发的，并且人的行为一般不会翻页太多，from+size 这种最经典的翻页模式是为了解决用户对于 TopN 的需求，用户希望找到 TopN 个最匹配的文档。其使用方式类似 SQL 中的 LIMIT关键字，Elasticserach 使用 from 和 size 两个参数来控制翻页：

• size: 要返回的结果数量，默认为 10
• from: 要跳过的结果数量，默认为 0

如果每页显示 5 条结果，下面的命令可以得到 1-3 页的结果：

GET /_search?size=5
GET /_search?size=5&from=5
GET /_search?size=5&from=10

分页搜索实现方式是：

1. 每个分片各自查询的时候先构建 from+size 的优先队列，然后将所有的文档 ID 和排序值返回给协调节点。
2. 协调节点创建 size 为 number_of_shards * (from + size) 的优先队列，对数据节点的返回结果进行合并，取全局的 from+size 返回给客户端

这种工作模式的主要代价在于，协调节点需要等待所有分片返回结果，然后再全局排序。因此会创建非常大的优先队列，需要控制分页的深度，Elasticsearch 默认最多返回 10000 个文档。但是有些时候，用户需要遍历取回所有文档，甚至可以不关心排序。在数据库中取回全部结果可以使用游标查询的方式，类似的概念在 Elasticsearch 中叫做 scroll。

scroll

scroll 可以用于拉取全量数据，他的工作模式不需要像 from + size 一样全局排序，因此没有深分页的代价，例如 reindex 本质上就是 scroll+bulk。使用 scroll 可以简单的在查询语句中添加 scroll 参数：

POST /my-index-000001/_search?scroll=1m

上面的查询语句会返回一个 ID，后面可以根据这个 ID 顺序拉取结果：

POST /my-index-000001/_search/scroll                                                               
{
  "scroll" : "1m",                                                                 
  "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==" 
} 

Elasticsearch 将查询后的上下文保存在服务端，因此客户端可以依据这个 scroll_id 依次获取后续的数据。

这个上下文也必然有一个生命周期，因为他会一直占用服务端资源。在这个例子中，我们设置 scroll 窗口保存 1 分钟的时间。1 分钟之内，你都可以使用 scroll_id 来拉取数据。当然，你也可以在拉取完成之后根据 scroll_id 手工清理上下文。

search_after

如果说 scroll 是把上下文保存在服务端，而 search_after 要求数据中存在一个无重复，可以用于排序的字段，需要客户端每次传入上次查到的最后结果，然后获取其随后的数据。

由于随后的请求每次都是查询出来的，如果数据发生变化，就可能出现跨页面结果不一致的情况，为了防止这种情况，需要在请求中加一个参数来设置当前的索引状态保留时间。

POST /my-index-000001/_pit?keep_alive=1m

PIT 是 point in time 的简写，他是一个轻量级的视图。上述请求返回一个 ID：

{
  "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA=="
}

随后的请求中你需要带上他。可以通过下面的方式，获取第一页的结果，其中的特别之处在于，要指定进行排序的字段：

GET /_search
{
  "size": 10000,
  "query": {
    "match" : {
      "user.id" : "elkbee"
    }
  },
  "pit": {
        "id":  "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==", 
        "keep_alive": "1m"
  },
  "sort": [ 
    {"@timestamp": "asc"}
  ]
}

在返回结果中，会携带 sort 字段的值，

{
  "hits" : {
    "hits" : [
      {
        "sort" : [
          4294967298                              
        ]
      }
    ]
  }
}

你需要在下次请求的时候带上他：

GET /_search
{
  "size": 10000,
  "query": ...
  "pit": {
        "id":  ...
        "keep_alive": ...
  },
  "sort": [
    {"@timestamp": "asc"}
  ],
  "search_after": [                                
    4294967298
  ]                    
}

类似 scroll，pit 请求返回的 ID 也可以手工清理。

最后我们总结一下每种分页方式的特点:

• from+size 支持跳页，不适合深分页；
• scroll 不支持跳页，适合拉取大量数据，不适合大量并发
• search_after 不支持跳页，适合拉取大量数据

Scroll 和 search_after 都可以用于深分页，search_after 需要提供一个主键字段进行排序，默认为 _shard_doc，它是 shard index 与 Lucene 内部 ID 的组合值。在服务端保存的上下文要比 scroll 小，目前官方推荐使用 search_after 代替 scroll。