Elasticsearch 中的大分片有哪些风险？

Question

在我的工作场所，我们的每个 ES 索引都配置为恰好有 5 个分片，并且我们不使用 Rollover API 或 ILM。我们的大多数索引都非常小，但我们有一个大型索引，其中每个单独的分片都接近 250 GB。现在正在讨论摄取额外的数据，这将使该索引的大小大约增加一倍。

我正在尝试打破这一点，因为根据我对最佳实践的理解（例如Elastic Co.在这里描述的那些）分片理想情况下应该是<=50GB. My understanding of the risks involved with letting shards get too big:

• 搜索性能下降
• 从失败中恢复更困难/更慢
• ES 在正常操作期间执行集群重新平衡更困难/更慢

这些准确吗？我还应该注意其他风险吗？我还有点担心，由于分片可能会出现大内存问题，整个集群可能会变得不稳定。这是一个有根据的担忧吗？

Answer 1

• 当分片变得太大时，它可能会减慢搜索查询的速度，因为每个查询必须处理更大量的数据。
• 当某个节点发生故障时，Elasticsearch 需要重新分配并恢复该节点的分片。大量分片需要相当长的时间才能恢复，从而增加了集群处于冗余减少和脆弱性增加状态的时间。
• Elasticsearch 集群经常跨节点重新平衡分片，以均匀分布数据和负载。更大的分片使这个过程更加耗费资源和时间
• 大分片可能会导致内存压力，特别是在存储有限的环境中。
• 对于较大的分片，拍摄快照并从中恢复的过程可能会变得更具挑战性和耗时
• 在极端情况下，非常大的分片会增加数据丢失的风险。如果大型分片在节点故障期间损坏或丢失，丢失的数据量可能会很大。

这就是大量碎片的一些不好的一面。在实践中，您可能会面临许多其他问题。所以你应该提前正确规划分片数量。