1. 从一个真实的数据建模困境说起电商后台的商品数据模型大概是每个搜索工程师都会撞上的经典难题。一个SPU标准产品单位下面挂着若干个SKU库存量单位每个SKU有自己的价格、库存、规格参数而SPU层面又有统一的标题、品牌、类目、描述。用户搜索的时候既可能搜某品牌手机命中SPU级别的字段也可能搜256G 黑色命中SKU级别的字段。更麻烦的是搜索结果要按SPU聚合展示但筛选条件又得作用在SKU上。我最早的做法是把所有SKU字段冗余到SPU文档里用nested类型存一个SKU数组。这个方案在小数据量下跑得挺欢直到SKU数量膨胀到平均每个SPU几十个、大促期间部分爆款SPU上千个SKU的时候问题就藏不住了。每次改一个SKU的价格整个SPU文档都要重建索引写入放大严重nested查询在深层嵌套下的性能衰减也很明显一次带筛选的聚合查询动辄几百毫秒。后来我把目光转向了ElasticSearch的父子文档Parent-Child Relationship。它允许把SPU和SKU拆成两个独立文档存在同一个索引里通过join字段建立关联。父文档和子文档可以独立更新查询时用has_child和has_parent做跨文档检索。这套机制正好对上了我的需求SKU独立更新、SPU聚合展示、筛选穿透到子文档。这篇简记就是我把父子文档从调研、踩坑到上线稳定运行的完整记录。如果你也在处理类似主数据明细数据的搜索场景比如订单与订单项、文章与评论、商品与规格这篇内容应该能帮你少走不少弯路。我会把join字段的映射设计、查询写法、性能调优、以及几个把我坑得比较惨的细节都摊开讲清楚。2. join字段的映射设计为什么不能随便改2.1 父子关系的底层存储逻辑先搞清楚一个前提ElasticSearch的父子文档并不是把两个文档物理上存在一起而是通过一个叫join的特殊字段来维护逻辑关系。这个字段在Lucene层面是一个_parent的元数据ES在分片内部维护了一张父子映射表。父文档和子文档必须落在同一个分片上这是路由决定的——子文档的路由值必须和父文档一致否则关系就断了。这意味着你在写入子文档时必须显式指定routing参数为父文档的ID。如果你偷懒不指定ES会按子文档自己的ID算路由大概率落到别的分片然后你就得到一个孤儿子文档查询时永远关联不上。这个坑我在测试环境踩过一次数据看起来都写进去了但has_child查询死活查不出结果排查了半天才发现是routing的问题。映射定义长这样PUT /product_index { mappings: { properties: { product_relation: { type: join, relations: { spu: sku } }, title: { type: text }, brand: { type: keyword }, price: { type: scaled_float, scaling_factor: 100 }, stock: { type: integer } } } }这里relations定义了一个层级spu是父sku是子。注意一个索引里可以定义多组父子关系但每篇文档只能属于其中一个类型。join字段本身不参与评分也不支持直接聚合它的作用就是维护关系。2.2 一个索引只能有一个join字段这是硬性限制也是很多人第一次用会懵的地方。你不能在一个索引里定义两个join类型的字段。如果你的业务需要多种父子关系比如商品-SKU和订单-订单项要么拆成两个索引要么把它们塞进同一个join字段的多组relations里。我当时的做法是拆索引。商品搜索和订单搜索的查询模式、刷新频率、数据量级都不一样混在一起反而互相拖累。拆开之后商品索引的join只维护spu - sku订单索引维护order - order_item各自清爽。但拆索引也有代价跨索引的父子查询做不了。如果你的场景需要从订单项反查商品那就得靠应用层做二次查询或者用宽表冗余。这个取舍要在设计初期就想清楚别等上线了才发现查询模式跨了索引。2.3 映射一旦建立relations不能改join字段的relations定义是不可变的。你不能给已有的relations新增一个子类型也不能改父子方向。想改只能重建索引用reindex把数据搬过去。这个限制在官方文档里写得不算显眼但实际影响很大。我吃过一次亏上线两周后产品说要加一个SPU-SKU-赠品的三级关系。我第一反应是改mapping结果直接报错。最后只能新建索引、写reindex脚本、双写过渡、切流量折腾了一整晚。所以我的建议是设计阶段就把关系层级想全宁可多留一层也别上线后返工。提示如果确实需要动态扩展关系类型可以考虑用普通字段存父ID在应用层维护关系牺牲一部分查询便利性换取灵活性。父子文档适合关系稳定的场景。3. 写入与更新routing是绕不开的坎3.1 父文档写入与子文档挂载写父文档很直接指定join字段的name为父类型即可PUT /product_index/_doc/spu_1001?refreshtrue { product_relation: { name: spu }, title: 某品牌旗舰手机, brand: 某品牌, category: 手机 }写子文档时join字段的name设为子类型同时用parent指定父ID并且必须带上routingPUT /product_index/_doc/sku_2001?routingspu_1001refreshtrue { product_relation: { name: sku, parent: spu_1001 }, spec: 256G 黑色, price: 5999, stock: 120 }注意routingspu_1001这一项。ES 7.x之后如果你在join字段里指定了parent部分版本会自动推导routing但我不建议依赖这个行为。显式写routing是最稳的尤其是在批量写入bulk场景下自动推导偶尔会出问题。批量写入的时候routing要写在每个action的元数据里POST /_bulk {index: {_index: product_index, _id: sku_2002, routing: spu_1001}} {product_relation: {name: sku, parent: spu_1001}, spec: 512G 白色, price: 6999, stock: 80}3.2 子文档独立更新的代价与收益父子文档最大的卖点就是子文档可以独立更新不用重建父文档。改一个SKU的价格只更新那一个子文档就行POST /product_index/_update/sku_2001?routingspu_1001 { doc: { price: 5799 } }对比nested方案这里省掉的是整个SPU文档的重建开销。nested更新一个SKU实际上是把整个SPU文档含所有SKU重新索引一遍写入放大会随SKU数量线性增长。父子文档把这个开销降到了常数级。但收益不是白来的。父子文档在查询时要维护父子映射表每次has_child查询都要做一次join操作读性能比nested差。而且父文档的_source里不包含子文档内容想拿完整数据得额外查询。所以这是一个写优化、读劣化的取舍。如果你的场景是读多写少nested可能更合适如果是写多读少或者子文档更新频繁父子文档更划算。3.3 删除父文档时的级联行为删除父文档时ES不会自动删除子文档。子文档会变成孤儿虽然查不到因为父没了但依然占着存储和索引空间。这个设计有点反直觉我第一次遇到时以为删了父就干净了结果磁盘占用一直不降。正确的做法是用delete_by_query先删子文档再删父文档POST /product_index/_delete_by_query { query: { has_parent: { parent_type: spu, query: { term: { _id: spu_1001 } } } } }然后再删父文档。或者用has_child从父的角度反查。这个顺序不能反反了父文档先没了has_parent就查不到子文档了。注意孤儿文档不会影响查询正确性但会持续占用资源。建议定期跑一个清理任务用has_parent查不到父的子文档批量删除。ES本身没有提供自动清理机制。4. 查询实战has_child与has_parent的用法与陷阱4.1 从父查子has_child的完整写法最常见的需求是找出所有包含满足条件SKU的SPU。比如搜价格低于6000且有库存的手机GET /product_index/_search { query: { has_child: { type: sku, query: { bool: { must: [ { range: { price: { lte: 6000 } } }, { range: { stock: { gt: 0 } } } ] } }, score_mode: max, inner_hits: { size: 3, sort: [{ price: asc }] } } } }这里有几个关键参数值得说。score_mode决定子文档的评分怎么影响父文档可选none、avg、max、min、sum。默认是none也就是父文档评分不受子文档影响。如果你希望匹配得越好的SKU父文档排得越前用max或avg。但要注意score_mode不是none时会有额外的评分计算开销。inner_hits是我用得最多的功能。它能在返回父文档的同时把命中的子文档也带出来。上面这个查询会返回每个SPU下价格最低的3个SKU。没有inner_hits的话你只能拿到SPU还得再发一次查询去取SKU网络往返翻倍。4.2 从子查父has_parent的反向检索反过来从SKU找SPU用has_parentGET /product_index/_search { query: { has_parent: { parent_type: spu, query: { term: { brand: 某品牌 } }, score_mode: score } } }这个查询返回的是所有属于某品牌的SKU文档。注意返回的是子文档不是父文档。如果你想要父文档得用has_child从父侧查或者拿到父ID后再查一次。has_parent的score_mode只有none和score两个选项比has_child少。score表示父文档的评分会传给子文档。实际用下来has_parent的性能通常比has_child好一些因为父文档数量少过滤效率高。4.3 多层嵌套与混合查询的坑父子文档支持多层比如spu - sku - promotion。但层数一多查询复杂度是指数级上升的。我试过三层has_child套has_child查询延迟从几十毫秒涨到几百毫秒而且inner_hits在多层下的行为很反直觉——它只返回最内层命中的文档中间层的信息拿不到。混合查询也要小心。比如父文档标题匹配手机且子文档价格低于6000GET /product_index/_search { query: { bool: { must: [ { match: { title: 手机 } }, { has_child: { type: sku, query: { range: { price: { lt: 6000 } } } } } ] } } }这个查询本身没问题但要注意title字段在父文档和子文档里可能都存在。如果子文档也有titlematch查询会同时命中父子文档结果就乱了。我的做法是父子文档的字段命名做区分父文档用spu_title子文档用sku_title避免歧义。提示父子文档共享同一个索引的mapping字段是共用的。设计时要想清楚哪些字段属于父、哪些属于子命名上做区分查询时用type过滤或者字段前缀区分。5. 性能调优那些文档里不会写的细节5.1 父子查询为什么慢全局序号与join开销父子文档的查询性能瓶颈根源在于ES需要在查询时做一次join。具体来说ES在分片内部维护了一个全局序号global ordinals的映射把父文档ID映射成序号子文档通过序号关联到父。这个映射在每次查询时都要加载如果父文档数量大加载开销就很可观。has_child查询的执行流程大致是先查子文档拿到命中的子文档对应的父序号再去父文档里找对应的文档。这个过程中如果子文档命中数量很大父序号的集合就很大后续的过滤和评分都会变慢。我实测过一个对比同样数据量下nested查询平均15ms父子查询平均45ms。差距主要就在这个join开销上。所以如果你的场景对延迟极其敏感父子文档可能不是最优解。5.2 减少join开销的三个实操手段第一个手段是控制父文档数量。父文档越少全局序号的映射越小加载越快。如果你的父文档有上千万考虑按业务维度分索引比如按类目分每个索引的父文档控制在百万级。第二个手段是用filter代替query。has_child里的子查询如果不需要评分用filter包起来ES会跳过评分计算直接走倒排索引过滤。这个优化在子文档命中量大时效果明显我这边能降30%左右的延迟。{ has_child: { type: sku, query: { bool: { filter: [ { range: { price: { lte: 6000 } } } ] } } } }第三个手段是限制inner_hits的size。inner_hits默认返回3条如果你设成100ES要为每个父文档收集100条子文档开销很大。按实际展示需求设通常3到5条就够了。5.3 分片路由与数据倾斜的预防因为子文档必须和父文档同分片如果某个父文档的子文档特别多比如爆款SPU有上千SKU这个分片就会比其他分片大很多形成数据倾斜。倾斜的分片在查询时会成为瓶颈拖慢整个集群。预防的办法是在路由上做文章。默认用父ID做routing如果父ID分布均匀问题不大。但如果你的父ID有热点比如按时间递增的ID可以考虑用父ID的哈希值做routing打散分布。代价是失去了按父ID范围查询的便利性要权衡。另一个办法是给大父文档的子文档单独建索引用应用层做关联。这个方案复杂但彻底适合极端倾斜的场景。我目前还没走到这一步因为业务上爆款SPU的SKU数量控制在几百以内倾斜在可接受范围。优化手段适用场景预期收益代价控制父文档数量父文档千万级降低join加载开销需要分索引设计filter代替query子查询不需评分延迟降20%-30%无限制inner_hits size展示型查询减少收集开销展示条数受限哈希routing父ID有热点缓解数据倾斜失去范围查询便利6. 踩坑复盘三个让我加班到凌晨的问题6.1 子文档写入成功但查不到routing缺失的排查链路这个坑前面提过但值得展开讲排查过程。现象是bulk写入返回200_count显示文档数对得上但has_child查询返回空。第一反应是查询写错了检查了type、字段名、查询语法都没问题。然后怀疑是refresh没生效加了refreshtrue还是空。接着用GET /product_index/_doc/sku_2001直接查子文档能查到_source里parent字段也对。这时候才想到routing。用GET /product_index/_doc/sku_2001?routingspu_1001查能查到不带routing查查不到。说明文档确实写到了错误的分片。根因是bulk写入时routing没带ES按子文档ID算了路由落到了别的分片。父文档在分片A子文档在分片Bjoin关系自然建立不起来。修复方式是删掉错误文档带routing重写。这个问题的隐蔽性在于写入不报错查询不报错只是结果为空很容易往查询方向排查浪费大量时间。提示写完子文档后用GET /_cat/shards/product_index看分片分布或者用_search_shards接口确认父子文档是否在同一分片。养成写入后验证routing的习惯。6.2 父文档更新导致子文档关系丢失的诡异现象有一次做数据迁移用_update_by_query批量更新父文档的某个字段。更新完之后部分子文档的has_parent查询失效了。查了半天发现_update_by_query在重建父文档时如果没指定routing会按父文档ID重新算路由可能落到和原来不同的分片。父文档换了分片子文档还在老分片关系就断了。这个问题的根因和上一个类似都是routing不一致。但更隐蔽因为父文档本身查得到只是关系断了。修复方式是在_update_by_query里显式指定routing或者用_reindex代替reindex会保留原routing。POST /product_index/_update_by_query?routingspu_1001 { query: { term: { _id: spu_1001 } }, script: { source: ctx._source.brand params.brand, params: { brand: 新品牌 } } }6.3 聚合查询下父子文档的计数偏差做品牌维度的SPU计数聚合时发现数字对不上。用has_child查出来的SPU数量和直接terms聚合父文档的数量不一致。排查后发现has_child查询默认会去重父文档但聚合时如果用了cardinality或者terms统计的是文档数不是去重后的父文档数。具体来说一个SPU有10个SKUhas_child查询返回1个SPU去重但如果你在聚合里按SKU维度统计会得到10。这个偏差在报表场景下很致命。解决办法是在聚合前先用has_child过滤然后对父文档做聚合或者用cardinality聚合父ID去重。GET /product_index/_search { size: 0, query: { has_child: { type: sku, query: { range: { price: { lte: 6000 } } } } }, aggs: { brand_count: { terms: { field: brand, size: 20 } } } }这个查询先过滤出符合条件的SPU再按品牌聚合结果就是去重后的SPU计数。如果直接对全量文档聚合会把SKU也算进去数字就虚高了。7. 父子文档与nested的选型对照7.1 从更新频率和数据量级做决策选父子还是nested我总结了一个简单的判断标准看子文档的更新频率和数量。如果子文档更新频繁比如库存、价格实时变且单个父文档下的子文档数量多几十个以上选父子。如果子文档基本不变比如商品的规格参数或者数量少几个以内选nested。nested的优势是查询快、支持复杂的嵌套聚合、数据在同一个文档里读取方便。劣势是更新代价高每次改一个子项都要重建整个文档。父子文档反过来更新便宜查询贵聚合能力弱。我现在的做法是混合用商品搜索用父子SKU价格库存频繁变商品详情页的规格参数用nested基本不变查询要快。同一个索引里可以同时有nested字段和join字段互不干扰。7.2 查询能力与聚合支持的差异nested支持nested查询、nested聚合、reverse_nested聚合能在嵌套层级内做复杂的统计。父子文档的聚合能力弱很多join字段本身不能聚合只能通过has_child/has_parent过滤后再对父或子文档聚合跨层聚合基本做不了。举个例子nested可以轻松算出每个SPU下SKU的平均价格用nested聚合加avg子聚合就行。父子文档要做同样的事得先has_child过滤出SPU再对SKU做聚合但聚合结果和父文档的对应关系很难维护通常要应用层二次处理。所以如果你的业务有大量跨层聚合需求nested更合适。如果只是过滤和展示父子够用。维度父子文档nested更新代价低子文档独立更新高重建整个文档查询性能较慢有join开销较快聚合能力弱跨层聚合困难强支持嵌套聚合数据量级适合子文档多的场景适合子文档少的场景关系层级支持多层单层嵌套路由要求必须同分片无7.3 迁移成本与回退方案从nested迁到父子或者反过来都不是小工程。数据要重建查询要重写聚合逻辑要调整。我的建议是如果现有方案能撑住别轻易迁。如果确实要迁用双写过渡新老两套索引同时写查询逐步切观察一段时间再下线老索引。回退方案也要提前想好。父子迁nested的回退相对容易因为nested查询更通用。nested迁父子的回退就麻烦些因为父子查询的写法差异大。我一般会在应用层做一层查询抽象把底层是nested还是父子的差异封装掉切换时只改配置不改业务代码。8. 上线后的监控与日常维护要点父子文档上线后有几个指标要盯着。第一个是孤儿文档数量定期用has_parent查不到父的子文档数量异常增长说明有删除逻辑没处理干净。第二个是分片大小倾斜用_cat/shards看各分片的文档数和存储大小偏差超过30%就要考虑调整routing策略。第三个是父子查询的延迟P99单独埋点监控因为父子查询的延迟波动比普通查询大容易被平均值掩盖。日常维护上我每周跑一次孤儿文档清理每月做一次分片均衡检查。清理脚本用delete_by_query注意加conflictsproceed避免版本冲突中断。分片均衡如果发现倾斜用_cluster/reroute手动迁移分片或者调整索引的routing_partition_size参数。还有一个容易忽略的点父文档的_source里不包含子文档所以做数据导出或者备份时父子文档要分别导出恢复时先导父再导子顺序不能反。我写过一个恢复脚本先bulk导父文档再bulk导子文档带routing跑通之后才敢做正式的迁移。这套父子文档的方案在我这边跑了半年多中间经历过两次大促查询延迟稳定在50ms以内写入放大比nested方案降了大概70%。踩过的坑基本都在上面了核心就一句话routing是命根子设计阶段想清楚关系层级查询时善用filter和inner_hits。如果你的场景也是主数据加明细数据父子文档值得一试但别指望它解决所有问题该用nested的地方还是得用nested。