最佳分片大小：平衡集群性能与管理

Elasticsearch 是一个强大的分布式搜索和分析引擎，它在很大程度上依赖于在节点之间高效管理和分发数据的能力。这种分发的核心组件是分片 (shards) 的概念。分片是索引的更小、可管理的部分，它们的尺寸和分发方式对集群的性能、可伸缩性和可管理性有着深远的影响。本文将深入探讨确定 Elasticsearch 中最佳分片大小的关键考虑因素，帮助您在原始性能和运营开销之间取得适当的平衡。

理解分片大小对于任何 Elasticsearch 部署都至关重要。过多的、过小的分片会导致开销增加，影响节点资源和查询延迟。反之，过少、过大的分片会阻碍可伸缩性，产生热点，并延长恢复操作的时间。本指南将为您提供知识和实用策略，以便在分片分配方面做出明智的决策，从而构建一个更高效、更健壮的 Elasticsearch 集群。

Elasticsearch 分片基础知识

在深入研究分片大小策略之前，掌握基本概念至关重要：

索引 (Index)：文档的集合。在 Elasticsearch 中，一个索引被划分为多个分片。
分片 (Shard)：分发单元。每个分片都是一个独立的 Lucene 索引。一个索引可以包含多个分片，分布在集群的不同节点上。
主分片 (Primary Shard)：创建索引时，会为其分配固定数量的主分片。这些分片是您数据被索引的地方。一旦创建，主分片的数量无法更改。但是，您可以添加更多的副本分片。
副本分片 (Replica Shard)：主分片的副本。它们提供冗余并提高读取吞吐量。如果主分片发生故障，副本可以被提升为主分片。副本分片的数量可以随时更改。

分片如何影响性能

索引性能：每个分片都需要资源来进行索引。分片越多，协调节点（负责管理请求）的开销就越大。然而，如果分片过大，索引单个分片可能会成为瓶颈。
查询性能：搜索请求会被分发到所有相关的主分片。分片数量越多，需要处理的请求就越多，这可能会增加延迟。相反，非常大的分片会导致搜索时间变长，因为 Lucene 需要处理分片内更多的数据。
集群管理：大量分片会增加主节点（负责集群状态管理）的负载。它还影响分片迁移、快照和恢复等操作的开销。
资源利用率：每个分片都会消耗内存和磁盘 I/O。过多的分片可能会耗尽节点资源，导致性能下降或节点不稳定。

分片大小的关键考虑因素

“理想”的分片大小不是一个固定数字；它取决于您的具体工作负载、数据特性和硬件。但是，有几个因素应该指导您的决策：

1. 数据量和增长率

当前数据大小：您的索引当前有多少数据？
增长率：您的数据增长有多快？这有助于预测未来的分片大小。
数据保留策略：您会删除旧数据吗？这会影响活动数据的有效大小。

2. 索引负载

索引速率：您每秒索引多少文档？
文档大小：单个文档的平均大小是多少？
索引吞吐量：您的节点在当前分片配置下能否处理索引负载？

3. 查询模式

查询复杂度：您的查询是简单的关键词搜索还是复杂的聚合？
查询频率：对数据的查询运行频率如何？
查询延迟要求：可接受的响应时间是多少？

4. 集群拓扑和资源

节点数量：您的集群中有多少节点？
节点硬件：CPU、RAM 和磁盘（强烈推荐为 Elasticsearch 使用 SSD）。
每个节点的分片限制：Elasticsearch 对节点可以持有的最大分片数有一个默认限制，以防止性能问题。这由 cluster.routing.allocation.total_shards_per_node（默认为 1000）控制。建议将实际分片数保持远低于此限制。

分片分配最佳实践

1. 目标分片大小

虽然没有万能的数字，但通常建议的目标分片大小在 10GB 到 50GB 之间。这个范围通常代表了良好的平衡。

太小（< 10GB）：可能导致过多的开销。每个分片都有内存占用，并增加了主节点的负载。管理成千上万个微小分片会成为重大的运营负担。
太大（> 50GB）：可能导致性能问题。合并分段、恢复和重新平衡操作需要更长的时间。如果一个大分片发生故障，恢复可能需要相当长的时间。

2. 考虑基于时间的索引

对于时间序列数据（日志、指标、事件），使用基于时间的索引是一种标准且高效的做法。这包括为特定时间段（例如，每日、每周、每月）创建新索引。

示例：与其拥有一个庞大的索引，不如拥有 logs-2023.10.26、logs-2023.10.27 等。
优点：更易于数据管理（通过“索引生命周期管理 - ILM”删除旧索引）、更好的性能（查询通常针对最近的数据），以及可控的分片大小。

3. 实现索引生命周期管理 (ILM)

ILM 策略允许您根据索引的年龄、大小或文档数量来自动化索引管理。您可以为索引定义不同的阶段（热、温、冷、删除）并为每个阶段指定操作，包括更改副本数量、收缩索引或删除它们。

热（Hot）阶段：索引正在被积极写入和查询。最大限度地提高性能。
温（Warm）阶段：索引不再被写入，但仍被查询。可以移至性能较低的硬件，可能具有更少的副本或被收缩。
冷（Cold）阶段：很少被查询。数据可以移至更便宜的存储，具有更少的副本或被冻结。
删除（Delete）阶段：数据不再需要，将被删除。

4. 避免过度分片 (Over-Sharding)

当您的集群大小和数据量对应的分片数量过多时，就发生了过度分片。这是一个常见的陷阱，会导致性能不佳和管理问题。

症状：主节点 CPU 使用率高、集群状态更新缓慢、恢复时间长以及普遍的响应迟缓。
缓解措施：从一开始就规划您的主分片数量。对于基于时间的索引，从每个索引的合理数量的主分片开始（例如，1 或 3）。您可以随时添加副本。

5. 不要过度索引 (Over-Indexing)

同样，避免在不必要时创建过多的索引。每个索引都会增加开销。对于没有自然分区机制的非时间序列数据，请考虑使用具有适当分片数量的单个索引是否足够。

6. 考虑 `number_of_shards` 设置

创建索引时，number_of_shards 参数定义了主分片的数量。此设置在索引创建后不可更改。

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // 示例：3 个主分片
      "number_of_replicas": 1   // 示例：1 个副本分片
    }
  }
}

提示：对于较小的索引或索引索引/查询负载非常低的索引，单个主分片可能就足够了。对于更大、更活跃的索引，3 个或 5 个主分片可以提供更好的分发和弹性，尤其是在您计划稍后拆分索引时（尽管拆分很复杂）。

7. 重新平衡与迁移

Elasticsearch 会自动重新平衡分片，以确保在节点之间均匀分布。但是，如果分片过大，这些操作可能会消耗大量资源且速度缓慢。较小、数量更多的分片有时可以更快地重新平衡，但这被管理更多分片的开销所抵消。

8. 查询性能调优

如果您的查询性能不佳，请评估您的分片策略。考虑：

分片数量：过多的分片会增加协调开销。
分片大小：非常大的分片会减慢分段合并和分片内的搜索速度。
索引设计：您是否使用了合适的映射和分析器？

计算最佳分片数量

没有单一的公式，但这是一个常见的方法：

估算索引在其生命周期内的总数据量。
确定目标分片大小（例如，30GB）。
计算所需主分片数量：总数据量 / 目标分片大小。
向上取整到最接近的整数。这将得到您索引的 number_of_shards。
- 示例：如果您预计有 90GB 的数据并以 30GB 的分片为目标，您将需要 90GB / 30GB = 3 个主分片。
考虑弹性和分发：对于关键索引，可以考虑使用 3 或 5 个主分片，以实现更好的分发和恢复选项，即使您初始数据量并不严格要求。权衡是增加了开销。
保守开始：通常比添加副本比更改主分片数量更容易（后者通常需要重新索引或复杂的变通方法）。如果不确定，请从较少的主分片开始并监控性能。

示例场景：日志分析

假设您正在索引应用程序日志：

数据量：您预计每月有 1TB 的日志。
数据保留：您保留日志 30 天。
目标分片大小：您以 20GB 为目标。
基于时间的索引：您创建每日索引（logstash-YYYY.MM.DD）。每个每日索引将保存大约 1TB / 30 天 ≈ 33GB 的数据。
每个索引的主分片数：考虑到 20GB 的目标和 33GB 的每日数据量，您可能选择每个索引 2 个主分片（33GB / 20GB ≈ 1.65，向上取整到 2）。这确保单个分片保持在您的目标大小范围内。
副本：您决定使用 1 个副本以实现高可用性。
总分片数：在 30 天的保留期内，您将有 30 个索引，每个索引有 2 个主分片和 2 个副本分片，在任何给定时间总共有 60 个主分片和 60 个副本分片。

这种方法使单个分片保持可管理，并通过简单地删除旧索引来实现高效的数据删除。

结论

Elasticsearch 中的最佳分片大小是一个持续的权衡过程。通过理解分片数量、分片大小、索引负载、查询模式和集群资源之间的相互作用，您可以做出明智的决策。优先为时间序列数据使用基于时间的索引，利用 ILM 实现自动化管理，并始终牢记管理分片的运营开销。以 10GB 到 50GB 的分片大小为目标，同时避免过度分片，是一个可靠的起点。定期的监控和性能调优将确保您的 Elasticsearch 集群随着数据的增长，保持高效、可伸缩和弹性。