我想从 elasticsearch 集群中的 match-all 查询中获取所有结果。我不在乎结果是否是最新的，也不在乎顺序，我只想稳步地继续遍历所有结果，然后从头开始。滚动和扫描最适合这个，拍摄我不需要的快照似乎有点成功。我将着眼于处理数以千万计的文档。
【问题讨论】：
标签： elasticsearch
有点像elasticsearch query to return all records 的复制品。但是我们可以添加更多细节来解决开销问题。 （即，“拍摄我不需要的快照似乎有点成功。”）
scroll-scan search 在这种情况下绝对是您想要的。这 “快照”在这里并不是很多开销。该文档将其比喻为“like 及时的快照”（已添加重点）。实际的实现细节更加微妙，而且相当巧妙。
稍后会在文档中提供更详细的解释：
通常，后台合并过程通过将较小的段合并在一起以创建新的更大的段来优化索引，此时较小的段被删除。此过程在滚动期间继续，但打开的搜索上下文可防止旧段在仍在使用时被删除。这就是 Elasticsearch 能够返回初始搜索请求结果的方式，而不管后续对文档的更改。
所以上下文保存成本低的原因是 Lucene 索引段的行为方式。一个 Lucene 索引被划分为多个段，每个段就像一个独立的迷你索引。随着文档的添加（和更新），Lucene 只是将一个新段附加到索引中。段是一次性写入的：创建后，它们将不再更新。
随着时间的推移，随着段的积累，Lucene 会定期在后台进行一些内务处理。它扫描段并合并段以刷新已删除和过时的信息，最终合并成更小的一组更新鲜和最新的段。随着新的合并段替换旧段，Lucene 将删除所有不再被整个索引积极使用的段。
这种分段索引设计是 Lucene 比简单的 B-tree 更具性能和弹性的原因之一。从长远来看，连续追加段比直接在磁盘上更新文件的累积 IO 更便宜。此外，一次性写入设计还有其他有用的属性。
Elasticsearch 在这里使用的类似快照的行为是在滚动搜索开始时维护对所有活动段的引用。所以开销很小：一些对少数文件的引用。另外，也许还有磁盘上这些文件的大小，因为索引会随着时间的推移而更新。
这可能是一笔昂贵的开销，如果磁盘空间是服务器上的一个严重问题。可以想象，当滚动搜索上下文处于活动状态时，索引的更新速度足够快，可能是索引所需磁盘大小的两倍。为此，确保您有足够的容量以使索引可能增长到其预期大小的 2-3 倍会很有帮助。
【讨论】：