Elasticsearch存储订单数据是否需要按时间拆分多索引？

你算的「单分片建议承载20GB、5个主分片理论上能撑100GB」的逻辑从静态容量阈值上是成立的，但不代表可以长期稳定运行：

• 20GB是官方给出的通用场景建议值，不是硬上限，但当单分片数据量逼近这个阈值时，段合并开销、故障恢复耗时、写入延迟都会明显上涨。真到单分片20GB的程度，节点故障后恢复单个分片可能要十几分钟甚至更久，集群稳定性会明显下降。
• 业务增速往往比初期预估快，单索引的分片数创建后调整成本极高（老版本完全不支持调整分片数，新版本拆分分片的资源开销也非常大），初期按10年容量设的5个分片，很可能三五年就被打满。
• 全量数据存在一个索引里，所有数据操作都会互相影响，比如给老数据做归档、调整字段配置，都会牵连全量订单数据。

你提到的「方便配置数据留存周期」是核心优势之一，除此之外这个方案还有这些实际好处：

• 分片配置灵活：每年新建索引的时候，可以根据当年的实际业务量调整分片数，不会被早年的配置绑死。存放冷数据的老索引还可以直接缩成1个分片，执行force merge成单段，大幅减少资源占用。
• 写入更稳定：所有写入压力全部落在当前年度的最新索引上，老索引完全是只读状态，不会有写入、段合并的资源争抢，新订单的写入延迟不会因为历史数据积累出现波动。
• 运维成本低：做数据备份、冷热数据迁移的时候，可以直接按索引粒度把多年前的老索引迁到廉价冷节点，不需要逐行筛选数据；排查数据问题的时候，也可以直接定位到对应时间范围的索引，不用扫全量数据。
• 优化空间大：只读的老索引可以按需做深度优化，比如关闭不需要的倒排索引、开启更高等级的压缩，这些操作在单大索引上无法实现，会影响全量数据的访问。

性能表现要结合查询场景判断，没有绝对的谁好谁坏：

• 对于带明确时间范围的查询（比如查某季度的交易统计、查某个用户近2年的订单），按年拆索引的性能明显更优。ES可以直接跳过不相关年份的索引，只扫描对应时间范围的分片，扫描的数据量、分片数都远小于单大索引，尤其查询近1-2年的热数据时，根本不会触碰多年前的冷数据，延迟通常比单大索引低30%以上。
• 对于完全不带时间条件的跨全量查询（比如只凭订单号查全历史的某条记录），两种方案性能差距极小，数据量不大的时候单索引甚至会略快一点——因为按年拆的场景下ES需要先遍历所有索引的元数据定位分片，但这个开销在你年增10GB的规模下几乎可以忽略，只要查询带上哪怕很粗的时间范围，时间索引的优势会立刻体现。
• 长期来看，当数据积累到5年以上（超过50GB），时间索引的性能优势会越来越明显。单大索引会随着数据量增加、段数变多出现不可逆的性能衰退，而时间索引里的老数据可以做只读优化，性能不会随时间推移下降。

实际落地的时候，你这个数据规模完全没必要用5个分片的单大索引，按年建索引的话每个年索引配1个主分片就足够，再给所有order-xxxx格式的索引绑定一个统一的order别名，业务层直接查询别名即可，完全不用感知底层的索引拆分逻辑，维护成本几乎为零。

内容的提问来源于stack exchange，提问作者Joey Yi Zhao