我希望从弹性搜索群集中的全匹配查询中获取所有结果。我不在乎结果是否是最新的，我不关心订单，我只想稳定地继续检查所有结果，然后在开始时重新开始。滚动和扫描是最好的，这似乎有点受欢迎拍摄我不需要的快照。我将关注处理数百万份文件。
答案 0 :(得分：8)
elasticsearch query to return all records的某种重复。但我们可以添加更多细节来解决开销问题。 （即，＆＃34;看起来有点像我不需要的快照。＆＃34;）
在这种情况下，scroll-scan search绝对是你想要的。该 ＆＃34;快照＆＃34;在这里不是很多开销。该文档将其描述为＆＃34; 喜欢时间快照＆＃34; （重点补充）。实际的实现细节有点微妙，而且非常聪明。
稍后会在文档中详细说明：
通常，后台合并过程通过将较小的段合并在一起来创建新的更大的段来优化索引，此时删除较小的段。此过程在滚动期间继续，但打开的搜索上下文可防止旧片段在仍在使用时被删除。这就是Elasticsearch能够返回初始搜索请求的结果，而不管后续的文档更改。
因此保留上下文的原因是Lucene索引段的行为方式。 Lucene索引被划分为多个段，每个段都像一个独立的迷你索引。随着文档的添加（和更新），Lucene只需在索引中添加一个新段。细分是一次性写入：创建后，它们永远不会再次更新。
随着时间的推移，随着细分市场的积累，Lucene将定期在后台进行一些内务管理。它扫描段并合并段以刷新已删除和过时的信息，最终合并为更小的更新和更新的段。随着较新的合并细分市场取代旧细分市场，Lucene将逐步删除索引不再使用的任何细分市场。
这种分段索引设计是Lucene比简单B树更具性能和弹性的原因之一。从长远来看，连续追加段比直接在磁盘上更新文件的累积IO更便宜。另外，一次写入设计还有其他有用的属性。
Elasticsearch在此处使用的类似快照的行为是维护对滚动搜索开始时活动的所有段的引用。因此开销很小：一些文件引用了一些文件。另外，也许是磁盘上这些文件的大小，因为索引会随着时间的推移而更新。
此可能是一个代价高昂的开销，如果磁盘空间是服务器上的一个严重问题。可以想象，当滚动搜索上下文活动时索引被足够快地更新可以使索引所需的磁盘大小加倍。为此，确保您拥有足够的容量以使索引可能增长到预期大小的2-3倍是有帮助的。