ElasticSearch search_after， from&size，scroll

对于三者：

1. from / size : 该查询的实现原理类似于mysql中的limit，比如查询第10001条数据，那么需要将前面的10000条都拿出来，进行过滤，最终才得到数据。(性能较差，实现简单，适用于少量数据，并且elastic默认from+size < 10000)。
2. scroll：该查询实现类似于消息消费的机制，首次查询的时候会在内存中保存一个历史快照以及游标(scroll_id)，记录当前消息查询的终止位置，下次查询的时候将基于游标进行消费(性能良好，维护成本高，在游标失效前，不会更新数据，不够灵活，一旦游标创建size就不可改变，适用于大量数据导出或者索引重建)
3. search_after: 性能优秀，类似于优化后的分页查询，历史条件过滤掉数据。官方文档上建议使用这种方式。

 

注意点：

from / size

使用方法很简单，直接设置from和size，但是有一个限制，就是from+size < index.max_result_window（index.max_result_window默认为10000），也就是说请求查询超过10000就会报500错误。

 

scroll

虽然能够解决from size带来的问题，但是不是针对实时用户请求，而是针对处理大量数据

 

search_after

1. 使用时，该参数from必须设置为0或-1。

2. search_after不是自由跳转到随机页面而是并行滚动许多查询的解决方案。它与scrollAPI 非常相似，但与它不同，search_after参数是无状态的，它总是针对最新版本的搜索器进行解析。因此，排序顺序可能会在步行期间发生变化，具体取决于索引的更新和删除。

3. 必须要设置sort，sort参数里必须至少使用一个唯一的字段来进行排序。官方文档里面的例子使用了两个排序：

GET twitter/_search
{
    "size": 10,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "search_after": [1463538857, "654323"],
    "sort": [
        {"date": "asc"},
        {"tie_breaker_id": "asc"}
    ]
}