Elasticsearch关联查询-父子文档

最新推荐文章于 2025-07-02 10:57:05 发布

原创最新推荐文章于 2025-07-02 10:57:05 发布 · 1.4w 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch

elasticsearch 专栏收录该内容

20 篇文章

订阅专栏

本文详细介绍了Elasticsearch中的父-子文档关系，包括其与nested模型的区别、映射设置、查询方式，如通过子文档查询父文档、has_child和has_parent查询，以及如何处理多代关系。重点阐述了在构建索引、查询和聚合时如何确保父-子文档位于同一分片以优化性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

父-子关系文档

父-子关系文档在实质上类似于 nested model ：允许将一个对象实体和另外一个对象实体关联起来。而这两种类型的主要区别是：在 nested objects 文档中，所有对象都是在同一个文档中，而在父-子关系文档中，父对象和子对象都是完全独立的文档。

父-子关系的主要作用是允许把一个 type 的文档和另外一个 type 的文档关联起来，构成一对多的关系：一个父文档可以对应多个子文档。与 nested objects 相比，父-子关系的主要优势有：

更新父文档时，不会重新索引子文档。
创建，修改或删除子文档时，不会影响父文档或其他子文档。这一点在这种场景下尤其有用：子文档数量较多，并且子文档创建和修改的频率高时。
子文档可以作为搜索结果独立返回。
Elasticsearch 维护了一个父文档和子文档的映射关系，得益于这个映射，父-子文档关联查询操作非常快。但是这个映射也对父-子文档关系有个限制条件：父文档和其所有子文档，都必须要存储在同一个分片中。

父-子文档ID映射存储在 Doc Values 中。当映射完全在内存中时， Doc Values 提供对映射的快速处理能力，另一方面当映射非常大时，可以通过溢出到磁盘提供足够的扩展能力。

父-子关系文档映射

建立父-子文档映射关系时只需要指定某一个文档 type 是另一个文档 type 的父亲。该关系可以在如下两个时间点设置：1）创建索引时；2）在子文档 type 创建之前更新父文档的 mapping。

举例说明，有一个公司在多个城市有分公司，并且每一个分公司下面都有很多员工。有这样的需求：按照分公司、员工的维度去搜索，并且把员工和他们工作的分公司联系起来。针对该需求，用嵌套模型是无法实现的。当然，如果使用 application-side-joins 或者 data denormalization 也是可以实现的，但是为了演示的目的，在这里我们使用父-子文档。

我们需要告诉Elasticsearch，在创建员工 employee 文档 type 时，指定分公司 branch 的文档 type 为其父亲。

PUT /company
{
  "mappings": {
    "branch": {},
    "employee": {
      "_parent": {
        "type": "branch" //employee 文档 是 branch 文档的子文档。
      }
    }
  }
}

构建父-子文档索引

为父文档创建索引与为普通文档创建索引没有区别。父文档并不需要知道它有哪些子文档。

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：

PUT /company/employee/1?parent=london 
{
  "name":  "Alice Smith",
  "dob":   "1970-10-24",
  "hobby": "hiking"
}

上面parent=lodin表示当前 employee 文档的父文档 ID 是 london 。

父文档 ID 有两个作用：创建了父文档和子文档之间的关系，并且保证了父文档和子文档都在同一个分片上。

在路由一个文档到一个分片中中，我们解释了 Elasticsearch 如何通过路由值来决定该文档属于哪一个分片，路由值默认为该文档的 _id 。分片路由的计算公式如下：

shard = hash(routing) % number_of_primary_shards
如果指定了父文档的 ID，那么就会使用父文档的 ID 进行路由，而不会使用当前文档 _id 。也就是说，如果父文档和子文档都使用相同的值进行路由，那么父文档和子文档都会确定分布在同一个分片上。

在执行单文档的请求时需要指定父文档的 ID，单文档请求包括：通过 GET 请求获取一个子文档；创建、更新或删除一个子文档。而执行搜索请求时是不需要指定父文档的ID，这是因为搜索请求是向一个索引中的所有分片发起请求，而单文档的操作是只会向存储该文档的分片发送请求。因此，如果操作单个子文档时不指定父文档的 ID，那么很有可能会把请求发送到错误的分片上。

父文档的 ID 应该在 bulk API 中指定

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 值，仅通过更新这个子文档是不够的，因为新的父文档有可能在另外一个分片上。因此，你必须要先把子文档删除，然后再重新索引这个子文档。

通过子文档查询父文档

has_child 的查询和过滤可以通过子文档的内容来查询父文档。例如，我们根据如下查询，可查出所有80后员工所在的分公司：

GET /company/branch/_search
{
  "query": {
    "has_child": {
      "type": "employee",
      "query": {
        "range": {
          "dob": {
            "gte": "1980-01-01"
          }
        }
      }
    }
  }
}

类似于 nested query ，has_child 查询可以匹配多个子文档，并且每一个子文档的评分都不同。但是由于每一个子文档都带有评分，这些评分如何规约成父文档的总得分取决于 score_mode 这个参数。该参数有多种取值策略：默认为 none ，会忽略子文档的评分，并且会给父文档评分设置为 1.0 ；除此以外还可以设置成 avg 、 min 、 max 和 sum 。

下面的查询将会同时返回 london 和 liverpool ，不过由于 Alice Smith 要比 Barry Smith 更加匹配查询条件，因此 london 会得到一个更高的评分。

GET /company/branch/_search
{
  "query": {
    "has_child": {
      "type":       "employee",
      "score_mode": "max",
      "query": {
        "match": {
          "name": "Alice Smith"
        }
      }
    }
  }
}

score_mode 为默认的 none 时，会显著地比其模式要快，这是因为Elasticsearch不需要计算每一个子文档的评分。只有当你真正需要关心评分结果时，才需要为 score_mode 设值，例如设成 avg 、 min 、 max 或 sum 。

min_children 和 max_children

has_child 的查询和过滤都可以接受这两个参数：min_children 和 max_children 。使用这两个参数时，只有当子文档数量在指定范围内时，才会返回父文档。

如下查询只会返回至少有两个雇员的分公司：

GET /company/branch/_search
{
  "query": {
    "has_child": {
      "type":         "employee",
      "min_children": 2, 
      "query": {
        "match_all": {}
      }
    }
  }
}

至少有两个雇员的分公司才会符合查询条件。

带有 min_children 和 max_children 参数的 has_child 查询或过滤，和允许评分的 has_child 查询的性能非常接近。

has_child Filter

has_child 查询和过滤在运行机制上类似，区别是 has_child 过滤不支持 score_mode 参数。has_child 过滤仅用于筛选内容–如内部的一个 filtered 查询–和其他过滤行为类似：包含或者排除，但没有进行评分。

has_child 过滤的结果没有被缓存，但是 has_child 过滤内部的过滤方法适用于通常的缓存规则。

通过父文档查询子文档

虽然 nested 查询只能返回最顶层的文档，但是父文档和子文档本身是彼此独立并且可被单独查询的。我们使用 has_child 语句可以基于子文档来查询父文档，使用 has_parent 语句可以基于父文档来查询子文档。

has_parent 和 has_child 非常相似，下面的查询将会返回所有在 UK 工作的雇员：

GET /company/employee/_search
{
  "query": {
    "has_parent": {
      "type": "branch", 
      "query": {
        "match": {
          "country": "UK"
        }
      }
    }
  }
}

返回父文档 type 是 branch 的所有子文档

has_parent 查询也支持 score_mode 这个参数，但是该参数只支持两种值： none （默认）和 score 。每个子文档都只有一个父文档，因此这里不存在将多个评分规约为一个的情况， score_mode 的取值仅为 score 和 none 。

不带评分的 has_parent 查询

当 has_parent 查询用于非评分模式（比如 filter 查询语句）时， score_mode 参数就不再起作用了。因为这种模式只是简单地包含或排除文档，没有评分，那么 score_mode 参数也就没有意义了。

子文档聚合

在父-子文档中支持子文档聚合，这一点和嵌套聚合类似。但是，对于父文档的聚合查询是不支持的（和 reverse_nested 类似）。

我们通过下面的例子来演示按照国家维度查看最受雇员欢迎的业余爱好：

GET /company/branch/_search
{
  "size" : 0,
  "aggs": {
    "country": {
      "terms": { 
        "field": "country"
      },
      "aggs": {
        "employees": {
          "children": { 
            "type": "employee"
          },
          "aggs": {
            "hobby": {
              "terms": { 
                "field": "hobby"
              }
            }
          }
        }
      }
    }
  }
}

country 是 branch 文档的一个字段。
子文档聚合查询通过 employee type 的子文档将其父文档聚合在一起。
hobby 是 employee 子文档的一个字段。

祖辈与孙辈关系

父子关系可以延展到更多代关系，比如生活中孙辈与祖辈的关系 — 唯一的要求是满足这些关系的文档必须在同一个分片上被索引。

让我们把上一个例子中的 country 类型设定为 branch 类型的父辈：

PUT /company
{
  "mappings": {
    "country": {},
    "branch": {
      "_parent": {
        "type": "country" 
      }
    },
    "employee": {
      "_parent": {
        "type": "branch" 
      }
    }
  }
}

branch 是 country 的子辈。
employee 是 branch 的子辈。

country 和 branch 之间是一层简单的父子关系，所以我们的操作步骤与之前保持一致：

POST /company/country/_bulk
{ "index": { "_id": "uk" }}
{ "name": "UK" }
{ "index": { "_id": "france" }}
{ "name": "France" }

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 ID 使得每一个 branch 文档被路由到与其父文档 country 相同的分片上进行操作。然而，当我们使用相同的方法来操作 employee 这个孙辈文档时，会发生什么呢？

PUT /company/employee/1?parent=london
{
  "name":  "Alice Smith",
  "dob":   "1970-10-24",
  "hobby": "hiking"
}

employee 文档的路由依赖其父文档 ID — 也就是 london — 但是 london 文档的路由却依赖其本身的父文档 ID — 也就是 uk 。此种情况下，孙辈文档很有可能最终和父辈、祖辈文档不在同一分片上，导致不满足祖辈和孙辈文档必须在同一个分片上被索引的要求。

解决方案是添加一个额外的 routing 参数，将其设置为祖辈的文档 ID ，以此来保证三代文档路由到同一个分片上。索引请求如下所示：

PUT /company/employee/1?parent=london&routing=uk 
{
  "name":  "Alice Smith",
  "dob":   "1970-10-24",
  "hobby": "hiking"
}

routing 的值会取代 parent 的值作为路由选择。

parent 参数的值仍然可以标识 employee 文档与其父文档的关系，但是 routing 参数保证该文档被存储到其父辈和祖辈的分片上。routing 值在所有的文档请求中都要添加。

联合多代文档进行查询和聚合是可行的，只需要一代代的进行设定即可。例如，我们要找到哪些国家的雇员喜欢远足旅行，此时只需要联合 country 和 branch，以及 branch 和 employee：

GET /company/country/_search
{
  "query": {
    "has_child": {
      "type": "branch",
      "query": {
        "has_child": {
          "type": "employee",
          "query": {
            "match": {
              "hobby": "hiking"
            }
          }
        }
      }
    }
  }
}