企业官网建设流程全解析

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?refresh=true { "product_relation": { "name": "spu" }, "title": "某品牌旗舰手机", "brand": "某品牌", "category": "手机" }

写子文档时，join字段的name设为子类型，同时用parent指定父ID，并且必须带上routing：

PUT /product_index/_doc/sku_2001?routing=spu_1001&refresh=true { "product_relation": { "name": "sku", "parent": "spu_1001" }, "spec": "256G 黑色", "price": 5999, "stock": 120 }

注意routing=spu_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?routing=spu_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_parent：

GET /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在多层下的行为很反直觉——它只返回最内层命中的文档，中间层的信息拿不到。

混合查询也要小心。比如"父文档标题匹配'手机'，且子文档价格低于6000"：

GET /product_index/_search { "query": { "bool": { "must": [ { "match": { "title": "手机" } }, { "has_child": { "type": "sku", "query": { "range": { "price": { "lt": 6000 } } } } } ] } } }

这个查询本身没问题，但要注意title字段在父文档和子文档里可能都存在。如果子文档也有title，match查询会同时命中父子文档，结果就乱了。我的做法是父子文档的字段命名做区分，父文档用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条，如果你设成100，ES要为每个父文档收集100条子文档，开销很大。按实际展示需求设，通常3到5条就够了。

5.3 分片路由与数据倾斜的预防

因为子文档必须和父文档同分片，如果某个父文档的子文档特别多（比如爆款SPU有上千SKU），这个分片就会比其他分片大很多，形成数据倾斜。倾斜的分片在查询时会成为瓶颈，拖慢整个集群。

预防的办法是在路由上做文章。默认用父ID做routing，如果父ID分布均匀，问题不大。但如果你的父ID有热点（比如按时间递增的ID），可以考虑用父ID的哈希值做routing，打散分布。代价是失去了按父ID范围查询的便利性，要权衡。

另一个办法是给大父文档的子文档单独建索引，用应用层做关联。这个方案复杂但彻底，适合极端倾斜的场景。我目前还没走到这一步，因为业务上爆款SPU的SKU数量控制在几百以内，倾斜在可接受范围。

6. 踩坑复盘：三个让我加班到凌晨的问题

6.1 子文档写入成功但查不到：routing缺失的排查链路

这个坑前面提过，但值得展开讲排查过程。现象是：bulk写入返回200，_count显示文档数对得上，但has_child查询返回空。第一反应是查询写错了，检查了type、字段名、查询语法，都没问题。然后怀疑是refresh没生效，加了refresh=true，还是空。

接着用GET /product_index/_doc/sku_2001直接查子文档，能查到，_source里parent字段也对。这时候才想到routing。用GET /product_index/_doc/sku_2001?routing=spu_1001查，能查到；不带routing查，查不到。说明文档确实写到了错误的分片。

根因是bulk写入时routing没带，ES按子文档ID算了路由，落到了别的分片。父文档在分片A，子文档在分片B，join关系自然建立不起来。修复方式是删掉错误文档，带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?routing=spu_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个SKU，has_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更合适。如果只是过滤和展示，父子够用。

7.3 迁移成本与回退方案

从nested迁到父子，或者反过来，都不是小工程。数据要重建，查询要重写，聚合逻辑要调整。我的建议是，如果现有方案能撑住，别轻易迁。如果确实要迁，用双写过渡：新老两套索引同时写，查询逐步切，观察一段时间再下线老索引。

回退方案也要提前想好。父子迁nested的回退相对容易，因为nested查询更通用。nested迁父子的回退就麻烦些，因为父子查询的写法差异大。我一般会在应用层做一层查询抽象，把底层是nested还是父子的差异封装掉，切换时只改配置不改业务代码。

8. 上线后的监控与日常维护要点

父子文档上线后，有几个指标要盯着。第一个是孤儿文档数量，定期用has_parent查不到父的子文档，数量异常增长说明有删除逻辑没处理干净。第二个是分片大小倾斜，用_cat/shards看各分片的文档数和存储大小，偏差超过30%就要考虑调整routing策略。第三个是父子查询的延迟P99，单独埋点监控，因为父子查询的延迟波动比普通查询大，容易被平均值掩盖。

日常维护上，我每周跑一次孤儿文档清理，每月做一次分片均衡检查。清理脚本用delete_by_query，注意加conflicts=proceed避免版本冲突中断。分片均衡如果发现倾斜，用_cluster/reroute手动迁移分片，或者调整索引的routing_partition_size参数。

还有一个容易忽略的点：父文档的_source里不包含子文档，所以做数据导出或者备份时，父子文档要分别导出，恢复时先导父再导子，顺序不能反。我写过一个恢复脚本，先bulk导父文档，再bulk导子文档（带routing），跑通之后才敢做正式的迁移。

这套父子文档的方案在我这边跑了半年多，中间经历过两次大促，查询延迟稳定在50ms以内，写入放大比nested方案降了大概70%。踩过的坑基本都在上面了，核心就一句话：routing是命根子，设计阶段想清楚关系层级，查询时善用filter和inner_hits。如果你的场景也是主数据加明细数据，父子文档值得一试，但别指望它解决所有问题，该用nested的地方还是得用nested。