6-4-06. Multiple Indices

Finally, remember that there is no rule that limits your application to using only a single index. When we issue a search request, it is forwarded to a copy (a primary or a replica) of all the shards in an index. If we issue the same search request on multiple indices, the exact same thing happens—there are just more shards involved.

마지막으로, 응용프로그램이 단일 index만을 사용하도록 제한하는 규칙은 없다는 점을 기억하자. 어떤 검색 request를 하면, 그것은 index에 있는 모든 shard의 복사본(primary나 replica)으로 전달된다. 만약 다수의 index에 동일한 검색을 request하면, 정확히 동일한 일이 발생한다. 단지 참여하는 shard가 더 많이 있을 뿐이다.

Searching 1 index of 50 shards is exactly equivalent to searching 50 indices with 1 shard each: both search requests hit 50 shards.

50개의 shard를 가진 하나의 index를 검색하는 것은, 하나의 shard를 가진 50개의 index를 검색하는 것과 정확히 동일하다. 각각, 모두 50개의 shard에 검색을 request한다.

This can be a useful fact to remember when you need to add capacity on the fly. Instead of having to reindex your data into a bigger index, you can just do the following:

이것은 즉석에서 바로 용량을 추가해야 하는 경우에, 기억해야 할 유용한 사실이 될 수 있다. 데이터를 더 큰 index로 다시 색인하지 않고, 다음과 같이 하면 된다.

• Create a new index to hold new data.

  새로운 데이터를 가질 새로운 index를 생성한다.

• Search across both indices to retrieve new and old data.

  신규 및 기존 데이터를 가져오기 위해, 양쪽 index 모두를 검색한다.

In fact, with a little forethought, adding a new index can be done in a completely transparent way, without your application ever knowing that anything has changed.

사실, 약간만 생각해보면, 새로운 index를 추가하는 것은 응용프로그램이 어떤 것이 변경되었는지 조차 알 수 없게, 완전히 쉽게 할 수 있다.

In Index Aliases and Zero Downtime, we spoke about using an index alias to point to the current version of your index. For instance, instead of naming your index tweets, name it tweets_v1. Your application would still talk to tweets, but in reality that would be an alias that points to tweets_v1. This allows you to switch the alias to point to a newer version of the index on the fly.

Index Aliases and Zero Downtime에서, index의 현재 버전을 가리키는, index alias의 사용에 대해서 이야기했었다. 예를 들어, index의 이름을 tweets 라 하지 않고, tweet_v1 이라 한다. 응용프로그램은 여전히 tweets 과 통신한다. 그러나, 실제로는, tweet_v1 을 가리키는 alias일 것이다. 이렇게 하면, 즉석에서 index의 최신 버전을 가리키도록, alias를 전환할 수 있다.

A similar technique can be used to expand capacity by adding a new index. It requires a bit of planning because you will need two aliases: one for searching and one for indexing:

유사한 기술이, 새로운 index를 추가하여 용량을 확장하는데 사용될 수 있다. 검색을 위해서 하나, 색인을 위해서 하나, 두 개의 alias가 필요하기 때문에, 약간의 계획이 필요하다.

PUT /tweets_1/_alias/tweets_search 
PUT /tweets_1/_alias/tweets_index 

tweets_search 와 tweets_index alias 양쪽 모두는 index tweets_1 을 가리킨다.

New documents should be indexed into tweets_index, and searches should be performed against tweets_search. For the moment, these two aliases point to the same index.

새로운 document는 tweets_index 에 색인될 것이고, 검색은 tweets_search 에 대해 수행될 것이다. 지금, 이들 두 개의 alias는 동일한 index를 가리킨다.

When we need extra capacity, we can create a new index called tweets_2 and update the aliases as follows:

추가 용량이 필요한 경우, tweets_2 라 불리는 새로운 index를 생성하고, alias를 다음과 같이 업데이트할 수 있다.

POST /_aliases
{
  "actions": [
    { "add":    { "index": "tweets_2", "alias": "tweets_search" }}, 
    { "remove": { "index": "tweets_1", "alias": "tweets_index"  }}, 
    { "add":    { "index": "tweets_2", "alias": "tweets_index"  }}  
  ]
}

	tweets_search alias에 index tweets_2 를 추가한다.
	tweets_index alias를 tweets_1 에서 tweets_2 로 전환한다.

A search request can target multiple indices, so having the search alias point to tweets_1 and tweets_2 is perfectly valid. However, indexing requests can target only a single index. For this reason, we have to switch the index alias to point to only the new index.

검색 request는 다수의 index를 대상으로 할 수 있으므로, tweets_1 과 tweets_2 를 가리키는 검색 alias는 완벽하게 유효하다. 그러나, 색인 request는 오직 하나의 index만을 대상으로 할 수 있다. 이런 이유로, 새로운 index만을 가리키도록, index alias를 전환해야 한다.

A document GET request, like an indexing request, can target only one index. This makes retrieving a document by ID a bit more complicated in this scenario. Instead, run a search request with the ids query, or do a multi-get request on tweets_1 and tweets_2.

색인 request와 마찬가지로, document GET request도 오직 하나의 index만을 대상으로 할 수 있다. 이것은 이 시나리오에서, 약간 더 복잡한 ID에 의해 document를 가져오도록 한다. 대신, ids query로 검색 request를 실행하거나, tweets_1 과 tweets_2 에 대한 multi-getrequest로 하자.

Using multiple indices to expand index capacity on the fly is of particular benefit when dealing with time-based data such as logs or social-event streams, which we discuss in the next section.

log나 SNS처럼, 시간에 기반한 데이터를 처리하는 경우, 즉석에서 색인 용량을 확장하기 위하여, 다수의 index를 사용하는 것에, 특히 도움이 된다. 바로 다음에서 이야기할 것이다.