为何Elasticsearch的routing_partition_size仅支持索引级配置？

背景回顾 #

根据Elasticsearch官方文档，routing_partition_size是创建索引时设置的索引级参数：

• 开启后，自定义路由值对应的文档会被索引到分片子集，以牺牲多分片搜索效率为代价实现数据均衡；
• 未开启时，同一路由值的文档仅存储在单个分片，容易引发集群数据失衡。

现有业务场景：以supplier_code作为自定义_routing值存储库存商品文档，多数小供应商库存少，适合单分片存储（无需routing_partition_size）；少数大供应商库存充足，需要通过routing_partition_size将文档分散到分片子集，避免单个分片成为查询瓶颈。但当前仅支持索引级配置该参数，导致小供应商的查询也需遍历多分片，不符合预期。

核心原因分析 #

• 路由计算的一致性要求：Elasticsearch的文档路由计算需要在索引和查询阶段保持严格一致。如果允许按文档或路由值单独配置routing_partition_size，会让分片路由规则变得碎片化，每个文档的分片计算逻辑不同，不仅会大幅增加节点的计算负担，还容易出现路由匹配错误，导致文档无法被正确查询到。

• 查询执行的简洁性与性能：现有查询执行流程基于索引级的统一路由规则，协调节点可以快速确定需要搜索的分片集合。若引入路由级的配置差异，查询时需要先判断当前路由值对应的分区规则，再动态计算分片范围，这会打破统一执行流程，增加协调节点的处理逻辑，在高并发场景下会显著降低查询效率。

• 索引元数据的管理成本：索引级配置能让索引的元数据保持简洁统一，集群节点可以缓存整个索引的路由配置，无需为每个路由值维护额外的配置信息，减少了内存占用和元数据的管理复杂度，保障集群的稳定性。

• 设计层面的权衡取舍：routing_partition_size本质是数据均衡与查询效率的权衡方案。官方选择索引级统一配置，是为了避免混合规则带来的复杂度和潜在问题——毕竟多数场景下，要么全量需要路由分区，要么不需要。对于这类混合场景，可通过拆分索引的方式解决：将大供应商的文档单独存入开启routing_partition_size的索引，小供应商的文档存入普通索引，兼顾数据均衡和查询效率。

内容的提问来源于stack exchange，提问作者Bilal Munawar