理解elasticsearch的parent-child关系

前面文章介绍了，在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中获的更好的压缩以减小使用的内存。

https://discuss.elastic.co/t/would-it-be-possible-the-relation-grate-grandparent-grate-grandchild-in-elasticsearch/26875/4