search - ElasticSearch-更新还是新索引？

Question

要求:

每个星期都要删除的一堆平面文件需要构建一个ElasticSearch索引

除了这个每周的feed之外，我们还获得间歇性的diff文件，提供的数据不是原始feed的一部分(插入或更新，不删除)。

将这些文件(每周完整提要或diff文件)解析并加载到ElasticSearch中的时间不是很长

连续两周收到的每周提要预计会有显着差异(删除，添加，更新)

索引对于应用程序正常运行至关重要，它的停机时间必须接近于零

我们不关心提要中所做的确切更改，但是如果当前加载由于某种原因失败，我们需要具有回滚到先前版本的能力

要说清楚，搜索需要快速且响应迅速

鉴于这些要求，我们计划执行以下操作:

对于增量更新(diff)，我们可以使用批量API

原样插入或更新记录

要进行全面更新，我们将重建一个新索引并按此post中所述交换别名。如果发生回滚，我们可以恢复到以前的工作索引(如果回滚需要回退几个版本，则也将保留备份)

问题:

这是最好的方法，还是在重建索引时使用内置版本控制对先前创建的索引进行CRUD文档更好？

将数据修改(删除，更新)到底层的lucene索引/碎片有什么影响？修改会导致碎片化或效率低下吗？

Answer 1

乍一看，我想说您的总体做法是合理的。如果需要，每周使用新数据创建一个新索引并交换别名是一个好方法

零停机时间和

可以出于任何原因回退到先前的索引

如果只保留一个索引并在其中对文档进行CRUD，则如果出现任何问题，将无法回滚，并且最终可能会混入当前周的数据和一周前的数据。

每次更新(甚至是一个字段)或删除文档时，先前的版本都会在基础Lucene段中标记为已删除。当Lucene段已经足够大时，ES将合并它们并清除已删除的文档。但是，在您的情况下，由于您每周都会创建一个索引(并最终从前一周删除该索引)，因此您不会陷入空间和/或碎片问题的情况。