要求：
- 单个 ElasticSearch 索引需要由一堆每周都会删除的平面文件构建而成
- 除了每周提要之外，我们还获得了间歇性的差异文件，提供不属于原始提要一部分的其他数据(插入或更新，不删除(
- 将这些文件(每周完整提要或差异文件(解析和加载到 ElasticSearch 中的时间不是很大 。
- 预计连续两周收到的每周 Feed 将存在显著差异(删除、添加、更新(
- 该索引对于应用运行至关重要，并且需要具有接近零的停机时间
- 我们不关心提要中所做的确切更改，但我们需要能够回滚到以前的版本，以防当前加载由于某种原因失败
- 显而易见，搜索需要快速且响应迅速。
鉴于这些要求，我们计划执行以下操作：
- 对于增量更新 (diff(，我们可以使用批量 API 按原样插入或更新记录
- 对于完整更新，我们将重建一个新索引并交换别名，如本文所述。在回滚的情况下，我们可以恢复到以前的工作索引(如果回滚需要回滚几个版本，也会保留备份(
问题：
在- 重新构造索引时，这是最佳方法还是使用内置版本控制对以前创建的索引进行 CRUD 文档更好？
- 修改数据(删除、更新(对底层 lucene 索引/分片有什么影响？修改会导致碎片化或效率低下吗？
-
乍一看，我会说你的整体方法是合理的。如果需要，每周使用新数据创建新索引并交换别名是一个好方法
- 零停机时间和
- 无论出于何种原因，都能够回滚到以前的索引
如果您只保留一个索引并将您的文档放在其中，则在出现任何问题时将无法回滚，并且最终可能会与本周的数据和前一周的数据混合在一起。
- 每次更新(即使是单个字段(或删除文档时，以前的版本都会在底层 Lucene 段中标记为已删除。当Lucene段变得足够大时，ES将合并它们并清除已删除的文档。但是，在您的情况下，由于您每周都会创建一个索引(并最终从前一周删除索引(，因此您不会遇到空间和/或碎片问题的情况。