时间戳

首页 > 解决方案 > Elasticsearch 作为缓存，重建索引还是就地更新？

elasticsearch - Elasticsearch 作为缓存，重建索引还是就地更新？

问题描述

我使用 Elasticsearch 作为电子商务目录中产品的缓存/搜索索引。某些事件（包括但不限于批量产品更新）可能导致全部或大部分文档需要重新索引。我想我有两个选择：

选项 A：更新受影响的文档。

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

我对这些方法的问题：

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

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

我想其他因素，例如索引的大小和重建需要多长时间也起作用，但我实际上正在处理许多独立的产品目录/索引，这些目录/索引的大小从不到 1000 个文档到超过一百万个不等，所以我的目标是提出一个可能对每个人都有效的通用策略。提前致谢。

标签： elasticsearch

解决方案

这是一个有趣的问题，但 IMO 并非易事。

为什么要创建新索引？跳过替换文档的合并（因为 Elasticsearch 中没有就地更新，因为 Lucene 写入数据是不可变的）。

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

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

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

  • 10K 甚至 100K 文档
  • 命中至少 1/3 的文档（也可能是 1/2 — 这只是一个猜测）。

推荐阅读