DevOps知识中心
DevOps知识中心

Elasticsearch 分片容量规划指南：平衡性能与可扩展性

通过优化分片容量来掌握 Elasticsearch 性能调优。本指南详细阐述了查询速度、索引吞吐量和资源利用率之间的关键权衡。您将学习实用的方法，包括如何计算理想的主分片数量、如何利用索引生命周期管理 (ILM) 处理时间序列数据，以及如何避免因管理过多或过少分片而产生的常见陷阱。

35 浏览量

Elasticsearch 分片大小调整指南：平衡性能与可伸缩性

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

本指南提供了一个实用的框架，用于确定 Elasticsearch 集群中的最佳分片大小。我们将探讨查询性能、索引吞吐量、集群弹性与资源消耗之间的关键权衡，以帮助您为特定工作负载找到完美的平衡点。

理解 Elasticsearch 分片

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

主分片与副本分片

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

分片数量的影响

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

关键限制和大小调整建议

对于分片大小没有一个“万能数字”。最佳大小严重依赖于您的数据量、索引速率和查询模式。然而，Elasticsearch 文档和社区最佳实践提供了几项关键指导。

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

最重要的因素是单个分片内包含的数据量。

  • 推荐最大大小： 普遍共识和最佳实践建议将单个主分片保持在 10GB 到 50GB 之间。
  • 绝对最大值： 尽管技术上可行，但强烈不建议单个分片超过 100GB，因为它会给恢复操作、索引性能和集群稳定性带来巨大压力。

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

2. 文档数量阈值

尽管大小是首要考虑因素，但文档数量也很重要，特别是对于非常小的文档。

  • 推荐文档范围： 目标是每个分片包含 100,000 到 500 万个文档。

如果您的文档非常小（例如，几百字节），您可能在达到文档数量建议之前就达到了大小限制（50GB）。反之，如果文档非常大（例如，多兆字节的 JSON blob），您可能在保持在大小限制以下时很快就达到了文档数量限制。

3. 集群开销和分片数量

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

  • 每 GB 堆内存的分片数量： 一个常见的指导原则是，总分片数量（主分片 + 副本分片）应使得集群大约使用数据节点分配的每 1GB 堆内存对应 20 个分片。

计算示例： 如果您的数据节点分配了 30GB 堆内存：

$$30 \text{ GB} \times 20 \text{ shards/GB} = 600 \text{ total shards}$$

如果您需要为某个索引创建 100 个主分片，您应该确保集群有足够的节点，以便根据此比例保持总开销可控。

实用的分片大小调整方法

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

步骤 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：跨节点分布

确保您的集群有足够的节点（和足够的堆空间）来有效托管这些分片，并保持“每 GB 堆内存 20 个分片”的规则。

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

Elasticsearch 不支持调整现有非空索引的主分片数量。这是初始设计时需要记住的一个关键限制。

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

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

您不是创建一个庞大、难以管理的索引，而是创建一个指向模板的滚动更新别名。

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

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

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

如果现有索引由于不可预见的数据模式而远超 50GB 的建议，您必须使用 Reindex API 来修复分片分布：

  1. 创建具有正确（最佳）分片配置的新索引。
  2. 使用 Reindex API 将所有数据从旧的、大小不当的索引复制到新索引中。
  3. 更新别名以指向新索引。
  4. 删除旧索引。

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

最佳实践总结

区域 最佳实践 / 指南
单个分片大小 将主分片保持在 10GB 到 50GB 之间（最大 100GB）。
文档数量 每个分片目标为 10 万到 500 万文档（次要于大小）。
集群开销 将数据节点上的总分片数量（主分片 + 副本分片）限制在每 1GB 堆内存大约 20 个分片。
索引管理 对于时间序列数据，使用索引生命周期管理 (ILM) 和滚动更新 (Rollover) 以确保持续的最佳大小。
大小调整 不要尝试更改活动索引的主分片数量；使用 Reindex API 将数据迁移到大小正确的新索引。

通过遵循这些大小调整指南并利用 ILM 进行持续管理，您可以确保您的 Elasticsearch 集群保持高性能、可伸缩性，并能抵御操作故障。