elasticsearch scroll查询的原理没太懂

Elasticsearch | 作者 code4j | 发布于2017年11月28日 | 阅读数：33316

网上看了好多说es游标查询的，但大多就是说和mysql游标一样，对查询条件的数据做快照然后后续只从快照取。

感觉说的还是有点抽象，我说下我的问题：

1.如果第一次查询要取全部查询数据的快照的话，假设全部匹配的数据有10w条，那这scroll的第一步拉取快照的这一步，和正常分页size=10000 有什么区别？不一样会吃很多内存？

2.滚动的第一步汇总结果排序一样也很消耗内存，说白了和1一样，只不过是不做限制了，甚至会取到更多的数据（比如普通分页取1w条，实际上结果可能有10w条，换成滚动的话第一次就会取结果为10w的快照了）

最后顺便问一问，滚动查询生产环境下什么场景适合用，频率多大比较合适呢？

4 个回复

kennywu76 - Wood

赞同来自: lunatictwo 、shandian811 、derobukal 、bng 、lbx6z 、sgven 、cccthought 、Haruhi_ 、PeterQ 、tsanko 、Merrizee 、shengtu0328 、yiming666 、carrd2008 、smalldemon 、YuLiGod 更多 »

ES的搜索是分2个阶段进行的，即Query阶段和Fetch阶段。 Query阶段比较轻量级，通过查询倒排索引，获取满足查询结果的文档ID列表。而Fetch阶段比较重，需要将每个shard的结果取回，在协调结点进行全局排序。通过From+size这种方式分批获取数据的时候，随着from加大，需要全局排序并丢弃的结果数量随之上升，性能越来越差。

而Scroll查询，先做轻量级的Query阶段以后，免去了繁重的全局排序过程。它只是将查询结果集，也就是doc id列表保留在一个上下文里，之后每次分批取回的时候，只需根据设置的size，在每个shard内部按照一定顺序（默认doc_id续)，取回这个size数量的文档即可。

由此也可以看出scroll不适合支持那种实时的和用户交互的前端分页工作，其主要用途用于从ES集群分批拉取大量结果集的情况，一般都是offline的应用场景。比如需要将非常大的结果集拉取出来，存放到其他系统处理，或者需要做大索引的reindex等等。

参考: https://www.elastic.co/guide/c ... .html