分片规模为什么重要
分片数量与大小同时影响恢复速度、集群状态的体积与聚合并行度：分片太大，单分片恢复慢、读写热点集中；分片太多，集群状态膨胀、每个请求的固定开销被放大。常见经验是单分片控制在十几到几十 GB，每 GB 堆内存承载的分片数保持在 20 个以内（含副本）。
怎么持续控制规模
与其一次算准，不如让机制自动收敛：生命周期策略的滚动条件里用 max_primary_shard_size 按主分片大小触发新索引，比按天数或文档数更贴近真实数据量。再定期用 _cat/indices 与 _cat/allocation 观察分片与磁盘分布，发现不均衡时先查分配规则与磁盘水位。
基本信息
| 单分片大小 | 常见经验区间 10GB 到 50GB，按查询模式与硬件调整 |
|---|---|
| 每 GB 堆分片数 | 经验上保持在 20 个以内（含副本） |
| 副本作用 | 查询扩展与节点故障容错，代价是成倍的存储与写入 |
| 自动化手段 | ILM 用 max_primary_shard_size 触发滚动 |
| 观察入口 | _cat/indices、_cat/allocation |
示例
示例
# 各索引的分片数与主分片占用，按大小排序
GET /_cat/indices?v&h=index,pri,rep,pri.store.size&s=pri.store.size:desc
# 各节点的分片数量与磁盘使用
GET /_cat/allocation?v&s=shards:desc
# 生命周期滚动条件：主分片超过 40GB 就滚动出新索引
PUT _ilm/policy/logs-policy
{ "policy": { "phases": { "hot": { "actions": { "rollover": { "max_primary_shard_size": "40gb" } } } } } }典型使用场景
- 新建索引前估算分片数：按预期数据量与单分片目标大小计算
- 旧集群治理：找出超大分片与碎片化严重的小索引
- 恢复时间预估：分片越大恢复越慢，恢复目标要靠分片规模兜住
- 节点不均衡：分片数与磁盘占用差异大时检查分配规则
- 日志类索引：用滚动与删除策略替代人工按天建索引
现象与处理方向
| 现象 | 指向的问题 | 处理方向 |
|---|---|---|
| 单分片几十上百 GB | 恢复慢、热点集中 | 按大小滚动，或 reindex 拆分到大分片数的新索引 |
| 分片数上万 | 集群状态大、主节点压力高 | 合并小索引，控制单位时间内的建索引数量 |
| 每 GB 堆分片数偏高 | 固定开销大、堆吃紧 | 减少分片数或增加堆 |
| 节点间分片数差异大 | 分配不均衡 | 检查分配过滤规则与磁盘水位 |
分片太大会让单分片恢复变慢、热点集中；分片太多则集群状态膨胀、每类请求的固定开销放大，两头都要避免，别只盯着其中一个方向。
减少主分片数不能原地完成，必须借助 shrink 或新建索引后 reindex 再切换别名，操作前要评估耗时、双份存储空间与回滚方式。