elastic 分页与遍历:from,size,search after & scroll api

分布式系统深度分页问题：

页数越深，就会占用越多的内存。就类似mysql 分页一样，越到后面页码性能越差。

search after

怎么解决呢，使用search after 参数就类似于mysql: id>xxx limit 10

1.先获取一个文档id

第一次搜索需要指定sort，并且保证值是唯一的。（可通过把_id加入排序保证唯一性）

2.传入文档id，获取后面文档数据，把sort里的值传到下面这个search_after参数里：

scroll api

scroll 查询 可以用来对 Elasticsearch 有效地执行大批量的文档查询，而又不用付出深度分页那种代价。游标查询允许我们 先做查询初始化，然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor

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

每次查询后输入上一次的scroll id，当你想导出es数据使用scroll api比较合适。

插入数据：

创建快照：

使用scroll_id查询：

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

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

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

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

异常：SearchContextMissingException

SearchContextMissingException[No search context found for id [568]]

原因：scroll设置的时间太短已经超时了，或者上次的请求返回结果中没有_scroll_id字段。