Elasticsearch（八）——深度分页问题解决方案

问题

在分页处理时，我们要确定两个参数，start & size，如果一个分页查询start值很大，那么这就是一个深度分页查询。
深度分页是很有问题的，用sql举例：select * from user order by id limit 10000,10 ，表面上看起来只取10条数据，而实际上它是个大查询，因为查询过程中，数据库要确定前10010条数据，然后才能拿出最后10条。
显而易见，一方面人为深度分页是个伪需求，没有谁会一直狂翻，或者直接跳第100页看数据。另一方面，深度分页对系统的稳定性有潜在威胁。

解决办法

mysql并没有限制深度分页，而Es专门搞了一个 max_result_window 的东西 – 最大结果窗口，默认值是10000，它不仅限制了用户在一次查询中最多数据条数是1w条，并且限制了start+size 必须小于1w，也就是说，你想取第9999条，往后的2条数据是不可以的，因为 9999+2 > 10000。如此一来，一石二鸟，同时防止了一次取太多和深度分页两个问题。

善如淘宝搜索限制分页最多100页，如下:

1.通过设置index.max_result_window来突破10000数据

PUT /索引/_settings
{ "index.max_result_window": "20000"
}


2.使用scrol滚动搜索来解决

游标查询 Scroll：

scroll 查询 可以用来对 Elasticsearch 有效地执行大批量的文档查询，而又不用付出深度分页那种代价。

游标查询允许我们 先做查询初始化，然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor 。

游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性，结果就像保留初始化时的索引 视图 一样。

深度分页的代价根源是结果集全局排序，如果去掉全局排序的特性的话查询结果的成本就会很低。 游标查询用字段 _doc 来排序。 这个指令让 Elasticsearch 仅仅从还有结果的分片返回下一批结果。

启用游标查询可以通过在查询的时候设置参数 scroll 的值为我们期望的游标查询的过期时间。 游标查询的过期时间会在每次做查询的时候刷新，所以这个时间只需要足够处理当前批的结果就可以了，而不是处理查询结果的所有文档的所需时间。 这个过期时间的参数很重要，因为保持这个游标查询窗口需要消耗资源，所以我们期望如果不再需要维护这种资源就该早点儿释放掉。 设置这个超时能够让 Elasticsearch 在稍后空闲的时候自动释放这部分资源。

GET /old_index/_search?scroll=1m
{"query": { "match_all": {}},"sort" : ["_doc"], "size": 1000
}


1. 保持游标查询窗口一分钟。


2. 关键字 _doc 是最有效的排序顺序。

这个查询的返回结果包括一个字段 _scroll_id， 它是一个base64编码的长字符串 。 现在我们能传递字段 _scroll_id 到 _search/scroll 查询接口获取下一批结果：

GET /_search/scroll
{"scroll": "1m", "scroll_id" : "cXVlcnlUaGVuRmV0Y2g7NTsxMDk5NDpkUmpiR2FjOFNhNnlCM1ZDMWpWYnRROzEwOTk1OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MTA5OTM6ZFJqYkdhYzhTYTZ5QjNWQzFqVmJ0UTsxMTE5MDpBVUtwN2lxc1FLZV8yRGVjWlI2QUVBOzEwOTk2OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MDs="
}


注意

1. 注意再次设置游标查询过期时间为一分钟。


2. 这个游标查询返回的下一批结果。 尽管我们指定字段 size 的值为1000，我们有可能取到超过这个值数量的文档。 当查询的时候， 字段 size 作用于单个分片，所以每个批次实际返回的文档数量最大为 size * number_of_primary_shards 。


3. 注意游标查询每次返回一个新字段 _scroll_id。每次我们做下一次游标查询， 我们必须把前一次查询返回的字段 _scroll_id 传递进去。 当没有更多的结果返回的时候，我们就处理完所有匹配的文档了。

官文地址
https://www.elastic.co/guide/cn/elasticsearch/guide/current/scroll.html