有效地获取弹性搜索索引中的所有文档

我想从elasticsearch集群中的全匹配查询中获取所有结果.我不在乎结果是否是最新的,我不关心订单,我只想稳定地继续检查所有结果,然后在开始时重新开始.滚动和扫描是最好的,这似乎有点受欢迎拍摄我不需要的快照.我将关注处理数百万份文档.

弹性搜索查询的一些重复,以返回所有记录.但我们可以添加更多细节来解决开销问题.(即,"我不需要拍摄快照似乎有点受欢迎.")

一个滚动扫描搜索,绝对是你在这种情况下,想要的东西."快照"在这里不是很多开销.该文档将其描述为" 像时间快照"(强调添加).实际的实现细节有点微妙,而且非常聪明.

稍后将在文档中进行更详细的说明:

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

因此上下文保持廉价的原因在于Lucene索引段的行为方式.Lucene索引被划分为多个段,每个段都像一个独立的迷你索引.随着文档的添加(和更新),Lucene只需在索引中添加一个新段.细分是一次性写入:创建后,它们永远不会再次更新.

随着时间的推移,随着细分市场的积累,Lucene将定期在后台进行一些内务管理.它扫描段并合并段以刷新已删除和过时的信息,最终合并为更小的更新和更新的段.随着较新的合并细分市场取代旧细分市场,Lucene将逐步删除整个索引不再使用的任何细分市场.

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

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

如果磁盘空间是服务器上的一个严重问题,这可能是一个昂贵的开销.可以想象,当滚动搜索上下文处于活动状态时索引快速更新可能会使索引所需的磁盘大小增加一倍.为此,确保您拥有足够的容量以使索引可能增长到预期大小的2-3倍是有帮助的.