search After 比scoll性能强在哪里？

ES为深度分页有scroll search 的方式，官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。那么在实时情况下如果处理深度分页的问题呢？es 给出了 search_after 的方式，这是在 >= 5.0 版本才提供的功能。 这也是本文要重要讲解的内容 基本思想：searchAfter的方式通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景。 思考：那search After 为什么不用产生临时快照之类的存储信息，就能保证滚动顺序读取数据呢？ 每个文档具有一个唯一值的字段应该用作排序规范的仲裁器。否则，具有相同排序值的文档的排序顺序将是未定义的。建议的方法是使用字段_id，它肯定包含每个文档的一个唯一值。 ``` POST twitter/_search { "size": 10, "query": { "match" : { "title" : "es" } }, "sort": [ {"date": "asc"}, {"_id": "desc"} ] } ``` 返回出的结果信息 ``` { "took" : 29, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 5, "relation" : "eq" }, "max_score" : null, "hits" : [ { ... }, "sort" : [ ... ] }, { ... }, "sort" : [ 124648691, "624812" ] } ] } } ``` 上面的请求会为每一个文档返回一个包含sort排序值的数组。这些sort排序值可以被用于 search_after 参数里以便抓取下一页的数据。比如，我们可以使用最后的一个文档的sort排序值，将它传递给 search_after 参数： ``` GET twitter/_search { "size": 10, "query": { "match" : { "title" : "es" } }, "search_after": [124648691, "624812"], "sort": [ {"date": "asc"}, {"_id": "desc"} ] } ``` 注意：当我们使用search_after时，from值必须设置为0或者-1。 search_after缺点是不能够随机跳转分页，只能是一页一页的向后翻，并且需要至少指定一个唯一不重复字段来排序。它与滚动API非常相似，但与它不同，search_after参数是无状态的，它始终针对最新版本的搜索器进行解析。因此，排序顺序可能会在步行期间发生变化，具体取决于索引的更新和删除。