> 2.0 把 parent/child 的实现整个重写，`_parent` 默认走 doc values，但只对 2.0 及以后创建的索引生效，所以用 `_parent` 的老索引升级后功能照常、改进拿不到，要 reindex 才行。同一份迁移文档里还有两条：父类型不能先于子类型存在，`top_children` 查询被删。本文对照 v2.4.6 源码把这三条的触发条件核了一遍。

## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845)。

来源和边界先交代：本文的依据出自 v2.4.6 标签下的官方文件（`parent_child.asciidoc`、`ParentFieldMapper.java`、`Version.java`），文中引用的原文均来自这些文件。我没有启动集群、也没有跑测试，示例取自官方示例；哪些是文档写明、哪些是我的推断，正文里逐处标注。

![01-parent_child](https://developer.qcloudimg.com/http-save/yehe-7348459/62b36eedf0af2aa62ce584ae43c0e9b2.png)

*图 1：官方文件 parent_child.asciidoc（v2.4.6 标签）。来源：GitHub elastic/elasticsearch v2.4.6 parent_child.asciidoc*

## 先看官方原文

2.0 的迁移文档（[parent_child.asciidoc 第 4–10 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/migration/migrate_2_0/parent_child.asciidoc#L4-L10)）开头是这两段：

> Parent/child has been rewritten completely to reduce memory usage and to execute `has_child` and `has_parent` queries faster and more efficient. The `_parent` field uses doc values by default. The refactored and improved implementation is only active for indices created on or after version 2.0.
>
> In order to benefit from all the performance and memory improvements, we recommend reindexing all existing indices that use the `_parent` field.

第三句是重点：新实现只对 2.0 及以后创建的索引生效。集群从 1.x 升到 2.x，老索引的文件不变，父子关系还是走老路径，功能正常，内存和查询上的改进拿不到。要拿到，只能 reindex。文档没有给出内存或性能的具体数字，本文也不编数字。

![02-MetaDataMappingServiceTests](https://developer.qcloudimg.com/http-save/yehe-7348459/d5907b05f9276f1ba1343df8598ce791.png)

*图 2：官方文件 MetaDataMappingServiceTests.java（v2.4.6 标签）。来源：GitHub elastic/elasticsearch v2.4.6 MetaDataMappingServiceTests.java*

## 这条迁移的风险在于升级后没有任何信号

通常的 breaking change 会报错或行为明显变化，读者马上知道要处理。这一条升级后父子查询照常返回结果，没有报错，也没有日志提示，容易被当成已经升级完成。后面发现父子查询还是慢、内存还是高，才会回头看到文档里那句 "we recommend reindexing"。

我的建议是升级 2.0 时就把这类索引的 reindex 排进计划。原因有两个：这些改进只在重建后才生效，不重建等于没有升级这部分；数据量只会增长，重建的窗口越往后越难找。

reindex 的成本也值得先掂量。父子关系解决的是"一对多、子文档需要独立更新"，我的判断是：如果子文档很少变动，用 `nested` 或把子对象放进父文档，查询和维护成本往往更低。这是建模上的建议，本文没有做基准测试。

![03-ParentFieldMapper](https://developer.qcloudimg.com/http-save/yehe-7348459/86bbd774a677a3cd80c0bb4a896e5e9e.png)

*图 3：官方文件 ParentFieldMapper.java（v2.4.6 标签）。来源：GitHub elastic/elasticsearch v2.4.6 ParentFieldMapper.java*

## "按创建版本生效"在源码里是什么样

迁移文档的说法可以在 v2.4.6 源码里对上。[ParentFieldMapper 第 126–131 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/core/src/main/java/org/elasticsearch/index/mapper/internal/ParentFieldMapper.java#L126-L131)在构建 `_parent` 的 mapper 时，对创建版本早于 `Version.V_2_0_0_beta1` 的索引，把 parent/child 两个 join 字段的 doc values 关掉：

```java
if (context.indexCreatedVersion().before(Version.V_2_0_0_beta1)) {
    childJoinFieldType.setHasDocValues(false);
    childJoinFieldType.setDocValuesType(DocValuesType.NONE);
    parentJoinFieldType.setHasDocValues(false);
    parentJoinFieldType.setDocValuesType(DocValuesType.NONE);
}
```

[第 281–284 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/core/src/main/java/org/elasticsearch/index/mapper/internal/ParentFieldMapper.java#L281-L284)的 `joinFieldTypeForParentType` 对同样的条件做了同样的处理。所以"doc values 默认开启"只对 2.0 及以后创建的索引成立，老索引在同一份代码里被显式关掉。`Version.java` 里 1.7.0 的版本号是 `1070099`，`2.0.0-beta1` 是 `2000001`（[Version.java 第 249、264 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/core/src/main/java/org/elasticsearch/Version.java#L249)），可以用来判断 `index.version.created` 属于哪一边。

## 父类型不能先于子类型存在

2.0 里，一个类型通过 `_parent` 元字段声明自己是另一个类型的子类型（迁移文档 [第 12 行起](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/migration/migrate_2_0/parent_child.asciidoc#L12)的 "Parent type cannot pre-exist"）：

```json
PUT my_index
{
  "mappings": {
    "my_parent": {},
    "my_child": {
      "_parent": {
        "type": "my_parent"
      }
    }
  }
}
```

文档对顺序的限定是：

> The mapping for the parent type can be added at the same time as the mapping for the child type, but cannot be added before the child type.

`_parent` 元字段文档的限制一节说得更直接（[parent-field.asciidoc 第 109–111 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/mapping/fields/parent-field.asciidoc#L109-L111)）：`_parent.type` 只能指向一个还不存在的类型，一个类型在创建之后不能再变成父类型。

源码里这条校验在 [MetaDataMappingService 第 269–277 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/core/src/main/java/org/elasticsearch/cluster/metadata/MetaDataMappingService.java#L269-L278)：对 2.0 及以后创建的索引，往已有索引里新增一个带 `_parent` 的类型时，如果它指向的类型已经存在、而且还不是任何类型的父类型，就抛 `IllegalArgumentException`，消息是：

```text
can't add a _parent field that points to an already existing type, that isn't already a parent
```

测试里有对应的两个用例（[MetaDataMappingServiceTests](https://github.com/elastic/elasticsearch/blob/v2.4.6/core/src/test/java/org/elasticsearch/cluster/metadata/MetaDataMappingServiceTests.java)）：先建 `type`，再给 `child` 加指向 `type` 的 `_parent`，会失败；先建 `parent` 和 `child1`，再加指向 `parent` 的 `child2`，因为 `parent` 已经是父类型，所以允许。

对建索引脚本的影响：如果脚本是先建好父类型的 mapping，再用 put mapping 去加子类型，会触发这个错误；在创建索引的同一个请求里同时给出父类型和子类型的 mapping，文档说明是可以的。这个限制只对 2.0 及以后创建的索引生效，条件里的 `Version.indexCreated(...).onOrAfter(Version.V_2_0_0_beta1)` 就是判断依据。

## `top_children` 查询被删了

迁移文档（[第 38–43 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/migration/migrate_2_0/parent_child.asciidoc#L38-L43)）的原文：

> The `top_children` query has been removed in favour of the `has_child` query. It wasn't always faster than the `has_child` query and the results were usually inaccurate. The total hits and any aggregations in the same search request would be incorrect if `top_children` was used.

官方给了三条理由：

1. 并不总是比 `has_child` 快；
2. 结果通常不准确；
3. 同一个请求里的 total hits 和聚合会算错。

第三条的影响最大：不只是返回的文档不准，连总数和聚合都跟着错。用了 `top_children` 的查询在 2.0 里没有"先用着"的余地，要换成 `has_child`。这次删除没有保留兼容期，从理由看是合理的：结果错误的查询，保留比删除代价更高。

## 2.0 前后对照

| 项 | 1.x | 2.0 |
|---|---|---|
| `_parent` 的 doc values | 源码里对老索引关闭 | 新建索引默认开启 |
| 新实现的生效范围 | 无 | 仅 2.0 及以后创建的索引 |
| 老索引 | 沿用旧路径 | 要 reindex 才能受益 |
| 父子相关查询 | `has_child`、`has_parent`、`top_children` | `has_child`、`has_parent` |
| 父类型的定义顺序 | 无此限制 | 不能先于子类型存在 |

## 怎么确认索引用的是不是新实现

文档没有给判断方法，但既然新实现只看创建版本，可以直接看索引设置里的 `index.version.created`：

```sh
curl -s 'localhost:9200/_cat/indices?v'
curl -s 'localhost:9200/my_index/_settings?pretty' | grep version
```

输出里的 `created` 是版本号的数字形式。按上面 `Version.java` 的编码，2.4.6 是 `2040699`，1.x 创建的索引是以 `1` 开头的七位数，比如 `1070099`。创建于 `2000001`（2.0.0-beta1）之前的索引，父子关系是老实现，要重建。

## reindex 怎么做

下面的流程把老索引的数据搬到一个新建的 2.0+ 索引。reindex 在 v2.4.6 里是 experimental，[reindex 文档第 4 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/docs/reindex.asciidoc#L4)标明 API 可能以不兼容的方式变化；文档开头的 IMPORTANT（[第 6 行起](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/docs/reindex.asciidoc#L6)）还写明 reindex 不会帮你建目标索引，mapping、分片数等要先自己配好。

```sh
# 1) 建新索引，父类型和子类型在同一个请求里给出
curl -XPUT 'localhost:9200/my_index_v2' -d '{
  "mappings": {
    "my_parent": {},
    "my_child": { "_parent": { "type": "my_parent" } }
  }
}'

# 2) 搬运数据
curl -XPOST 'localhost:9200/_reindex' -d '{
  "source": { "index": "my_index" },
  "dest":   { "index": "my_index_v2" }
}'

# 3) 核对数量，再切别名
curl -s 'localhost:9200/my_index/_count'
curl -s 'localhost:9200/my_index_v2/_count'
```

### `_parent` 的值是从哪里带过去的

这里要纠正一种常见的担心：是不是要先把 parent id 存成 `_source` 里的普通字段，reindex 才带得过去。读 v2.4.6 的源码，不需要。

- [AbstractAsyncBulkIndexByScrollAction 第 110–112 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/modules/reindex/src/main/java/org/elasticsearch/index/reindex/AbstractAsyncBulkIndexByScrollAction.java#L110-L112)的 `copyMetadata` 从每条命中里读 `_parent`，调用 `index.parent(...)` 设到新的索引请求上；路由在 [第 127–129 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/modules/reindex/src/main/java/org/elasticsearch/index/reindex/AbstractAsyncBulkIndexByScrollAction.java#L127-L129)同样从 `_routing` 复制；
- 命中里为什么有这两个值：[FieldsVisitor 第 58–64 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/core/src/main/java/org/elasticsearch/index/fieldvisitor/FieldsVisitor.java#L58-L64)的 `BASE_REQUIRED_FIELDS` 里包含 `_routing` 和 `_parent`，取文档时默认就会读出来。

所以按代码读，`_parent` 和 `_routing` 会被 reindex 原样带到目标索引，不依赖 `_source` 里有没有这个字段。这是读源码的推断，没有跑过，建议先拿一组小数据验证：reindex 之后对目标索引跑 `has_child`，能返回结果就说明关系带过去了。官方 reindex 文档的脚本章节（[第 263 行](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/docs/reindex.asciidoc#L263)）也把 `_parent` 列在脚本能修改的元数据里。

### 路由的约束

[`_parent` 文档](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/mapping/fields/parent-field.asciidoc#L113-L117)里还有一条限制：父子文档必须在同一个分片，`parent` ID 同时作为子文档的路由值，所以对子文档做 GET、DELETE、UPDATE 时都要带同样的 `parent` 值。reindex 之后写入端和读取端对 parent 的传法不能变，这是改完索引之后要核对的客户端行为。

## reindex 前的准备

父子文档之间有依赖关系，动手前建议确认这几件事：

1. 规模：父文档数、子文档数、平均每个父下挂多少个子，用来估时间和磁盘；
2. reindex 期间的写入：如果业务还在写，期间新增和修改的文档不会自动出现在新索引里。常见的做法是新老索引双写一段时间，reindex 历史数据，切换查询后再停掉对旧索引的写入，代价是写入逻辑要改；
3. 别名：用别名指向索引，切换时改别名指向，业务代码不用改，前提是所有读写都走别名，直接写索引名的代码会漏；
4. 试跑：拿一个小的父子索引完整跑一遍（reindex、校验、切换），再动大的。试跑能暴露 mapping 顺序、查询改写这类问题。

## 重建之后怎么验证父子关系

reindex 跑完不等于完成。建议验三样：

1. 计数：父文档数、子文档数和原索引一致，能发现漏文档；
2. 抽样验证关系：挑几个父文档，用 `has_child` 查它们下面的子文档，数量要对：

```sh
curl -s -XPOST 'localhost:9200/my_index_v2/_search' -d '{
  "query": {
    "has_child": {
      "type": "my_child",
      "query": { "match_all": {} }
    }
  }
}'
```

反向用 `has_parent` 也验一次；

3. 对比关键查询：选几个业务上真实的父子查询，在新旧索引上各跑一次，对比返回的文档 id 集合。计数和抽样都通过，也可能出现个别子文档挂错父的局部错误，只有这一步能发现。

## 什么时候别用父子关系

适合的场景：一对多，且子文档需要频繁独立增删改。父子的价值在于更新子文档时不用重写整个父文档。

不太适合的场景：

- 一对多但子文档很少变动：用 `nested` 或直接把子对象放进父文档，查询和维护都简单；
- 想用它做 JOIN 出报表：ES 不是为这个设计的，放在应用层或数仓里更合适；

2.0 的重写之后，内存和查询效率相对 1.x 有改进，但 `_parent` 文档里列出的限制还在：父子要在同一个分片，父类型不能事后追加，对子文档做 GET、DELETE、UPDATE 要带 parent。这是选型时的取舍。

## 写在最后

这篇涉及三条改动：新实现只对 2.0 及以后创建的索引生效，老索引要 reindex；父类型不能先于子类型存在，put mapping 顺序写反会报错；`top_children` 被删，要换成 `has_child`。

前两条都是不报错或要到特定操作时才暴露的类型：老索引升级后功能正常、改进没拿到，建索引脚本的顺序只在用 put mapping 追加子类型时才出问题。第三条会让旧的查询请求直接失败，至少能被发现。

对"索引级"的改进，升级后要主动确认生效，不能假设升级集群版本就受益。确认的办法是看索引的元数据，这里是 `index.version.created`，而不是集群版本号。大版本升级后，挑几个有代表性的索引把设置打出来对一遍，这个清单不长，能覆盖"升级了但没真正生效"的情况。

## 参考

- [Parent/Child changes @ v2.4.6](https://github.com/elastic/elasticsearch/blob/v2.4.6/docs/reference/migration/migrate_2_0/parent_child.asciidoc)

> 本文引用的原文与示例均来自本地 `elasticsearch` 仓库 `v2.4.6` 标签下的迁移文档；未给出内存或性能的具体数字，因为原文没有提供。

> 本文对照 Elasticsearch `v2.4.6` 标签的官方文档核对，引文逐字取自原文。撰写时未启动集群、未运行测试。


2.0 把 parent/child 的实现整个重写，_parent 默认走 doc values，但只对 2.0 及以后创建的索引生效，所以用 _parent 的老索引升级后功能照常、改进拿不到，要 reindex 才行。同一份迁移文档里还有两条：父类型不能先于子类型存在，top_children 查询被删。本文对照 v2.4.6 源码把这三条的触发条件核了一遍。

考古｜_parent 在 ES 2.0 被重写，老索引不重建就用不上新实现

2.0 把 parent/child 的实现整个重写，parent 默认走 doc values……

官方产研

云计算

后端

大数据

2.0重写parent/child实现：_parent默认docvalues仅对新索引生效，旧索引需reindex才能获益。父类型不能先于子类型存在，top_children查询已删除。源码验证触发条件，提供reindex操作指南与验证方法，适用于腾讯云ES。

Elasticsearch 

代码解释

路由

Java

让每一个 Agent，都跑在云上

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

考古｜_parent 在 ES 2.0 被重写，老索引不重建就用不上新实现-腾讯云开发者社区-腾讯云

考古｜_parent 在 ES 2.0 被重写，老索引不重建就用不上新实现

考古｜_parent 在 ES 2.0 被重写，老索引不重建就用不上新实现

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐