Elasticsearch 分片和副本应该如何设计？

先说结论

主分片决定数据水平切分，副本提供冗余并可分担查询。分片数要让单分片大小、节点分布和故障恢复时间可控，同时避免大量小分片消耗堆、文件句柄和调度资源；副本数根据可用性、查询吞吐与存储成本选择。

主分片数量不是“节点数乘某个固定值”，应使用真实文档、映射和查询压测估算。

根据保留周期估算总数据与增长，设计 rollover 阈值让分片大小稳定。确保任一数据节点故障后其余节点仍有磁盘和计算余量接收恢复分片，并把副本分布到不同故障域。

每个主分片本质上是独立的 Lucene 索引，写入先形成内存 buffer 和 segment，后台再 merge。分片越多，查询一次需要扇出的 Lucene 实例越多，打开的 segment、文件句柄、线程和 heap 元数据也越多；分片越大，单分片恢复、迁移、merge 和故障重建时间越长。

因此“分片越小越并行”与“分片越大越少开销”之间要平衡。时间序列可以按 rollover 控制单分片规模，而不是先固定一个看似漂亮的每天分片数。

假设每天原始数据 500 GB，压缩和 _source 后约 350 GB，计划保留 30 天，目标单分片 30–50 GB：

总逻辑数据 ≈ 10.5 TB
主分片数 ≈ 210~350（按全周期总量）

实际还要拆成按天/周的索引、考虑副本倍数、磁盘水位、merge 临时空间、快照和故障期间剩余节点容量。不要把理论压缩比直接当生产容量保证，应从真实 mapping 和 _source 测量。

副本第一作用是容灾：主分片故障后可提升为主；第二作用是并行读：搜索请求可在主或副本之间选择。副本越多，读吞吐和故障冗余可能提高，但写入必须复制到更多分片，存储、网络、恢复和 merge 成本同步上升。

副本不能替代备份。误删、错误更新和整个集群损坏会同步到副本，必须使用快照、跨集群复制或可重放原始事件。

配置 allocation awareness 或 zone/rack 感知，避免同一主分片和副本落在同一物理故障域。磁盘水位、节点角色、过滤规则、分片大小和恢复限速都会影响分配；状态黄色通常表示主已分配但副本未分配，红色则有主分片缺失。

恢复期间不要只看“集群状态变绿”，还要看恢复流量对在线查询、磁盘和网络的影响。滚动重启应逐节点操作，保证剩余副本和容量足够。

副本数可动态改；主分片数通常需要 split、shrink 或 reindex 到新索引。split 需要预留分裂因子，shrink 往往要求源索引只读并把分片集中到少数节点。时间序列更推荐通过新索引模板和 alias/数据流切换，避免改造巨型在线索引。

副本数可动态调整，主分片数通常不能直接修改，可通过 split、shrink 或 reindex 到新索引改变。时间序列使用索引模板、ILM 和别名让新索引采用新规划。

更多分片可能提高有限并行度，也会让每次查询扇出更多任务并增加协调开销。副本能提高读吞吐，但写入也必须同步到副本，会增加写放大。

通常表示主分片已分配但部分副本无法分配，常见原因是节点不足、磁盘水位、分配规则或同节点不能放同分片副本。

单节点开发或可重建的临时数据可以，但生产意味着节点故障时主分片不可用，且没有副本分担查询。是否可接受应由 RTO/RPO 和数据是否可从事实源重建决定。

每次查询、恢复、merge 和集群状态管理都要处理更多分片，heap 与文件句柄增加，扇出和长尾更明显。分片数应基于容量与并行需求规划。

不能。写入先由主分片处理，副本复制会增加成本；热点写入需要调整 routing、拆分索引或改变数据模型。