ElasticSearch-更新还是新索引？

要求：

• 一个单一的ElasticSearch索引需要从每周丢弃的一堆平面文件中构造出来
• 除了这个每周提要之外，我们还获得了间歇性的diff文件，提供了不属于原始提要的附加数据（插入或更新，不删除）
• 解析这些文件（每周完整提要或diff文件）并将其加载到ElasticSearch中的时间不是很长
• 连续两周内收到的每周提要预计会有显著差异（删除、添加、更新）
• 该索引对于应用程序的正常运行至关重要，它需要有接近零的停机时间
• 我们不关心在提要中所做的确切更改，但我们需要能够回滚到以前的版本，以防当前加载由于某种原因失败
• 为了说明显而易见的问题，搜索需要快速响应

鉴于这些要求，我们计划做以下工作：

对于增量更新（diff），我们可以使用批量API插入或更新记录

对于完整更新，我们将重建一个新索引，并按照本文所述交换别名。在回滚的情况下，我们可以恢复到以前的工作索引（如果回滚需要返回几个版本，也会维护备份）

问题：

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

修改基础lucene索引/碎片的数据（删除、更新）有什么影响？修改是否会导致碎片化或效率低下

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

• 零停机时间和
• 无论出于何种原因，都能够回滚到以前的索引

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

每次更新（甚至一个字段）或删除文档时，在底层Lucene段中，以前的版本都会标记为已删除。当Lucene片段足够大时，ES将合并它们并删除删除的文档。但是，在您的情况下，由于您每周都要创建一个索引（并最终删除前一周的索引），因此不会出现空间和/或碎片问题

---

他的数据每周都会相似，每周创建一个类型（例如，week1、week2…等等）而不是每次创建完整的索引，这会是一个非常糟糕的主意吗is@asettouf请看另一个答案：（提示：类型正在消失）谢谢（再次）Val:）关于碎片的问题是针对对现有索引执行CRUD的场景。换言之，我试着看看，如果坚持使用单个索引并对其进行批量更新和删除（使ES努力跟上数据组织，而用户则在对索引进行重击以获取数据），是否还有其他缺点。当使用单个索引时，更难保证数据始终一致，特别是如果你每周的批量更新在中间崩溃。无论如何，假设您的每周更新总是成功的，那么碎片可能永远不会成为问题。再说一遍，我们讨论了多少文档，你的硬件规格，等等