When you index a document, it is stored on a single primary shard. How does Elasticsearch know which shard a document belongs to? When we create a new document, how does it know whether it should store that document on shard 1 or shard 2?
document를 색인하면, 특정 primary shard에 저장된다. Elasticsearch는 document가 어느 shard에 속해 있는지 어떻게 알까? 새로운 document를 생성하면, document를 shard 1 또는 2 중 어느 shard에 저장하는지 어떻게 알까?
The process can’t be random, since we may need to retrieve the document in the future. In fact, it is determined by a simple formula:
나중에 document를 검색해야 하기 때문에, 프로세스는 무작위로 할 수 없다. 사실, 그것은 매우 간단한 수식에 의해 결정된다.
shard = hash(routing) % number_of_primary_shards
The routing value is an arbitrary string, which defaults to the document’s _id but can also be set to a custom value. This routing string is passed through a hashing function to generate a number, which is divided by the number of primary shards in the index to return the remainder. The remainder will always be in the range 0 to number_of_primary_shards - 1, and gives us the number of the shard where a particular document lives.
routing 값은 사용자가 정의할 수도 있는, document의 _id 를 기본으로 하는, 임의의 문자열이다. 이 routing 문자열은 숫자를 생성하기 위한 hashing 함수를 거친다. 이것을 index에 있는 primary shard의 수로 나누고, 나머지(remainder) 를 돌려받는다. 나머지는 항상 0 ~ number_of_primary_shard – 1 의 범위에 있고, 특정 document가 존재하는 shard의 번호를 나타낸다.
This explains why the number of primary shards can be set only when an index is created and never changed: if the number of primary shards ever changed in the future, all previous routing values would be invalid and documents would never be found.
이는 primary shard의 수가 왜 index가 생성될 때 결정되어야 하는지, 왜 절대로 바꿀 수 없는지를 설명한다. 만약, 나중에 primary shard의 수가 바뀐다면, 이전의 모든 routing 값들은 유효하지 않고, document는 결코 찾을 수 없게 된다.
Users sometimes think that having a fixed number of primary shards makes it difficult to scale out an index later. In reality, there are techniques that make it easy to scale out as and when you need. We talk more about these in Designing for Scale.
사용자들은 때때로 primary shard의 수를 고정하는 것이, 나중에 수평확장을 어렵게 한다고 생각한다. 실제로, 필요한 경우 수평확장을 쉽게 만들어 주는 기술은 존재한다. 이에 대해서는 Designing for Scale에서 더 이야기할 것이다.
All document APIs (get, index, delete, bulk, update, and mget) accept a routing parameter that can be used to customize the document-to- shard mapping. A custom routing value could be used to ensure that all related documents—for instance, all the documents belonging to the same user—are stored on the same shard. We discuss in detail why you may want to do this in Designing for Scale.
모든 document API(get, index, delete, bulk, update, mget)는 document-to-shard mapping을 사용자 정의하는데 사용될 수 있는, routing 매개변수를 사용할 수 있다. 사용자 정의 routing 값은 모든 관련된 document(예를 들자면, 특정 사용자에게 속하는 모든 document)가 동일한 shard에 저장된다는 것을 보장하는데 사용된다. Designing for Scale에서 왜 이렇게 해야 하는지 자세히 이야기 해 보자.
'2.X > 1. Getting Started' 카테고리의 다른 글
| 1-03-13. Cheaper in Bulk (0) | 2017.10.01 |
|---|---|
| 1-04. Distributed Document Store (0) | 2017.10.01 |
| 1-04-2. How Primary and Replica Shards Interact (0) | 2017.10.01 |
| 1-04-3. Creating, Indexing, and Deleting a Document (0) | 2017.10.01 |
| 1-04-4. Retrieving a Document (0) | 2017.10.01 |