某种程度上与Elasticsearch查询重复，以返回所有记录。但是我们可以添加更多细节来解决开销问题。（即，“拍摄不需要的快照似乎有点受欢迎。”）

一个滚动扫描搜索，绝对是你在这种情况下，想要的东西。这里的“快照”并不是很多开销。该文档将其隐喻地描述为“ 像 时间快照
一样 ”（添加了重点）。实际的实现细节有些微妙，也很聪明。

稍后在文档中会提供更详细的说明：

通常，后台合并过程通过将较小的段合并在一起以创建新的较大的段来优化索引，然后删除较小的段。在滚动过程中，此过程将继续进行，但是打开的搜索上下文可防止旧段在使用中时被删除。通过这种方式，Elasticsearch可以返回初始搜索请求的结果，而不管对文档的后续更改如何。

因此，保留上下文便宜的原因是因为Lucene索引段的行为。Lucene索引分为多个段，每个段就像一个独立的迷你索引。随着文档的添加（和更新），Lucene会简单地将新段添加到索引。段是一次写入的：创建段之后，就不会再对其进行更新。

随着时间的流逝，随着细分市场的积累，Lucene将在后台定期进行一些内务处理。它扫描这些段并合并这些段以刷新已删除和过时的信息，最终合并为一小组较小的较新且最新的段。随着新的合并段替换旧的段，Lucene将删除所有不再被索引有效使用的段。

这种分段索引设计是Lucene比简单的B树更具性能和弹性的原因之一。从长远来看，连续添加段比直接在磁盘上更新文件的累积IO便宜。再加上一次写入设计具有其他有用的特性。

Elasticsearch在这里使用的类似于快照的行为是在滚动搜索开始时维护对所有活动段的引用。因此开销是最小的：一些文件的引用。另外，随着索引的不断更新，这些文件在磁盘上的大小可能也会增加。

如果 磁盘空间是服务器上的严重问题， 那么 这 可能
是一笔昂贵的开销。可以想象的是，在滚动搜索上下文处于活动状态时，索引被足够快地更新可能是索引所需磁盘大小的两倍。为此，确保您有足够的容量以使索引可能增长到其预期大小的2-3倍是有帮助的。
__