祖辈与孙辈关系

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

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

  1. PUT /company
  2. {
  3. "mappings": {
  4. "country": {},
  5. "branch": {
  6. "_parent": {
  7. "type": "country" (1)
  8. }
  9. },
  10. "employee": {
  11. "_parent": {
  12. "type": "branch" (2)
  13. }
  14. }
  15. }
  16. }

<1> branchcountry 的子辈。

<2> employeebranch 的子辈。

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

  1. POST /company/country/_bulk
  2. { "index": { "_id": "uk" }}
  3. { "name": "UK" }
  4. { "index": { "_id": "france" }}
  5. { "name": "France" }
  6. POST /company/branch/_bulk
  7. { "index": { "_id": "london", "parent": "uk" }}
  8. { "name": "London Westmintster" }
  9. { "index": { "_id": "liverpool", "parent": "uk" }}
  10. { "name": "Liverpool Central" }
  11. { "index": { "_id": "paris", "parent": "france" }}
  12. { "name": "Champs Élysées" }

parent ID 使得每一个 branch 文档被路由到与其父文档 country 相同的分片上进行操作。然而,当我们使用相同的方法来操作 employee 这个孙辈文档时,会发生什么呢?

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

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

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

  1. PUT /company/employee/1?parent=london&routing=uk <1>
  2. {
  3. "name": "Alice Smith",
  4. "dob": "1970-10-24",
  5. "hobby": "hiking"
  6. }

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

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

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

  1. GET /company/country/_search
  2. {
  3. "query": {
  4. "has_child": {
  5. "type": "branch",
  6. "query": {
  7. "has_child": {
  8. "type": "employee",
  9. "query": {
  10. "match": {
  11. "hobby": "hiking"
  12. }
  13. }
  14. }
  15. }
  16. }
  17. }
  18. }