ES分页方式对比
|
序号 |
分页方式 |
说明 |
性能 |
优点 |
缺点 |
场景 |
|---|---|---|---|---|---|---|
| 1 |
From/Size |
ES默认分页查询方式 |
低 |
1）使用方便，符合SQL思想 2）不强制连续，可以跳页查询 3）数据实时更新 |
1）深度分页性能较差 2）最大数据记录数受max_result_window限制，ES默认为10000(控制深度分页) |
1）数据量比较小，允许容忍深度分页问题 2）实时查询（UI分页）
|
| 2 |
Scroll |
1）获取游标scroll_id，生成历史快照 2）根据上页scroll_id，获取下页的数据 3）查询完成之后需要通过scroll_id清理历史快照 |
中 |
可解决深度分页问题 |
1）无法反应数据的实时性（快照版本） 2）强制连续查询，不允许跳页 3）需维护scroll_id，因为有数据快照，所以会占用大量资源 |
非实时查询场景 1）Job类批量处理数据 2）海量数据的导出 |
| 3 |
Sliced Scroll |
Each scroll is independent and can be processed in parallel like any scroll request.（ES5.0+） |
||||
| 4 |
Search After |
官方给出的实时分页查询建议（ES5.0+） |
高 |
1）性能最好 2）可解决深度分页问题 3）可以反映数据的实时变更 |
1）实现复杂，需要有一个全局唯一的字段 2）强制连续查询，不允许跳页 3）每一次查询都需要上次查询的结果（维护前一页最后元素的id），连续分页的实现会比较复杂 |
实时查询场景 1）海量数据的UI分页 |
一、from+size
1.1 from+size原理
注意：页面越大、分页越深，待排序的数据量越大，效率越低！！！
1.2 max_window_size
基于ES的from/size进行常规分页操作时，存在max_window_size限制，默认是10000。
因此，当from + size > 10000时，会有如下报错：
临时解决方案是：增大分页深度限制（index.max_result_window）到10W，但是随着数据量越来越大、深度分页的场景越来越复杂时，如何解决这种问题呢？
二、scroll
2.1 scroll原理
为了满足深度分页的场景，ES提供了scroll滚屏搜索（类似于SQL中的游标） 方式进行分页读取。
注意：
1）滚动上下文是昂贵的，并不建议将其用于实时用户请求，建议使用scroll来获取ES中的全量数据。
2）scroll并不适用于跳页情景！
2.2 scroll分页读取过程
1）先获取第一个scroll_id，url参数包括/index/_type/和scroll，scroll字段指定了scroll_id 的有效生存期（以分钟为单位），过期之后会被ES自动清理。
如果文档不需要特定排序，可以指定按照文档创建的时间返回会使迭代更高效。
2）后续的文档读取上一次查询返回的scroll_id 来不断的取下一页，如果srcoll_id 的生存期很长，那么每次返回的 scroll_id 都是一样的，直到该 scroll_id 过期，才会返回一个新的 scroll_id。
请求指定的 scroll_id 时就不需要 /index/_type 等信息了。
每读取一页都会重新设置 scroll_id 的生存时间，所以这个时间只需要满足读取当前页就可以，不需要满足读取所有的数据的时间，1分钟足以。
3）所有文档获取完毕之后，需要手动清理掉 scroll_id 。
虽然ES会有自动清理机制，但是 srcoll_id 的存在会耗费大量的资源来保存一份当前查询结果集映像，并且会占用文件描述符，因此用完之后要及时清理。
使用ES提供的 CLEAR_API 来删除指定的 scroll_id 。
2.3 scroll-scan
当 scroll 的文档不需要排序时，ES为了提高检索的效率，在 2.0 版本提供了 scroll + scan 的方式。
随后又在 2.1.0 版本去掉了 scan 的使用，直接将该优化合入了 scroll 中。
由于moa 线上的ES版本是2.3 的，所以只简单提一下。使用的 scan 的方式是指定 search_type=scan
三、search after
3.1 search after原理
上述的 scroll search 的方式，官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况，例如进行数据迁移、或索引变更等。
那么，在实时情况下，如何处理深度分页的问题呢？ES给出了search_afte 的方式（ES5.0+）。
3.2 scroll分页读取过程
1）第一页的请求和正常的请求一样
2）第二页的请求，使用第一页返回结果的最后一个数据的值，加上 search_after 字段来取下一页。注意：使用 search_after 的时候要将 from 置为 0 或 -1。
总结：search_after 适用于深度分页+ 排序，因为每一页的数据依赖于上一页最后一条数据，所以无法跳页请求。
另外，返回的始终是最新的数据，在分页过程中数据的位置可能会有变更。
这种分页方式更加符合moa的业务场景。
四、附录
官方文档：
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/search-request-from-size.html
参考博客：
https://blog.csdn.net/chedan666/article/details/83109228
https://blog.csdn.net/weixin_33881140/article/details/93473130
https://www.cnblogs.com/hello-shf/p/11543453.html
https://km.sankuai.com/page/15385509?searchid=264380959
https://blog.csdn.net/weixin_39800144/article/details/80501606
浙公网安备 33010602011771号