ElasticSearch - 更新或新索引？

Question

要求：

• 单个ElasticSearch索引需要从每周丢弃的一堆平面文件构建
• 除了每周Feed之外，我们还会获得间歇性差异文件，提供不属于原始Feed的其他数据（插入或更新，不删除）
• 将这些文件（每周完整Feed或差异文件）解析并加载到ElasticSearch中的时间不是很大
• 连续两周收到的每周饲料预计会有显着差异（删除，添加，更新）
• 索引对于应用程序运行至关重要，并且需要接近零停机时间
• 我们不关心Feed中的确切更改，但我们需要能够回滚到以前的版本，以防当前加载由于某种原因而失败
• 要说清楚，搜索需要快速响应

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

1. 对于增量更新（差异），我们可以使用批量API
按原样插入或更新记录
2. 对于完整更新，我们将重新构建一个新索引并交换此post中提到的别名。在回滚的情况下，我们可以恢复到以前的工作索引（如果回滚需要返回几个版本，也会保留备份）

问题：

1. 这是最好的方法，还是在重新构建索引时，使用内置版本控制对先前创建的索引的CRUD文档更好？
2. 修改数据（删除，更新）对底层lucene索引/分片有什么影响？修改会导致碎片化或效率低下吗？

Answer 1

1. 乍一看，我说你的整体方法是合理的。如果需要

   ，每周使用新数据创建新索引并交换别名是一种很好的方法
   • 零停机时间和
   • 无论出于何种原因能够回滚到以前的索引

如果您只保留一个索引并在那里CRUD您的文档，那么如果出现任何问题，您将无法回滚，并且您可能最终处于混合状态，其中包含当前周的数据和来自当前数据的数据一周前。

1. 每次更新（甚至单个字段）或删除文档时，先前版本将在基础Lucene段中标记为已删除。当Lucene段增长得足够大时，ES将合并它们并清除已删除的文档。但是，在您的情况下，由于您每周都要创建一个索引（并最终从前一周删除索引），您将无法进入您将拥有空间和/或空间的情况碎片问题。