我们在实际工作中，有很多分页的需求，商品分页、订单分页等，在MySQL中我们可以使用limit，那么在Elasticsearch中我们可以使用什么呢？
ES 分页搜索一般有三种方案，from + size、search after、scroll api，这三种方案分别有自己的优缺点，下面将进行分别介绍。
使用的数据是kibana中的kibana_sample_data_flights。
这是ES分页中最常用的一种方式，与MySQL类似，from指定起始位置，size指定返回的文档数。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
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参数进行修改。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
{ "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 利用实时有游标来帮我们解决实时滚动的问题。第一次搜索时需要指定 sort，并且保证值是唯一的，可以通过加入 _id 保证唯一性。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
GET kibana_sample_data_flights/_search { "size": 2, "query": { "match": { "DestWeather": "Sunny" } }, "sort": [ { "timestamp": { "order": "asc" }, "_id": { "order": "desc" } } ] } |
在返回的结果中，最后一个文档有类似下面的数据，由于我们排序用的是两个字段，返回的是两个值。
|
1 2 3 4 |
"sort" : [ 1614561419000, "6FxZJXgBE6QbUWetnarH" ] |
第二次搜索，带上这个sort的信息即可，如下
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
GET kibana_sample_data_flights/_search { "size": 2, "query": { "match": { "DestWeather": "Sunny" } }, "sort": [ { "timestamp": { "order": "asc" }, "_id": { "order": "desc" } } ], "search_after": [ 1614561419000, "6FxZJXgBE6QbUWetnarH" ] } |
创建一个快照，有新的数据写入以后，无法被查到。每次查询后，输入上一次的 scroll_id。目前官方已经不推荐使用这个API了，使用search_after即可。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
GET kibana_sample_data_flights/_search?scroll=1m { "size": 2, "query": { "match": { "DestWeather": "Sunny" } }, "sort": [ { "timestamp": { "order": "asc" }, "_id": { "order": "desc" } } ] } |
在返回的数据中，有一个_scroll_id字段，下次搜索的时候带上这个数据，并且使用下面的查询语句。
|
1 2 3 4 5 |
POST _search/scroll { "scroll" : "1m", "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA6UWWVJRTk9TUXFTLUdnU28xVFN6bEM4QQ==" } |
上面的scroll指定搜索上下文保留的时间，1m代表1分钟，还有其他时间可以选择，有d、h、m、s等，分别代表天、时、分钟、秒。
搜索上下文有过期自动删除，但如果自己知道什么时候该删，可以自己手动删除，减少资源占用。
|
1 2 3 4 |
DELETE /_search/scroll { "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA6UWWVJRTk9TUXFTLUdnU28xVFN6bEM4QQ==" } |
from + size 的优点是简单，缺点是在深度分页的场景下系统开销比较大。
search after 可以实时高效的进行分页查询，但是它只能做下一页这样的查询场景，不能随机的指定页数查询。
scroll api 方案也很高效，但是它基于快照，不能用在实时性高的业务场景，且官方已不建议使用。
from:https://www.cnblogs.com/powercto/p/14618147.html