父子关系可以延展到更多代关系，比如生活中孙辈与祖辈的关系 — 唯一的要求是满足这些关系的文档必须在同一个分片上被索引。
让我们把上一个例子中的 country 类型设定为 branch 类型的父辈：
PUT /company
{
"mappings": {
"country": {},
"branch": {
"_parent": {
"type": "country" (1)
}
},
"employee": {
"_parent": {
"type": "branch" (2)
}
}
}
}-
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 (1)
{
"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"
}
}
}
}
}
}
}