2.X/6. Modeling Your Data

6-4-11. Shared Index

drscg 2017. 9. 23. 12:58

We can use a large shared index for the many smaller forums by indexing the forum identifier in a field and using it as a filter:

포럼의 식별자를 field에 색인 하고, 그것을 filter로 사용하여, 많은 수의 작은 포럼에 대해 거대한 공유된 index를 사용할 수 있다.

PUT /forums
{
  "settings": {
    "number_of_shards": 10 
  },
  "mappings": {
    "post": {
      "properties": {
        "forum_id": { 
          "type":  "string",
          "index": "not_analyzed"
        }
      }
    }
  }
}

PUT /forums/post/1
{
  "forum_id": "baking", 
  "title":    "Easy recipe for ginger nuts",
  ...
}

수천 개의 작은 포럼을 가지기에 충분히 큰 index를 생성한다.

 

각 post는 그것이 어느 포럼에 속하는지를 식별하기 위한 forum_id 를 포함해야 한다.

We can use the forum_id as a filter to search within a single forum. The filter will exclude most of the documents in the index (those from other forums), and caching will ensure that responses are fast:

단일 포럼 내에서 검색하기 위하여, filter로써 forum_id 를 사용할 수 있다. filter는 index에 있는 대부분의 document(다른 포럼의 document)를 제외할 것이다. 그리고, caching은 빠른 response를 보장할 것이다.

GET /forums/post/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "title": "ginger nuts"
        }
      },
      "filter": {
        "term": {
          "forum_id": {
            "baking"
          }
        }
      }
    }
  }
}

This approach works, but we can do better. The posts from a single forum would fit easily onto one shard, but currently they are scattered across all ten shards in the index. This means that every search request has to be forwarded to a primary or replica of all ten shards. What would be ideal is to ensure that all the posts from a single forum are stored on the same shard.

이 방식은 동작하지만, 더 좋은 방법으로 할 수 있다. 단일 포럼의 게시물은 하나의 shard에 잘 맞겠지만, 현재 그것은 index에 있는 10개의 shard에 흩어져 있다. 즉, 모든 검색 request는 모두 10개의 primary 또는 replica에 전달되어야 한다. 단일 포럼의 모든 게시물이 동일한 shard에 저장되는 것을 보장하는 이상적인 방법은 무엇일까?

In Routing a Document to a Shard, we explained that a document is allocated to a particular shard by using this formula:

Routing a Document to a Shard에서, 아래 수식을 사용하여, document를 특정 shard에 할당하는 하는 방법을 설명했었다.

shard = hash(routing) % number_of_primary_shards

The routing value defaults to the document’s _id, but we can override that and provide our own custom routing value, such as forum_id. All documents with the same routing value will be stored on the same shard:

routing 값은 기본적으로 document의 _id 이다. 그러나, 그것을 무시하고, forum_id 같은 사용자 정의 routing 값을 제공할 수 있다. 동일한 routing 값을 가진 모든 document는 동일한 shard에 저장된다.

PUT /forums/post/1?routing=baking 
{
  "forum_id": "baking", 
  "title":    "Easy recipe for ginger nuts",
  ...
}

 

동일한 포럼의 모든 게시물은 동일한 shard에 저장된다는 것을 보장하기 위하여, routing 값으로 forum_id 를 사용한다.

When we search for posts in a particular forum, we can pass the same routing value to ensure that the search request is run on only the single shard that holds our documents:

특정 포럼의 게시물을 검색할 때, 검색 request가 document를 가지고 있는 단일 shard에서만 동작된다는 것을 보장하기 위하여, 동일한 routing 값을 전달한다.

GET /forums/post/_search?routing=baking 
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "title": "ginger nuts"
        }
      },
      "filter": {
        "term": { 
          "forum_id": {
            "baking"
          }
        }
      }
    }
  }
}

query는 이 routing 값에 대응하는 shard에서만 실행된다.

단일 shard는 많은 포럼의 게시물을 가질 수 있으므로, 여전히 filtering query가 필요하다.

Multiple forums can be queried by passing a comma-separated list of routing values, and including each forum_id in a terms query:

다수의 포럼은 콤마(,)로 구분된 routing 값을 전달하여 query될 수 있다. 그리고, terms filter에는 각각의 forum_id 가 포함되어 있다.

GET /forums/post/_search?routing=baking,cooking,recipes
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "title": "ginger nuts"
        }
      },
      "filter": {
        "terms": {
          "forum_id": {
            [ "baking", "cooking", "recipes" ]
          }
        }
      }
    }
  }
}

While this approach is technically efficient, it looks a bit clumsy because of the need to specify routing values and terms queries on every query or indexing request. Index aliases to the rescue!

이 방법은 기술적으로 효과적이지만, 모든 query나 색인 request에 routing 값과 terms query를 지정해야 하기 때문에, 약간 어설프게 보인다. index alias를 추가하면 훨씬 더 나아 보일 것이다.

'2.X > 6. Modeling Your Data' 카테고리의 다른 글

6-4-09. Retiring Data  (0) 2017.09.23
6-4-10. User-Based Data  (0) 2017.09.23
6-4-12. Faking Index per User with Aliases  (0) 2017.09.23
6-4-13. One Big User  (0) 2017.09.23
6-4-14. Scale Is Not Infinite  (0) 2017.09.23