Elasticsearch 分片大小指南：平衡性能与可扩展性

Elasticsearch 是一个强大的分布式搜索和分析引擎，擅长处理海量数据。然而，要实现最佳性能和稳定性，很大程度上取决于你如何构建数据分布——特别是分片大小。分片是 Elasticsearch 索引的基本构建块；它们决定了数据如何被分区、复制和分布在集群节点上。不正确的分片大小可能导致严重的性能瓶颈、增加运维开销，或者相反，导致资源利用不足。

本 Elasticsearch 分片大小指南为你提供了一种实用的方法，用于选择初始分片数量，并通过实际工作负载指标进行验证。目标不是找到一个完美的数字，而是建立一个随着数据增长仍能保持可恢复、可搜索且经济实惠的分片布局。

理解 Elasticsearch 分片

在深入探讨大小调整之前，理解什么是分片以及它在集群架构中如何运作至关重要。Elasticsearch 中的索引由一个或多个主分片组成。每个主分片都是一个独立的、基于 Lucene 的索引，可以承载数据。

主分片与副本分片

主分片： 这些分片保存实际数据。它们负责索引和搜索操作。当你为索引定义主分片数量时，你决定了数据如何在集群中水平分布。
副本分片： 这些是主分片的副本。它们提供冗余（容错能力），并通过允许查询由主分片和副本分片同时服务来提高搜索吞吐量。

分片数量的影响

分片总数（主分片 + 副本分片）直接影响集群开销。每个分片都需要内存（堆空间）和 CPU 资源来跟踪其状态和元数据。过多的小分片会使主节点不堪重负，并增加集群管理开销，导致性能下降，即使单个分片很小也是如此。

关键约束与大小建议

分片大小没有单一的“神奇数字”。最佳大小在很大程度上取决于你的数据量、索引速率和查询模式。然而，Elasticsearch 文档和社区最佳实践提供了几个关键指南。

1. 大小阈值：最佳分片大小

最关键的因素是单个分片内包含的数据大小。

常见目标范围： 许多生产集群的目标是将主分片保持在 10GB 到 50GB 范围内。
大分片警告： 对于某些仅追加或低查询工作负载，较大的分片可能有效，但它们会增加恢复时间并使重新定位成本更高。在依赖接近或超过 100GB 的分片之前，请进行测试。

为什么有这个限制？ 如果节点发生故障，Elasticsearch 必须重新分配（重新定位或重新复制）存储在该节点上的分片。大分片会显著增加恢复所需的时间，从而延长了弹性降低的时间窗口。此外，Lucene 在管理中等大小的段时性能更好。

2. 文档数量阈值

虽然大小至关重要，但文档数量也很重要，特别是对于非常小的文档。

每个分片没有通用的安全文档数量。一个包含数百万个微小日志文档的分片可能表现良好，而一个包含较少但较大且经过大量分析的文档的分片可能代价高昂。应同时跟踪分片存储大小和工作负载行为，而不是仅依赖文档数量。

3. 集群开销与分片数量

限制每个节点的分片总数，以有效管理资源消耗。

较旧的指南通常使用每 GB 堆内存的分片规则。将这些视为粗略的警告信号，而不是硬性限制。现代 Elasticsearch 的每分片堆开销低于旧版本，但过多的分片仍然会增加集群状态工作、文件句柄、段开销和恢复复杂性。

实用的分片大小调整方法

根据预期的总数据大小，使用以下步骤计算新索引的适当主分片数量。

步骤 1：估算索引总大小

确定你期望此索引在其整个生命周期（例如，6 个月或 1 年）内存储的数据总量。

示例： 我们预计 logs-2024 索引将存储 2 TB 的数据。

步骤 2：定义目标分片大小

根据指南选择一个安全的目标大小（例如，40GB）。

示例： 目标分片大小 = 40 GB。

步骤 3：计算所需主分片数量

将总估计大小除以目标分片大小。始终向上取整到最接近的整数。

$$\text{主分片数量} = \text{向上取整} \left( \frac{\text{索引总大小}}{\text{目标分片大小}} \right)$$

示例计算（2 TB = 2048 GB）： $$\text{主分片数量} = \text{向上取整} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{向上取整}(51.2) = 52$$

在这种情况下，你应该创建具有 52 个主分片 的索引。

步骤 4：确定副本数量

根据你的弹性和搜索量需求决定副本数量。

弹性： 将 number_of_replicas 设置为至少 1（以实现高可用性）。
搜索性能： 如果搜索流量很大，请使用 2 个或更多副本。
示例： 我们选择 1 个副本以实现标准容错。

最终索引设置： 52 个主分片和 1 个副本（总共 104 个分片）。

步骤 5：跨节点分布

确保你的集群有足够的节点、堆内存、磁盘和 I/O 容量来有效承载这些分片。对于副本，Elasticsearch 必须能够将每个副本放置在与主分片不同的节点上。

管理索引生命周期和调整大小

Elasticsearch 不允许你直接更改现有索引的 index.number_of_shards。你可以使用拆分、收缩或重新索引工作流，但每种方法都有要求和运维成本。

索引生命周期管理 (ILM) 的作用

对于时间序列数据（日志、指标），最佳实践是利用索引生命周期管理 (ILM) 和滚动功能。

与其创建一个庞大且难以管理的索引，不如创建一个指向模板的滚动别名。

热阶段： 数据写入当前活动索引。ILM 根据大小或年龄监控此索引（例如，当达到 40GB 时滚动）。
滚动： 当达到阈值时，Elasticsearch 会根据模板（使用计算出的主分片数量）自动创建一个新索引，并将别名切换到指向新索引。旧索引移动到不同阶段（温/冷）。

这种方法允许你在整个数据生命周期中维护大小一致、性能最佳的分片。

何时需要重新分片（高级）

如果由于不可预见的数据模式，现有索引增长到远超 50GB 的建议值，你必须使用重新索引 API 来修复分片分布：

创建一个具有修正后（最佳）分片配置的新索引。
使用重新索引 API 将所有数据从旧的、大小不当的索引复制到新索引。
更新别名以指向新索引。
删除旧索引。

关于重新索引的警告： 重新索引是一项资源密集型操作。应安排在低流量时段进行，并且需要足够的集群资源来处理索引和复制的并发负载。

最佳实践总结

领域	最佳实践/指南
单个分片大小	将主分片保持在 10GB 到 50GB 之间（最大 100GB）。
文档数量	将文档数量作为次要信号进行监控，但通过查询和索引指标进行验证。
集群开销	保持分片数量足够低，以确保堆压力、集群状态更新和恢复保持健康。
索引管理	对时间序列数据使用索引生命周期管理 (ILM) 和滚动，确保持续的最佳大小。
调整大小	不要尝试更改实时索引的主分片数量；使用重新索引 API 将数据迁移到大小正确的新索引。

从一个目标分片大小开始，根据预期数据量计算主分片数量，然后通过负载测试和生产指标进行验证。对于时间序列数据，ILM 滚动通常是保持分片大小可预测且无需持续手动干预的最简洁方法。