Elasticsearch：如何根据场景合理调整分片数量？

合理调整分片数量是 Elasticsearch 集群运维中最关键的决策之一。分片数量在索引创建后无法直接修改（主分片数），因此必须在创建前根据业务场景进行精准规划。如果规划失误，后期只能通过“重建索引”（Reindex）来修正，成本极高。

以下是根据不同场景调整分片数量的详细指南、计算公式和最佳实践。

---

一、核心原则：黄金法则

在深入具体场景前，请牢记以下三个核心原则：

1. 分片大小适中：

   • 推荐范围：单个分片大小控制在 10GB ~ 50GB 之间。
   • 下限：避免小于 1GB 的分片（会导致元数据过大，合并开销高）。
   • 上限：避免大于 50GB 的分片（恢复时间长，单点查询压力大，Lucene 内部结构效率下降）。
   • 例外：冷数据归档可以更大（100GB+），高频实时日志可以稍小（但建议不低于 5GB）。

2. 分片数 = 节点数 × (CPU核数因子)：

   • 为了充分利用并行能力，分片总数应略多于数据节点的核心总数。
   • 经验公式：总分片数 ≈ 数据节点数 × 每节点CPU核数 × (1 ~ 3)。
   • 例如：3 个节点，每个节点 8 核，总分片数建议在 24 ~ 72 之间。

3. 预留增长空间：

   • 分片数一旦设定不可减少。如果你预计数据量会增长 10 倍，不要只按当前数据量计算，要按未来 6-12 个月的预期数据量来规划。

---

二、不同场景的分片策略

1. 日志存储场景 (Logging / Time-Series)

• 特征：写多读少，数据按时间写入，旧数据很少被修改，通常按天/周滚动删除。
• 策略：基于时间滚动 (Rollover) + 固定分片数。
• 计算方法：
  1. 估算单日数据量（例如：50GB/天）。
  2. 确定保留周期（例如：保留 7 天）。
  3. 设定单分片目标大小（例如：30GB）。
  4. 单索引分片数 = ceil(单日数据量 / 单分片目标大小)。
     • 例：ceil(50GB / 30GB) = 2 个分片。
  5. 操作：每天创建一个新索引（如 logs-2023.10.01），设置 2 个主分片。使用 ILM (Index Lifecycle Management) 自动管理滚动和删除。
• 优点：每个索引大小可控，删除旧数据只需 drop 整个索引，效率极高。

2. 实时搜索场景 (E-commerce / Product Search)

• 特征：读写均衡，对延迟敏感，数据持续累积，需要频繁更新商品详情。
• 策略：单一大索引 (或按月滚动) + 预估总容量。
• 计算方法：
  1. 估算未来 1 年的总数据量（例如：500GB）。
  2. 设定单分片目标大小（例如：30GB，搜索场景稍大一点有利于缓存）。
  3. 总主分片数 = ceil(总数据量 / 单分片目标大小)。
     • 例：ceil(500GB / 30GB) = 17 个分片。
  4. 校验节点能力：确保集群数据节点的核心数能支撑 17 个分片的并发查询。如果只有 3 个节点（共 24 核），17 个分片是合理的。
• 注意：如果数据量增长超预期，只能 Reindex 到新的大索引中。

3. 聚合分析场景 (Analytics / Metrics)

• 特征：写入后几乎不更新，查询主要是大范围聚合（Aggregations），扫描全量数据。
• 策略：少量大分片。
• 原因：聚合操作需要在协调节点合并所有分片的结果。分片越多，网络传输和内存排序的开销越大。
• 计算方法：
  • 可以将单分片目标大小提升至 40GB - 60GB。
  • 尽量减少分片总数，只要保证写入时能跑满磁盘带宽即可。

4. 冷数据归档场景 (Cold / Archive)

• 特征：极少访问，仅用于合规审计，存储在廉价磁盘。
• 策略：Force Merge 到 1 个分片。
• 操作：
  1. 初始写入时可按正常策略分片（为了写入速度）。
  2. 当数据变为“冷”数据（如超过 3 个月），使用 ILM 触发 Force Merge 操作，将多个分片合并为 1 个大分片。
  3. 这能极大减少文件句柄占用，提高顺序读取速度，节省存储空间。

---

三、动态调整方案 (当预估失败时)

由于主分片数不可变，如果初期规划错误（分片太小或太大），必须采用以下方案调整：

方案 A：重新索引 (Reindex) —— 最通用

将数据从旧索引迁移到新索引（新索引配置了正确的分片数）。

POST _reindex
{"source": { "index": "old_index" },"dest": { "index": "new_index_with_correct_shards" }
}

• 缺点：耗时，需要双倍存储空间，期间可能需要停止写入或使用别名切换。

方案 B：滚动索引 (Rollover) —— 日志场景推荐

如果不希望手动 Reindex，可以在创建索引时使用 Alias (别名) + Rollover 机制。

1. 创建一个别名 logs-write 指向 logs-000001。
2. 设置条件：当 logs-000001 达到 30GB 或 1 天时，自动滚动创建 logs-000002。
3. 关键点：你可以在 Rollover 策略中定义新索引的分片数。这意味着你可以随着集群扩容，动态调整新生成索引的分片策略（虽然不能改变旧索引，但可以控制未来的分片大小）。

方案 C：Shrink API (仅适用于减少分片)

如果你的分片太多且太小，且满足特定条件（所有文档的路由值相同，或者通过特定路由使得数据可以合并），可以使用 _shrink API 将多个分片合并为一个。

• 限制：只能减少分片数（如 4 -> 2 -> 1），不能增加。且源索引必须只读。

---

四、计算实例演示

假设你有一个电商集群，配置如下：

• 节点：3 个 Data Node。
• 配置：每个节点 8 CPU, 32GB RAM。
• 数据增长：预计每月新增 20GB 订单数据，需保留 2 年（480GB）。

步骤 1：确定单分片大小
搜索场景，取中间值 30GB。

步骤 2：计算所需总分片数
总分片数 = 480GB / 30GB = 16 个分片。

步骤 3：验证集群承载能力

• 集群总 CPU 核数 = 3 * 8 = 24 核。
• 分片数 (16) < 总核数 (24)，且每个节点平均承担 ~5.3 个分片。
• 结论：合理。每个分片都能获得足够的 CPU 时间片进行查询和合并。

步骤 4：决策

• 方案一（单索引）：创建一个 orders 索引，设置 number_of_shards: 16。适合查询跨所有历史数据。
• 方案二（按月滚动）：创建 orders-2023-01 等。
  • 每月数据 20GB。
  • 若设 1 个分片：20GB < 30GB，略小但可接受。
  • 若设 2 个月合并一次：40GB / 30GB ≈ 1.3 -> 2 个分片。
  • 推荐：按月滚动，每月 1 个分片（20GB）。虽然略小于 30GB 下限，但在可接受范围内，且方便按月删除旧数据。如果担心分片太小，可以双月滚动（每两个月一个索引，设 1-2 个分片）。

---

五、避坑指南 (Checklist)

在最终敲定分片数前，请问自己以下问题：

1. 是否考虑了副本？
   • 总主分片数是 16，如果副本设为 1，实际物理分片数是 32。确保集群资源能扛住 32 个分片的负载。
2. 是否有“热点”问题？
   • 如果使用了自定义 Routing（如按用户 ID 路由），可能导致数据分布不均，某些分片极大，某些极小。此时需要增加总分片数以稀释热点。
3. 未来扩容计划？
   • 如果计划明年加 2 台机器，现在的分片数是否足以利用新机器？（分片数 > 当前节点数，才能在未来扩容时自动平衡）。
4. 是否使用了 ILM？
   • 强烈建议配合 Index Lifecycle Management (ILM)。它可以自动在 Hot 阶段使用较多分片（优化写入），在 Warm/Cold 阶段 Force Merge 减少分片（优化存储和查询）。

总结公式

推荐主分片数 = Max( ceil(预估总数据量 / 30GB), 数据节点数 )

• 如果计算结果远大于节点数，说明数据量巨大，需确认集群规模。
• 如果计算结果小于节点数，建议至少设置为节点数（保证每个节点都有数据，负载均衡），或者接受部分节点空闲。
• 永远不要为了“以后可能用得上”而设置几百个分片，小分片是集群性能的头号杀手。