有效获取elasticsearch索引中的所有文档

我想从 Elasticsearch 集群中的所有匹配查询中获取所有结果。我不关心结果是否是最新的，也不关心顺序，我只想稳步地继续检查所有结果，然后从头开始。滚动和扫描最适合这种情况吗？拍摄我不需要的快照似乎有点麻烦。我将考虑处理数千万个文档。

有点重复elasticsearch查询返回所有记录 https://stackoverflow.com/questions/8829468/elasticsearch-query-to-return-all-records。但我们可以添加更多细节来解决开销问题。 （即，“拍摄我不需要的快照似乎有点受打击。”）

A 滚动扫描搜索 http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-scroll.html在这种情况下绝对是您想要的。这 “快照”在这里并没有太多开销。该文档将其比喻为“like及时的快照”（强调是添加的）。实际的实现细节有点微妙，而且相当聪明。

文档后面有更详细的解释：

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

因此，上下文的保存成本较低的原因是 Lucene 索引段的行为方式。 Lucene 索引被划分为多个段，每个段就像一个独立的迷你索引。当添加（和更新）文档时，Lucene 只是将一个新段附加到索引中。段是一次性写入的：创建后，就不再更新。

随着时间的推移，随着段的积累，Lucene 将定期在后台进行一些内务处理。它扫描段并合并段以刷新已删除和过时的信息，最终合并为较小的一组更新鲜和更新的段。当新的合并段替换旧段时，Lucene 将删除所有索引不再主动使用的段。

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

Elasticsearch 此处使用的类似快照的行为是为了在滚动搜索开始时维护对所有活动段的引用。因此开销很小：对少数文件的一些引用。另外，也许还有磁盘上这些文件的大小，因为索引会随着时间的推移而更新。

This may是一笔昂贵的管理费用，if磁盘空间是服务器上的一个严重问题。可以想象，当滚动搜索上下文处于活动状态时，索引的更新速度足够快，可能会使索引所需的磁盘大小增加一倍。为此，确保拥有足够的容量是很有帮助的，这样索引就可以增长到其预期大小的 2-3 倍。