前面文章介绍了，在es里面的几种数据组织关系，包括array[object]，nested，以及今天要说的Parent-Child。
Parent-Child与Nested非常类似，都可以用来处理一对多的关系，如果多对多的关系，那就拆分成一对多在处理。前面提到nested的缺点是对数据的更新需要reindex整个nested结构下的所有数据，所以注定了它的使用场景一定是查询多更新少的场景，如果是更新多的场景，那么nested的性能未必会很好，而Parent-Child就非常适合在更新多的场景，因为Parent-Child的数据存储都是独立的，只要求父子文档都分布在同一个shard里面即可而nested模式下，不仅要求在同一个shard下还必须是同一个sengment里面的同一个block下，这种模式注定了nested查询的性能要比Parent-Child好，但是更新性能就大大不如Parent-Child了，对比nested模式，Parent-Child主要有下面的几个特点：
（1） 父文档可以被更新，而无须重建所有的子文档
（2）子文档的添加，修改，或者删除不影响它的父文档和其他的子文档，这尤其是在子文档数量巨大而且需要被添加和更新频繁的场景下Parent-Child能获取更好的性能
（3）子文档可以被返回在搜索结果里面
ElasticSearch在内存里面维护了一个父子关系的映射表，以便于能够加速查询，这种映射使用的是doc-value，如果数据量巨大内存放不下，会自动的保存到磁盘中，当然此时性能也会下降。
下面来看一个例子，首先我们要定义mapping：
{
"order": 0,
"template": "pc_test*",
"settings": {
"index": {
"number_of_replicas": "0",
"number_of_shards": "3"
}
},
"mappings": {
"employee": {
"_parent": {
"type": "branch"
}
},
"branch": {}
},
"aliases": {}
}
branch：代表一个分公司
employee：代表员工
关系： 一个公司可以包含多个员工
下面开始插入数据，首先我们先插入公司数据：
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" }
注意插入公司数据的type是branch，数据的id用的是city字段，
添加员工数据的时候，要指定的父文档是属于哪个，这样才能把父子数据给关联到同一台机器上。
PUT /company/employee/1?parent=london
{
"name": "Alice Smith",
"dob": "1970-10-24",
"hobby": "hiking"
}
parent id字段有两个用途：
（1）它创建了连接父子文档的关系并且确保了子文档一定和父文档存在一个shard里面
（2）默认情况下es用的是文档的id字段进行hash取模分片的，如果父文档的id字段被指定，那么路由字段就是id，而在子文档中我们指定parent的值也是父文档的id字段，所以就一定确保了父子文档都在一个shard里面，在父子文档的关系中，index，update，add，delete包括search在使用的时候都必须设置路由字段，否则查询结果会出错。
继续插入子文档：
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的值改变了，必须删除这个parent下面的所有子文档然后删除本身，最后添加新的父文档，再添加新的子文档，否则parent值改变后，父文档的parent改变了，子的没改变会出现父子不在同一个shard里面，从而导致查询出错。
下面来看下，如何查询父子关系的数据，这里面主要有两个查询方法：
（1）has_child
使用子文档的字段当成查询条件，查询出符合条件的父文档的数据
一个查询例子如下：
GET /company/branch/_search
{
"query": {
"has_child": {
"type": "employee",
"query": {
"range": {
"dob": {
"gte": "1980-01-01"
}
}
}
}
}
}
这里面关于父文档的score，是由所有子文档的评分通过一个计算方法得来的，这里可以设置，有5种策略：
none：忽略评分
avg：所有子文档的平均分
min：所有子文档的最小分
max：所有子文档的最大分
sum：所有子文档的得分和
通过下面的查询，可以看出评分对排序的影响：
GET /company/branch/_search
{
"query": {
"has_child": {
"type": "employee",
"score_mode": "max",
"query": {
"match": {
"name": "Alice Smith"
}
}
}
}
}
得分设置为none拥有更快的查询性能，因为少了额外的计算
此外has_child查询还可以接受两个限制参数min_children和max_children，在查询的时候根据子文档的个数做过滤，看下面的一个例子：
GET /company/branch/_search
{
"query": {
"has_child": {
"type": "employee",
"min_children": 2,
"query": {
"match_all": {}
}
}
}
}
上面的查询仅仅查询最子文档个数符合过滤条件的父文档，has_child也可以使用filter查询。
（2）has_parent
has_parent查询和has_child相反，通过查询父文档的字段，从而得到子文档的数据。
一个例子如下：
GET /company/employee/_search
{
"query": {
"has_parent": {
"type": "branch",
"query": {
"match": {
"country": "UK"
}
}
}
}
}
has_parent也支持score_mode，有两种设置一个none，一个score因为每个child只有一个parent，所以不需要做聚合的评分。
最后看下parent-child的聚合，一个例子：
GET /company/branch/_search
{
"size" : 0,
"aggs": {
"country": {
"terms": {
"field": "country"
},
"aggs": {
"employees": {
"children": {
"type": "employee"
},
"aggs": {
"hobby": {
"terms": {
"field": "hobby"
}
}
}
}
}
}
}
}
上面聚合的意思是：
按国家分组，然后算组内的员工再根据其爱好进行分组
最后，parent-child模式，支持多层的关系
一个对多对多，目前官网上给出了3层关系的例子，从社区上来看说是支持无限层级的关系映射，但是超过3层的映射，官网没有给出使用例子，具体的使用还得使用者去测试，不过现实情况包含3级以上的关系数据应该非常少了。
一个的3级例子的mapping：
PUT /company
{
"mappings": {
"country": {},
"branch": {
"_parent": {
"type": "country"
}
},
"employee": {
"_parent": {
"type": "branch"
}
}
}
}
多了一级国家的映射，总体的关系是：
一个国家可以有多个分公司，每个分公司又可以有多个员工
看下，数据例子：
（1）先插入国家数据
POST /company/country/_bulk
{ "index": { "_id": "uk" }}
{ "name": "UK" }
{ "index": { "_id": "france" }}
{ "name": "France" }
（2）在插入公司数据
POST /company/branch/_bulk
{ "index": { "_id": "london", "parent": "uk" }}
{ "name": "London Westmintster" }
{ "index": { "_id": "liverpool", "parent": "uk" }}
{ "name": "Liverpool Central" }
{ "index": { "_id": "paris", "parent": "france" }}
{ "name": "Champs Élysées" }
注意parent是父的，公司的route用的是city
（3）插入员工数据
PUT /company/employee/1?parent=london&routing=uk
{
"name": "Alice Smith",
"dob": "1970-10-24",
"hobby": "hiking"
}
第三层的插入数据用了parent字段来确保和父文档的关联，又用了routding字段来确保和父文档，祖父文档位于同一个shard里面。
注意如果超过3层，routing字段一定最顶层的文档的路由值，而parent字段则是其真正的关联的父文档。超过3层的映射官网没有给出例子，具体是否是那样用的，有兴趣的朋友可以自行测试，多层的父子关系会消耗更多的内存，以及性能更糟糕所以设计上应该尽量避免出现这种情况，此外如果非得设计，注意parent id字段应该尽量短的，从而在doc value中获的更好的压缩以减少使用的内存。
参考文章：
[url]https://discuss.elastic.co/t/would-it-be-possible-the-relation-grate-grandparent-grate-grandchild-in-elasticsearch/26875/4
[/url]