parent-child关系，类似于nested模型，区别在于，nested objects文档中，所有对象都在同一个文档中，而parent-child关系文档中，父对象和子
使用场景：子文档数量较多，并且子文档创建和修改的频率高时。
与nested objects相比，parent-child关系的优势有：
更新父文档时，不会重新索引子文档。
对父-子文档关系有个限制条件：父文档和其所有子文档，都必须要存储在同一个分片中。
Parent-Child关系文档映射 建立父-子文档映射关系时只需要指定某一个文档 type 是另一个文档 type 的父亲。 该关系可以在如下两个时间点设置：1）创建索引时；2）在子文档 type 创建之前更新父文档的 mapping。
举例说明，有一个公司在多个城市有分公司，并且每一个分公司下面都有很多员工。
在创建员工 employee 文档 type 时，指定分公司 branch 的文档 type 为其父亲。
1 2 3 4 5 6 7 8 9 10 11 PUT /company { "mappings": { "branch": {}, "employee": { "_parent": { "type": "branch" } } } }
employee 文档 是 branch 文档的子文档。
构建Parent-Child文档索引 为父文档创建索引与为普通文档创建索引没有区别。父文档并不需要知道它有哪些子文档。
1 2 3 4 5 6 7 POST /company/branch/_bulk { "index": { "_id": "london" }} { "name": "London Westminster", "city": "London", "country": "UK" } { "index": { "_id": "liverpool" }} { "name": "Liverpool Central", "city": "Liverpool", "country": "UK" } { "index": { "_id": "paris" }} { "name": "Champs Élysées", "city": "Paris", "country": "France" }
创建子文档时，用户必须要通过 parent 参数来指定该子文档的父文档 ID：
1 2 3 4 5 6 PUT /company/employee/1?parent=london { "name": "Alice Smith", "dob": "1970-10-24", "hobby": "hiking" }
当前 employee 文档的父文档 ID 是 london 。如此保证了父文档和子文档都在同一个分片上。
分片路由的计算公式如下：
shard = hash(routing) % number_of_primary_shards
如果指定了父文档的 ID，那么就会使用父文档的 ID 进行路由，而不会使用当前文档 _id。也就是说，如果父文档和子文档都使用相同的值进行路由，那么父文档和子文档都会确定分布在同一个分片上。
在执行单文档的请求时需要指定父文档的 ID，单文档请求包括：通过 GET 请求获取一个子文档；创建、更新或删除一个子文档。而执行搜索请求时是不需要指定父文档的ID，这是因为搜索请求是向一个索引中的所有分片发起请求，而单文档的操作是只会向存储该文档的分片发送请求。因此，如果操作单个子文档时不指定父文档的 ID，那么很有可能会把请求发送到错误的分片上。
1 2 3 4 5 6 7 POST /company/employee/_bulk { "index": { "_id": 2, "parent": "london" }} { "name": "Mark Thomas", "dob": "1982-05-16", "hobby": "diving" } { "index": { "_id": 3, "parent": "liverpool" }} { "name": "Barry Smith", "dob": "1979-04-01", "hobby": "hiking" } { "index": { "_id": 4, "parent": "paris" }} { "name": "Adrien Grand", "dob": "1987-05-11", "hobby": "horses" }
如果你想要改变一个子文档的 parent 值，仅通过更新这个子文档是不够的，因为新的父文档有可能在另外一个分片上。因此，你必须要先把子文档删除，然后再重新索引这个子文档。