elasticsearch - Elasticsearch作为缓存，是否重建索引与更新？

Question

我将Elasticsearch用作电子商务目录中产品的缓存/搜索索引。某些事件(包括但不限于批量产品更新)可能导致文档的全部或很大一部分需要重新索引。我认为我有2个选择:

选项A:就地更新受影响的文档。

选项B:创建一个新索引，继续使用旧索引来提供查询，直到完全构建新索引，然后将应用程序指向新索引。

我对这些方法的疑问:

即使选项B中的两个索引都位于同一群集中并因此共享诸如RAM和CPU之类的物理资源，选项A在进行更新时是否会比“选项B”对“实时”查询更具破坏性？

如果可以，这里是否有合理的经验法则，例如“如果少于x％的文档需要更新，则使用选项A，否则使用选项B”？

我想象其他因素(例如索引的大小以及重建所需的时间)也会发挥作用，但是实际上我正在处理许多独立的产品目录/索引，其大小从1000个以下文档到一百万个以上不等，因此我的目标是提出一种可能适合所有人的通用策略。提前致谢。

Answer 1

这是一个有趣的问题，但IMO并非无足轻重。

您为什么要创建一个新索引？跳过合并被替换文档的合并(因为Elasticsearch中没有就地更新，因为Lucene不变地写入数据)。

为什么不希望创建新索引？因为更新查询可能要小得多；使用脚本设置/更改一百万个文档中的值，在网络上要比重新发送一百万个文档小得多。

您的选择可能还取决于您的瓶颈。是网络，CPU / RAM还是磁盘？例如，使用选项B，您不必等待合并发生就可以收回磁盘空间，但是可以在创建新索引后立即触发。

我认为该特定场景没有任何基准，但是我的直觉是我只会考虑使用

10K甚至10万个文档

至少打了1/3的文档(也可能是1/2-这只是一个猜测)。