Elasticsearch 6.2+迁移：父子模型与多索引方案选型咨询

结合你的集群规模、读写特征以及三个可选方案的细节，我认为你倾向的多独立索引方案是更优选择，没必要强行用join类型维持原父子模型。下面我会结合你的场景拆解各方案的适配性，再补充你需要关注的额外性能和扩展问题：

方案适配性拆解 #

1. 采用join数据类型 #

这个方案看似能无缝衔接旧逻辑，但其实并不适配你的场景：

• 虽然它能保留has_parent/has_child查询和同分片性能优势，但你的父文档仅160万左右，子文档却接近2.7亿，父/子最大比例达到1:400，这种极端比例下，单索引的扁平化映射会变得极度杂乱——你要在同一个索引里维护两种差异极大的文档结构（读密集的父文档、读写密集的子文档），后续字段变更、问题排查都会变得非常棘手，而且没法快速识别文档类型，运维成本飙升。
• 更关键的是，单索引的配置很难同时兼顾父文档的读性能和子文档的写性能：比如父文档需要高副本、大缓存来优化读，而子文档需要合适的刷新间隔、分片数来提升写吞吐量，两者的优化方向冲突，反而会抵消同分片的性能优势。

2. 多独立索引（推荐） #

这个方案完全贴合你的业务特征，而且你担心的应用端关联开销其实是可控的：

• 配置灵活性拉满：父文档读密集，可以给父索引配置更多副本、调大查询缓存；子文档读写密集，可以单独调整分片数、缩短刷新间隔，两者的优化互不干扰；
• 数据本地性可替代：通过自定义routing（比如用父文档ID作为路由值），完全能把关联子文档和父文档路由到同分片，实现和原父子模型一样的本地查询优势，避免跨分片的额外开销；
• 应用端关联的开销可控：你提到has_parent/has_child本身也有性能开销——没错，ES执行这类查询时需要在分片内遍历关联文档，尤其是你子文档规模极大的情况下，has_child查询的开销可能比应用端做两次查询（先查父文档拿ID，再查子索引）还要高。而且应用端可以做缓存优化：把高频访问的父文档ID缓存起来，减少重复查询父索引的次数，进一步降低开销。
• 针对子索引规模过大的问题，可以考虑按时间或业务维度做索引拆分（比如按月rollover），避免单个子索引过于庞大，提升读写和维护效率；多索引查询时用multi_search或者bool查询组合，比多次单独查询更高效。

3. 单索引+自定义类型字段 #

这个方案完全不推荐，单索引容纳近2.7亿文档后，分片维护、查询性能都会急剧下降，而且映射复杂，后续迭代成本极高，完全不符合你的业务场景。

额外需关注的性能/扩展细节 #

结合你的集群数据（总分片36，92.33GB），还要注意这些关键点：

• 路由策略必须严格一致：多索引方案下，父文档和关联子文档必须使用完全相同的routing值（比如父文档ID），否则数据本地性优势就会失效，跨分片查询的延迟会飙升；
• 父索引缓存优化：父文档读密集，建议开启父索引的查询缓存（index.queries.cache.enabled: true），并适当调大缓存大小（比如设为堆内存的10%），把高频查询的父文档结果缓存起来，减少磁盘IO；
• 子索引写性能调优：子文档读写密集，可以调整index.refresh_interval（比如设为15s，默认1s）减少刷新次数提升写吞吐量；如果业务能接受少量数据丢失风险，还可以开启index.translog.durability: async，降低写操作的磁盘同步开销；
• 分片数合理分配：当前总分片36，子文档规模是父文档的170倍左右，建议给子索引分配更多主分片（比如父索引用3主6副本，子索引用9主18副本，保持总分片数不变），让子文档的读写压力更均匀；
• 索引生命周期管理：如果子文档有时间属性，建议用ES 6.2的索引生命周期管理（ILM）实现自动rollover、删除旧索引，避免子索引无限膨胀；
• 监控与调优：迁移后要重点监控多索引查询的延迟，对比原has_parent/has_child的查询耗时，用ES的_cat/nodes?v、_cat/indices?v以及Kibana监控面板跟踪分片的CPU、IO、内存使用率，及时调整配置。

内容的提问来源于stack exchange，提问作者Nithin Chandy