[TOC]
前言
我们在实际工作中，有很多分页的需求，商品分页、订单分页等，在MySQL中我们可以使用limit，那么在Elasticsearch中我们可以使用什么呢？
ES 分页搜索一般有三种方案，from + size、search after、scroll api，这三种方案分别有自己的优缺点，下面将进行分别介绍。
使用的数据是kibana中的kibana_sample_data_flights。
from + size
这是ES分页中最常用的一种方式，与MySQL类似，from指定起始位置，size指定返回的文档数。
GET kibana_sample_data_flights/_search
{
"from": 10,
"size": 2,
"query": {
"match": {
"DestWeather": "Sunny"
}
},
"sort": [
{
"timestamp": {
"order": "asc"
}
}
]
}
这个例子中查询航班中，目的地的天气是晴朗的，并且按时间进行排序。
使用简单，且默认的深度分页限制是1万，from + size 大于 10000会报错，可以通过index.max_result_window参数进行修改。
{
"error": {
"root_cause": [
{
"type": "query_phase_execution_exception",
"reason": "Result window is too large, from + size must be less than or equal to: [10000] but was [10001]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."
}
],
"type": "search_phase_execution_exception",
"reason": "all shards failed",
"phase": "query",
"grouped": true,
"failed_shards": [
{
"shard": 0,
"index": "kibana_sample_data_flights",
"node": "YRQNOSQqS-GgSo1TSzlC8A",
"reason": {
"type": "query_phase_execution_exception",
"reason": "Result window is too large, from + size must be less than or equal to: [10000] but was [10001]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."
}
}
]
},
"status": 500
}
这种分页方式，在分布式的环境下的深度分页是有性能问题的，一般不建议用这种方式做深度分页，可以用下面将要介绍的两种方式。
理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。
现在假设我们请求第 1000 页，结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。
search after
search after 利用实时有游标来帮我们解决实时滚动的问题。第一次搜索时需要指定 sort，并且保证值是唯一的，可以通过加入 _id 保证唯一性。
GET kibana_sample_data_flights/_search
{
"size": 2,
"query": {
"match": {
"DestWeather": "Sunny"
}
},
"sort": [
{
"timestamp": {
"order": "asc"
},
"_id": {
"order": "desc"
}
}
]
}
在返回的结果中，最后一个文档有类似下面的数据，由于我们排序用的是两个字段，返回的是两个值。
"sort" : [
1614561419000,
"6FxZJXgBE6QbUWetnarH"
]
第二次搜索，带上这个sort的信息即可，如下
GET kibana_sample_data_flights/_search
{
"size": 2,
"query": {
"match": {
"DestWeather": "Sunny"
}
},
"sort": [
{
"timestamp": {
"order": "asc"
},
"_id": {
"order": "desc"
}
}
],
"search_after": [
1614561419000,
"6FxZJXgBE6QbUWetnarH"
]
}
scroll api
创建一个快照，有新的数据写入以后，无法被查到。每次查询后，输入上一次的 scroll_id。目前官方已经不推荐使用这个API了，使用search_after即可。
GET kibana_sample_data_flights/_search?scroll=1m
{
"size": 2,
"query": {
"match": {
"DestWeather": "Sunny"
}
},
"sort": [
{
"timestamp": {
"order": "asc"
},
"_id": {
"order": "desc"
}
}
]
}
在返回的数据中，有一个_scroll_id字段，下次搜索的时候带上这个数据，并且使用下面的查询语句。
POST _search/scroll
{
"scroll" : "1m",
"scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA6UWWVJRTk9TUXFTLUdnU28xVFN6bEM4QQ=="
}
上面的scroll指定搜索上下文保留的时间，1m代表1分钟，还有其他时间可以选择，有d、h、m、s等，分别代表天、时、分钟、秒。
搜索上下文有过期自动删除，但如果自己知道什么时候该删，可以自己手动删除，减少资源占用。
DELETE /_search/scroll
{
"scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA6UWWVJRTk9TUXFTLUdnU28xVFN6bEM4QQ=="
}
总结
from + size 的优点是简单，缺点是在深度分页的场景下系统开销比较大。
search after 可以实时高效的进行分页查询，但是它只能做下一页这样的查询场景，不能随机的指定页数查询。
scroll api 方案也很高效，但是它基于快照，不能用在实时性高的业务场景，且官方已不建议使用。
