parent-child关系,类似于nested模型,区别在于,nested objects文档中,所有对象都在同一个文档中,而parent-child关系文档中,父对象和子
对象都是完全独立的文档。
使用场景:子文档数量较多,并且子文档创建和修改的频率高时。
与nested objects相比,parent-child关系的优势有:
更新父文档时,不会重新索引子文档。
创建,修改或删除子文档时,不会影响父文档或其他子文档。
子文档可以作为搜索结果独立返回。
对父-子文档关系有个限制条件:父文档和其所有子文档,都必须要存储在同一个分片中。
Parent-Child关系文档映射
建立父-子文档映射关系时只需要指定某一个文档 type 是另一个文档 type 的父亲。 该关系可以在如下两个时间点设置:1)创建索引时;2)在子文档 type 创建之前更新父文档的 mapping。
举例说明,有一个公司在多个城市有分公司,并且每一个分公司下面都有很多员工。
在创建员工 employee 文档 type 时,指定分公司 branch 的文档 type 为其父亲。
1 | PUT /company |
employee 文档 是 branch 文档的子文档。
构建Parent-Child文档索引
为父文档创建索引与为普通文档创建索引没有区别。父文档并不需要知道它有哪些子文档。
1 | POST /company/branch/_bulk |
创建子文档时,用户必须要通过 parent 参数来指定该子文档的父文档 ID:
1 | PUT /company/employee/1?parent=london |
当前 employee 文档的父文档 ID 是 london 。如此保证了父文档和子文档都在同一个分片上。
分片路由的计算公式如下:
shard = hash(routing) % number_of_primary_shards
如果指定了父文档的 ID,那么就会使用父文档的 ID 进行路由,而不会使用当前文档 _id。也就是说,如果父文档和子文档都使用相同的值进行路由,那么父文档和子文档都会确定分布在同一个分片上。
在执行单文档的请求时需要指定父文档的 ID,单文档请求包括:通过 GET 请求获取一个子文档;创建、更新或删除一个子文档。而执行搜索请求时是不需要指定父文档的ID,这是因为搜索请求是向一个索引中的所有分片发起请求,而单文档的操作是只会向存储该文档的分片发送请求。因此,如果操作单个子文档时不指定父文档的 ID,那么很有可能会把请求发送到错误的分片上。
1 | POST /company/employee/_bulk |
如果你想要改变一个子文档的 parent 值,仅通过更新这个子文档是不够的,因为新的父文档有可能在另外一个分片上。因此,你必须要先把子文档删除,然后再重新索引这个子文档。