【问题标题】:Adding new documents to production Elasticsearch cluster将新文档添加到生产 Elasticsearch 集群
【发布时间】:2021-10-29 19:19:47
【问题描述】:

我的 Elasticsearch 集群经常被搜索查询使用。每周一次,我会收到一批需要添加到索引中的新文档。如果我将它们添加到索引中,它将在索引和合并或移动分片时大大降低搜索速度。 避免减速的最佳方法是什么?

到目前为止我的解决方案:

1. Spin up a single node empty elastic.
2. Restore index i need to update from a snapshot.
3. Add new documents to this index.
4. Force merge shards
5. Snapshot resulting index.
6. Restore updated index on production cluster.
7. Update aliases to use updated index and delete old index.

我认为从快照恢复不应该占用太多资源。可能需要预热恢复的索引以获得更好的性能。

是正常的解决方案还是太复杂了?

Elasticsearch 是否有适当的方法来添加文档而不会造成停机或集群减速?

【问题讨论】:

  • 你如何定义“减速”?你的参考基准是什么?您能详细介绍一下您的设置吗?
  • 好吧,“减速”是温和的说法,我不能在添加新文档的过程中对索引运行 _count 请求,甚至不能说运行复杂的查询。可能索引速度太快了。但是在使用时仍然更改索引对我来说是个坏主意。
  • 你的设置是什么?数据量等?
  • 10 节点集群(1 正在协调)。总共 900Gb RAM,160 个 CPU 内核,5Tb 总索引大小(每个索引大约 50-500Gb)
  • 5TB 的 10 个节点就足够了……但是 500GB 索引?有多少主/副本分片?

标签: elasticsearch


【解决方案1】:

500GB 在一个主分片上,我会在做任何其他事情之前明确解决这个问题。您有 10 个节点,因此您需要将负载分散到所有节点上。添加节点根本没有帮助。

official recommendation 是为了不让分片大于 10/50GB。因此,在您的情况下,我将 split that index 拥有 10 个主分片(每个 +1 个副本),以便每个节点都可以处理部分工作。否则,总是只有一个节点在做写工作,两个节点在做读工作,这不是最优的。

因此,在想出规避问题的方法之前,请按照我上面的描述解决问题。您的集群会好很多,因为 10 个节点肯定可以轻松处理 5TB,而不必像您列出的那样采用复杂的更新过程。

试试看……

【讨论】:

  • 对不起,我误读了你关于分片的问题,以为你在问每个索引有多少副本。我正在尝试拥有大约 20Gb 大小的碎片。同样,整体性能还可以,问题是何时需要更新这些索引。
猜你喜欢
  • 2021-05-10
  • 1970-01-01
  • 2015-07-31
  • 1970-01-01
  • 2016-06-13
  • 2019-12-31
  • 2018-08-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多