使用 from / size 分页

from - 表示起始位置,size - 表示每页数量;类似与 MySQL 的 limit + offset。
示例:

GET /_search
{
    "from" : 10, "size" : 10,
    "query" : {
        "term" : { "user" : "kimchy" }
    }
}

需要注意的是,from + size 不能超过10000,也就是说在前10000条之内,可以随意翻页,10000条之后就不行了。
实际上,通过设置 index.max_result_window 可以修改这个限制,但是不建议这么做,因为这种方式翻页越深效率越低。

原理:

Query阶段:

当一个请求发送到某个ES节点时,该节点(Node1)会根据from和size,建立一个结果集窗口,窗口大小为from+size。假如from=10000,size=100,则窗口大小为10100。

此节点将请求广播到其他相关节点上,从每个Shards中取Top 10100条的score和id。

所有Shards获取的结果汇聚到Node1,假如有5个Shards,则一共会取到5 * 10100 = 50500条数据。

Node1进行归并排序,并选择Top 10100条,存入结果集窗口。

Fetch阶段:
根据Query阶段得到的排序结果,从 from 位置取 size 条数据,抓取文档详细内容返回。

从此过程中可以看出,翻页越靠后,需要参与排序的文档就越多,效率也就越低。所以,如果结果集很大,不建议用这种分页方式。

关于ES搜索请求过程,推荐一篇博文:https://blog.csdn.net/caipeichao2/article/details/46418413(其中query_and_fetch已经在对外接口中去掉了,所以只需了解query_then_fetch过程即可。)

使用 scroll 分页

使用scroll就像传统数据库中的游标一样,方式如下:

第一步

POST /twitter/_search?scroll=1m
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}

scroll=1m,表示“search context”存活时间1分钟。返回结果中会带有一个“_scroll_id”,这个值在后续的翻页过程中使用。

第二步

POST /_search/scroll
{
    "scroll" : "1m",
    "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}

不用指定index和type,也不用其他查询条件,只要把上一步的_scroll_id即可。

之后翻页一直如此,每次执行会自动滚动100条数据,直到返回的结果为空为止。

每次执行间隔不要超过1分钟,否则“search context”会释放掉。

第三步

DELETE /_search/scroll
{
    "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}

结果遍历完成后,删除scroll_id。这一步也可以不做,等1分钟后没有继续翻页请求,“search context”会自动释放掉,不过建议还是手动清除,节省资源。

优化:
如果目的是为了遍历所有结果,而不关心结果的顺序,那么可以按“_doc”排序来提高性能

POST /twitter/_search?scroll=1m
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "sort": ["_doc"]
}

与 from/size 分页方式不同,使用 scroll 分页只能单向顺序翻页,不能随机翻页,适用于遍历结果集的场景。

scroll 翻页能够深度翻页,但是翻页期间需要维护“search context”,这是需要占用一定资源的。

所以对于用户高并发访问的场景,不推荐用这种方式,scroll 更适用于批处理类的后台任务。

使用 search after 分页

这种方式同样可以深度翻页,但是弥补了 scroll 方式的不足。其思想是:用前一次的查询结果作为下一次的查询条件。

示例:

首次查询

GET /user_model/_search
{
  "size": 10,
  "query": {"match_all": {}},
  "sort": [
    {"_id": "asc"}
  ]
}

返回结果:

{
  "took" : 4379,
  "timed_out" : false,
  "_shards" : {
    "total" : 6,
    "successful" : 6,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 38213940,
    "max_score" : null,
    "hits" : [
      ...
      {
        "_index" : "user_model",
        "_type" : "_doc",
        "_id" : "00000f78f59644b1967783986c35496c",
        "_score" : null,
        "_source" : {
          ...
        },
        "sort" : [
          "00000f78f59644b1967783986c35496c"
        ]
      }
    ]
  }}

后续查询

GET /user_model/_search
{
  "size": 10,
  "query": {"match_all": {}},
  "sort": [
    {"_id": "asc"}
  ],
  "search_after": ["00000f78f59644b1967783986c35496c"]
}

其中,search_after 为上次查询结果中最后一条记录的 sort 值。

总结:

  1. 如果数据量小(10000条内),或者只关注结果集的TopN数据,可以使用from / size 分页,简单粗暴

  2. 数据量大,深度翻页,后台批处理任务(数据迁移)之类的任务,使用 scroll 方式

  3. 数据量大,深度翻页,用户实时、高并发查询需求,使用 search after 方式