6-3-6. Grandparents and Grandchildren

The parent-child relationship can extend across more than one generation—grandchildren can have grandparents—but it requires an extra step to ensure that documents from all generations are indexed on the same shard.

부모-자식 관계는 한 세대이상으로 확장(손자는 조부모를 가질 수 있다)될 수 있다. 그러나, 모든 세대의 document가 동일한 shard에 색인되는지를 보장하기 위한, 추가 단계가 필요하다.

Let’s change our previous example to make the country type a parent of the branch type:

country type을 branch type의 부모로 만들기 위해, 이전 예제를 변경해 보자.

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

	branch 는 country 의 자식이다.
	employee 는 branch 의 자식이다.

Countries and branches have a simple parent-child relationship, so we use the same process as we used in Indexing Parents and Children:

country와 branch는 단순한 부모-자식 관계를 가진다. 따라서, Indexing Parents and Children에서 사용했던 것과, 동일한 프로세스를 사용한다.

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" }

The parent ID has ensured that each branch document is routed to the same shard as its parent country document. However, look what would happen if we were to use the same technique with the employee grandchildren:

parent ID는 각 branch document가 자신의 부모인 country document와 동일한 shard에 routing 되는 것을 보장한다. 그러면, 손자인 employee 에 동일한 기술을 사용한다면, 어떤 일이 발생하는 지를 살펴보자.

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

The shard routing of the employee document would be decided by the parent ID—london—but the london document was routed to a shard by its own parent ID—uk. It is very likely that the grandchild would end up on a different shard from its parent and grandparent, which would prevent the same-shard parent-child mapping from functioning.

employee document의 shard routing은, 부모 ID(london)에 의해, 결정된다. 그러나 london document는, 자신의 부모 ID(uk)에 의해, shard로 routing 된다. 손자는 부모, 조부모와는 다른 shard로 routing될 가능성이 매우 높다. 따라서 부모-자식이 동일한 shard에 mapping되는 것을 막을 것이다.

Instead, we need to add an extra routing parameter, set to the ID of the grandparent, to ensure that all three generations are indexed on the same shard. The indexing request should look like this:

대신, 모든 3 세대가 동일한 shard에 색인되는 것을 보장하기 위하여, 추가로 routing 매개변수에 조부모의 ID를 설정하여, 추가해야 한다. 색인 request는 다음과 같아야 한다.

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

routing 값은 parent 값을 우선한다.

The parent parameter is still used to link the employee document with its parent, but the routingparameter ensures that it is stored on the same shard as its parent and grandparent. The routingvalue needs to be provided for all single-document requests.

parent 매개변수는 여전히 employee document를 부모와 연결하는데 사용된다. 그러나 routing 매개변수는 손자가 부모, 조부모와 동일한 shard에 저장된다는 것을 보장한다. routing 값은 모든 단일 document request에 제공되어야 한다.

Querying and aggregating across generations works, as long as you step through each generation. For instance, to find countries where employees enjoy hiking, we need to join countries with branches, and branches with employees:

세대에 걸친 query와 aggregation은 각 세대를 통해 단계적으로 동작한다. 예를 들면, 직원들이 하이킹을 즐기는 나라를 찾기 위해서는, 지점이 있는 나라, 그리고 직원을 가진 지점과 join해야 한다.

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