Elasticsearch 分页查询四种解决方案与原理

原文引用 -> ElasticSearch分页查询四种解决方案与原理

1、from + size 浅分页

常用的分页查询根据from+size语句如下：

GET /my_index/my_type/_search
{
    "query": { "match_all": {}},
    "from": 10,
    "size": 5
}

上面的查询表示从搜索结果中取第10条开始的5条数据。

这个查询语句在 Elasticsearch 集群内部是怎么执行？假设该索引只有primary shards，没有 replica shards，假设10个分片。搜索一般包括两个阶段，query 和 fetch 阶段，query 阶段确定要取哪些doc，fetch 阶段取出具体的 doc。

Query阶段
（1） Client 发送一次搜索请求，node1 接收到请求，然后，node1 创建一个大小为 from + size 的优先级队列用来存结果，我们管 node1 叫 coordinating node。

（2）coordinating node将请求广播到涉及到的 shards，每个 shard 在内部执行搜索请求，然后，将结果存到内部的大小同样为 from + size 的优先级队列里，可以把优先级队列理解为一个包含 top N 结果的列表。

（3）每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating node，coordinating node 拿到各个 shards 返回的结果后对结果进行一次合并，产生一个全局的优先级队列，存到自身的优先级队列里。

在上面的过程中，coordinating node 拿到 (from + size) * 分片数目 条数据，然后合并并排序后选择前面的 from + size 条数据存到优先级队列，以便 fetch 阶段使用。另外，各个分片返回给 coordinating node 的数据用于选出前 from + size 条数据，所以，只需要返回唯一标记 doc 的 _id 以及用于排序的 _score 即可，这样也可以保证返回的数据量足够小。

coordinating node 计算好自己的优先级队列后，query 阶段结束，进入 fetch 阶段。

fetch阶段
query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。

（1）coordinating node 发送 GET 请求到相关shards。
（2）shard 根据 doc 的 _id 取到数据详情，然后返回给 coordinating node。
（3）coordinating node 返回数据给 Client。

coordinating node 的优先级队列里有 from + size 个 _doc _id，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前10条数据是不需要取的，只需要取优先级队列里的第11到15条数据即可。

需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用 multi-get 来避免多次去同一分片取数据，从而提高性能。

2、scroll 深分页

from+size查询方式在10000-50000条数据（1000到5000页）以内的时候还是可以的，但是如果数据过多的话，就会出现深分页问题。

举例说明：
Elasticsearch 的这种方式提供了分页的功能，同时，也有相应的限制。举个例子，一个索引，有10亿数据，分10个 shards，然后，一个搜索请求，from=1,000,000，size=100，这时候，会带来严重的性能问题，CPU，内存，IO，网络带宽。

2.1 scroll

为了解决上面的问题，elasticsearch提出了一个scroll滚动的方式。
scroll 类似于sql中的cursor，使用scroll，每次只能获取一页的内容，然后会返回一个scroll_id。根据返回的这个scroll_id可以不断地获取下一页的内容，所以scroll并不适用于有跳页的情景。

(1)初始搜索请求应该在查询中指定 scroll 参数，如 ?scroll=1m,这可以告诉 Elasticsearch 需要保持搜索的上下文环境多久。

初始搜索：

GET /my_index/my_type/_search?scroll=1m
{
  "query": {
    "match_all": {}
  },
  "size": 1,
  "from": 0
}

返回结果：

{
  "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAABn5FjRXNkZmY3ZmVGJPVXJ1NWs2MUh5RGcAAAAAAAAZ_BY0VzZGZmN2ZlRiT1VydTVrNjFIeURnAAAAAAAAGfgWNFc2RmZjdmZUYk9VcnU1azYxSHlEZwAAAAAAABn6FjRXNkZmY3ZmVGJPVXJ1NWs2MUh5RGcAAAAAAAAZ-xY0VzZGZmN2ZlRiT1VydTVrNjFIeURn",
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
  }

返回结果包含一个 scroll_id，可以被传递给 scroll API 来检索下一个批次的结果。

（2）每次对 scroll API 的调用返回了结果的下一个批次结果，直到 hits 数组为空。scroll_id 则可以在请求体中传递。scroll 参数告诉 Elasticsearch 保持搜索的上下文等待另一个3m。返回数据的size与初次请求一致。

二次搜索：

POST /_search/scroll
{
  "scroll":"3m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAB0mFjRXNkZmY3ZmVGJPVXJ1NWs2MUh5RGcAAAAAAAAdKBY0VzZGZmN2ZlRiT1VydTVrNjFIeURnAAAAAAAAHScWNFc2RmZjdmZUYk9VcnU1azYxSHlEZwAAAAAAAB0qFjRXNkZmY3ZmVGJPVXJ1NWs2MUh5RGcAAAAAAAAdKRY0VzZGZmN2ZlRiT1VydTVrNjFIeURn"
}

返回结果：

{
  "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAB0mFjRXNkZmY3ZmVGJPVXJ1NWs2MUh5RGcAAAAAAAAdKBY0VzZGZmN2ZlRiT1VydTVrNjFIeURnAAAAAAAAHScWNFc2RmZjdmZUYk9VcnU1azYxSHlEZwAAAAAAAB0qFjRXNkZmY3ZmVGJPVXJ1NWs2MUh5RGcAAAAAAAAdKRY0VzZGZmN2ZlRiT1VydTVrNjFIeURn",
  "took": 1,
  "timed_out": false,
  "terminated_early": true,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 5168,
    "max_score": 1,
    "hits": [
      {
      }

原理上来说可以把 scroll 分为初始化和遍历两步，初始化时将所有符合搜索条件的搜索结果缓存起来，可以想象成快照，在遍历时，从这个快照里取数据，也就是说，在初始化后对索引插入、删除、更新数据都不会影响遍历结果。因此，scroll 并不适合用来做实时搜索，而更适用于后台批处理任务，比如群发。

2.2 scroll-scan 的高效滚动

scroll API 保持了那些已经返回记录结果，所以能更加高效地返回排序的结果。但是，按照默认设定排序结果仍然需要代价。

一般来说，你仅仅想要找到结果，不关心顺序。你可以通过组合 scroll 和 scan 来关闭任何打分或者排序，以最高效的方式返回结果。你需要做的就是将 search_type=scan 加入到查询的字符串中：

POST /my_index/my_type/_search?scroll=1m&search_type=scan
{
   "query": {
        "match" : {
            "cityName" : "杭州"
        }
    }
}

设置 search_type 为 scan 可以关闭打分，让滚动更加高效。
扫描式的滚动请求和标准的滚动请求有四处不同：

(1)不算分，关闭排序。结果会按照在索引中出现的顺序返回;
(2)不支持聚合;
(3)初始 search 请求的响应不会在 hits 数组中包含任何结果。第一批结果就会按照第一个 scroll 请求返回。
(4)参数 size 控制了每个分片上而非每个请求的结果数目，所以 size 为 10 的情况下，如果命中了 5 个分片，那么每个 scroll 请求最多会返回 50 个结果。

如果你想支持打分，即使不进行排序，将 track_scores 设置为 true。

3、search_after 深分页

scroll 的方式，官方的建议不用于实时的请求（一般用于数据导出），因为每一个scroll_id 不仅会占用大量的资源，而且会生成历史快照，对于数据的变更不会反映到快照上。

search_after 分页的方式是根据上一页的最后一条数据来确定下一页的位置，同时在分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上。但是需要注意，因为每一页的数据依赖于上一页最后一条数据，所以无法跳页请求。

为了找到每一页最后一条数据，每个文档必须有一个全局唯一值，官方推荐使用 _uid 作为全局唯一值，其实使用业务层的 id 也可以。

（1）首次查询

POST /my_index/my_type/_search
{
    "size":2,
    "query": {
        "match" : {
            "cityName" : "杭州"
        }
    },
    "sort": [
        {"updateTime": "desc"}
    ]
}

查询返回结果

{
  "took": 2,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 534,
    "max_score": null,
    "hits": [
      {
        "_index": "my_index",
        "_type": "my_type",
        "_id": "2019061010810316",
        "_score": null,
        "_source": {
        }

（2）第二次查询

POST /my_index/my_type/_search{    "size":2,    "query": {        "match" : {            "cityName" : "杭州"        }    },    "search_after": [1560137241000],    "sort": [        {"updateTime": "desc"}    ]}

查询结果：
按照第一个检索到的最后显示的“updateTime”，search_after及多个排序字段多个参数用逗号隔开，作为下一个检索search_after的参数。
当使用search_after参数时，from的值必须被设为0或者-1

{  "took": 5,  "timed_out": false,  "_shards": {    "total": 5,    "successful": 5,    "skipped": 0,    "failed": 0  },  "hits": {    "total": 534,    "max_score": null,    "hits": [      {        "_index": "my_index",        "_type": "my_type",        "_id": "2019061010781031",        "_score": null,        "_source": {        }