elasticsearch分页查询（浅分页、滚动分页、search_after 分页）

不同的分页方式，适合不同的场景：

查询方式	数据量	实时查询	排序	跳页	适用场景
from+size浅分页	小	支持	支持	支持	实时查询，跳页查询
scroll标准方式	大	不支持	支持	不支持	深度分页，有序的批量查询
scroll-scan 滚动扫描	大	不支持	不支持	不支持	深度分页，无序的批量查询
search_after 分页	大	支持	支持	不支持	深度分页，数据批量导出

• from+size浅分页适合数据量小的场景，可以用于实时搜索场景，也可以跳页搜索。
• scroll标准方式查询不适合实时搜索查询，因为开始查询时形成一个快照，连续查询过程中，不会将新增加或修改的数据添加到查询结果中，也不支持跳页查询。区分首次查询和后续查询。
• scroll-scan 滚动扫描方式查询，在scroll标准方式基础上进行了一定的优化，特别是不需要排序的情况下，可以有效提高查询效率。区分首次查询和后续查询。
• search_after 分页的每次查询依赖于上次查询的最后一条数据，适合顺序连续查询，不支持跳页查询。区分首次查询和后续查询。

1、from + size 浅分页

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

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

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

搜索一般包括两个阶段，query 和 fetch 阶段，query 阶段确定要取哪些doc，fetch 阶段取出具体的 doc。

1.1 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 阶段。

1.2 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（1分钟）,这可以告诉 Elasticsearch 需要保持搜索的上下文环境多久。

初始搜索：

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

返回结果：

{
  "_scroll_id": "iT1VydTVrNjFIeURnAAAAAA...",
  "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（3分钟）。返回数据的size与初次请求一致。

二次搜索：

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

返回结果：

{
  "_scroll_id": "DnF1ZXJ5VGhlbkZldGNo...",
  "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 也可以。

3.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": {
        }

3.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": {
        }