序号分页方式说明性能优点缺点场景
From/SizeES默认分页查询方式低1）使用方便，符合SQL思想
2）不强制连续，可以跳页查询
3）数据实时更新
1）深度分页性能较差
2）最大数据记录数受max_result_window限制，ES默认为10000(控制深度分页)
1）数据量比较小，允许容忍深度分页问题
2）实时查询（UI分页）
Scroll1）获取游标scroll_id，生成历史快照
2）根据上页scroll_id，获取下页的数据
3）查询完成之后需要通过scroll_id清理历史快照
中可解决深度分页问题1）无法反应数据的实时性（快照版本）
2）强制连续查询，不允许跳页
3）需维护scroll_id，因为有数据快照，所以会占用大量资源
非实时查询场景
1）Job类批量处理数据
2）海量数据的导出
Sliced ScrollEach scroll is independent and can be processed in parallel like any scroll request.（ES5.0+）
Search After官方给出的实时分页查询建议（ES5.0+）高1）性能最好
2）可解决深度分页问题
3）可以反映数据的实时变更
1）实现复杂，需要有一个全局唯一的字段
2）强制连续查询，不允许跳页
3）每一次查询都需要上次查询的结果（维护前一页最后元素的id），连续分页的实现会比较复杂
实时查询场景
1）海量数据的UI分页
一、from+size
1.1 from+size原理
from+size是ES默认的分页查询方式，但是在深度分页的情况下，该方式效率很低，分析如下：
假如ES集群存在6个分片，from+size=100，size=10，则会根据排序规则从6个分片中取回from+size（100）条数据数据，然后汇总（即600条数据），最后从这600条中选择第90~100条数据。
假如from+size=1W，则汇总数据为6W条，如果分片数量更多呢？
注意：页面越大、分页越深，待排序的数据量越大，效率越低！！！
1.2 max_window_size
基于ES的from/size进行常规分页操作时，存在max_window_size限制，默认是10000。
因此，当from + size > 10000时，会有如下报错：
RemoteTransportException[[set-xr-eagle-travel-travelcommones-test01][10.48.169.154:8042][indices:data/read/search[phase/query]]]; nested: QueryPhaseExecutionException[Result window is too large, from + size must be less than or equal to: [10000] but was [11720]. 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.]; }{[WCUhQV_yRgmXeGZT-UNkJw][detail_project][1]:
临时解决方案是：增大分页深度限制（index.max_result_window）到10W，但是随着数据量越来越大、深度分页的场景越来越复杂时，如何解决这种问题呢？
二、scroll
2.1 scroll原理
为了满足深度分页的场景，ES提供了scroll滚屏搜索（类似于SQL中的游标） 方式进行分页读取。
针对某次查询生成一个游标 scroll_id（每次只能获取一页的内容），后续的查询只需要根据这个游标去查询数据（不断地获取下一页的内容），直到结果集中返回的 hits 字段为空，就表示遍历结束。
scroll_id的生成：可理解为建立了一个临时的历史快照，在此之后的增删改查等操作不会影响到这个快照的结果。
注意：
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+）。
search_after是一种假分页方式，是根据上一页的最后一条数据来确定下一页的位置，同时在分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上。
为了找到每一页最后一条数据，每个文档必须有一个全局唯一值（与moa内存中使用rbtree 分页的原理一样），官方推荐使用 _uid 作为全局唯一值，其实使用业务层的 id 也可以。
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
