分页搜索—Elastic Stack 实战手册

分页搜索—Elastic Stack 实战手册

· 更多精彩内容,请下载阅读全本《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。

上一篇:Reindex API — Elastic Stack 实战手册


下一篇:Elasticsearch生态&技术峰会 | Elasticstack解决方案与行业应用