6-4-01. The Unit of Scale

In Dynamically Updatable Indices, we explained that a shard is a Lucene index and that an Elasticsearch index is a collection of shards. Your application talks to an index, and Elasticsearch routes your requests to the appropriate shards.

Dynamically Updatable Indices에서, shard는 Lucene의 index 이고, Elasticsearch의 index는 shard의 집합이라고 설명했었다. 응용프로그램이 index에 request하면, Elasticsearch는 적절한 shard에 해당 request를 전달(route)한다.

A shard is the unit of scale. The smallest index you can have is one with a single shard. This may be more than sufficient for your needs—a single shard can hold a lot of data—but it limits your ability to scale.

shard는 확장의 단위(unit of scale) 이다. 가질 수 있는 가장 작은 index는 단일 shard를 가진 index이다. 이것은 여러분의 요구 (단일 shard는 많은 데이터를 가질 수 있다) 이상으로 충분하겠지만, 확장을 제한한다.

Imagine that our cluster consists of one node, and in our cluster we have one index, which has only one shard:

cluster가 하나의 node로 구성되어 있고, 그 cluster 안에, 하나의 shard만을 가진, 하나의 index를 가지고 있다고 가정해 보자.

PUT /my_index
{
  "settings": {
    "number_of_shards":   1, 
    "number_of_replicas": 0
  }
}

replica shard 없이, 하나의 primary shard만을 가진 index를 생성.

This setup may be small, but it serves our current needs and is cheap to run.

이 설정은 작지만, 현재의 요구 사항을 충족시키며, 저렴하게 실행된다.

At the moment we are talking about only primary shards. We discuss replica shards in Replica Shards.

지금은 primary shards에 대해서만 이야기하고 있다. Replica Shards에서 replica shards에 대해서 이야기할 것이다.

One glorious day, the Internet discovers us, and a single node just can’t keep up with the traffic. We decide to add a second node, as per Figure 49, “확장 요소가 없는, 단일 shard로 구성된 index”. What happens?

어느 날, 인터넷이 이 cluster를 발견했고, 단일 node로는 더 이상 트래픽을 감당할 수 없게 되었다.Figure 49, “확장 요소가 없는, 단일 shard로 구성된 index”처럼, 두 번째 node를 추가하기로 결정했다. 어떻게 될까?

Figure 49. 확장 요소가 없는, 단일 shard로 구성된 index

The answer is: nothing. Because we have only one shard, there is nothing to put on the second node. We can’t increase the number of shards in the index, because the number of shards is an important element in the algorithm used to route documents to shards:

정답은 아무 일도 일어나지 않는다 이다. 단 하나의 shard만을 가지고 있기 때문에, 두 번째 node에 넣을 게 아무것도 없다. shard의 수는 document를 shard에 전달하는 경우에 사용되는 알고리즘에서 중요한 요소이기 때문에, index에 있는 shard의 수를 증가시킬 수 없다.

shard = hash(routing) % number_of_primary_shards

Our only option now is to reindex our data into a new, bigger index that has more shards, but that will take time that we can ill afford. By planning ahead, we could have avoided this problem completely by overallocating.

현재, 우리의 유일한 선택은, 더 많은 shard를 가진, 더 큰, 새로운 index에, 데이터를 다시 색인하는 것이다. 하지만 시간이 낭비된다. 미리 계획을 하면, 초과 할당(overallocation) 으로, 이 문제를 완전히 방지할 수 있다.