To add data to Elasticsearch, we need an index—a place to store related data. In reality, an index is just a logical namespace that points to one or more physical shards.
Elasticsearch에 데이터를 추가하기 위해서는, 관련된 데이터를 저장할 수 있는 장소인 index 가 필요하다.실제로, index는 하나 이상의 물리적인 shards 를 가리키는 logical namespace 이다.
A shard is a low-level worker unit that holds just a slice of all the data in the index. In Inside a Shard, we explain in detail how a shard works, but for now it is enough to know that a shard is a single instance of Lucene, and is a complete search engine in its own right. Our documents are stored and indexed in shards, but our applications don’t talk to them directly. Instead, they talk to an index.
shard 는 index에 있는 모든 data의 일부만을 가진, low-level worker-unit 이다. Inside a Shard에서 shard가 동작하는 방법에 대해 자세히 설명하겠지만, 지금은 각 shard가 Lucene의 single instance이고, 그 자체로 완벽한 검색 엔진이라는 것을 아는 것으로 충분하다. document는 shard에 저장되고, 색인된다. 그러나 응용프로그램은 shard와 직접 통신하지 않고, index와 통신한다.
Shards are how Elasticsearch distributes data around your cluster. Think of shards as containers for data. Documents are stored in shards, and shards are allocated to nodes in your cluster. As your cluster grows or shrinks, Elasticsearch will automatically migrate shards between nodes so that the cluster remains balanced.
shard는 Elasticsearch가 cluster에 데이터를 분산하는 방법이다. 데이터 저장소로서 shard를 생각해 보자. document는 shard에 저장되고, shard는 cluster내 node에 할당된다. cluster가 증가/감소함에 따라, Elasticsearch는 cluster가 균형이 맞도록, 자동으로 node간에 shard를 이동시킨다.
A shard can be either a primary shard or a replica shard. Each document in your index belongs to a single primary shard, so the number of primary shards that you have determines the maximum amount of data that your index can hold.
shard는 primary shard나 replica shard가 될 수 있다. index에 있는 각각의 document는 하나의 primary shard에 속한다. 그래서 primary shard의 수는 index가 가질 수 있는 데이터의 최대값을 결정한다.
While a primary shard can technically contain up to Integer.MAX_VALUE - 128 documents, the practical limit depends on your use case: the hardware you have, the size and complexity of your documents, how you index and query your documents, and your expected response times.
primary shard는 기술적으로 ( Integer.MAX_VALUE - 128 ) 개의 document를 포함할 수 있지만, 실질적인 한계는 사용 사례에 달려 있다. 가지고 있는 H/W, document의 크기나 복잡함, document를 색인하고 검색하는 방법, 기대하는 response 시간 등등
A replica shard is just a copy of a primary shard. Replicas are used to provide redundant copies of your data to protect against hardware failure, and to serve read requests like searching or retrieving a document.
replica shard는 단순히 primary shard의 복사본이다. replica는 H/W 장애로부터 데이터를 보호하기 위하여, 여분의 복사본을 제공하고, document를 검색하거나 가져오는 것과 같은, 읽기 request를 처리하는데 사용된다.
The number of primary shards in an index is fixed at the time that an index is created, but the number of replica shards can be changed at any time.
index에 있는 primary shard의 수는 index가 생성되는 시점에 고정된다. 그러나 replica shard의 수는 어느 때라도 변경할 수 있다.
Let’s create an index called blogs in our empty one-node cluster. By default, indices are assigned five primary shards, but for the purpose of this demonstration, we’ll assign just three primary shards and one replica (one replica of every primary shard):
비어있는 하나의 node를 가진 cluster에 blogs 라 불리는 index를 생성해 보자. 기본적으로 indices는 5개의 primary shard를 할당한다. 그러나 설명을 위해, 3개의 primary shard와 1개의 replica를 할당하자. (모든 primary shard에 대해 하나씩의 replica)
PUT /blogs { "settings" : { "number_of_shards" : 3, "number_of_replicas" : 1 } }
Our cluster now looks like Figure 2, “하나의 index를 가진 단일 node cluster”. All three primary shards have been allocated to Node 1.
cluster는 이제 Figure 2, “하나의 index를 가진 단일 node cluster”처럼 보일 것이다. Node 1 에 모두 3개의 primary shard가 할당되었다.
If we were to check the cluster-health now, we would see this:
지금 cluster-health를 확인해 보면, 아래처럼 나타날 것이다.
{ "cluster_name": "elasticsearch", "status": "yellow","timed_out": false, "number_of_nodes": 1, "number_of_data_nodes": 1, "active_primary_shards": 3, "active_shards": 3, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 3,
"delayed_unassigned_shards": 0, "number_of_pending_tasks": 0, "number_of_in_flight_fetch": 0, "task_max_waiting_in_queue_millis": 0, "active_shards_percent_as_number": 50 }
| cluster의 |
| replica shard가 node에 할당되지 않았다. |
A cluster health of yellow means that all primary shards are up and running (the cluster is capable of serving any request successfully) but not all replica shards are active. In fact, all three replica shards are currently unassigned—they haven’t been allocated to a node. It doesn’t make sense to store copies of the same data on the same node. If we were to lose that node, we would lose all copies of our data.
yellow 로 나타난 cluster health는 모든 primary shard가 올라와 실행 중인 것을 의미한다(cluster가 모든 request에 성공적으로 답할 수 있다). 그러나, replica shard는 모두 비정상이다. 사실, 3개의 모든 replica shard는 현재 할당되지 않았다(unassigned) (그들은 node에 할당되지 않았다). 동일한 node에, 동일한 데이터의 복사본을 저장하는 것은 말이 되지 않는다. 해당 node를 잃어버리면, 데이터의 모든 복사본을 잃어버리게 된다.
Currently, our cluster is fully functional but at risk of data loss in case of hardware failure.
현재 cluster는 모든 기능을 다하고 있지만, H/W 장애 시에 데이터 분실의 위험이 있다.
'2.X > 1. Getting Started' 카테고리의 다른 글
| 1-02-1. An Empty Cluster (0) | 2017.10.01 |
|---|---|
| 1-02-2. Cluster Health (0) | 2017.10.01 |
| 1-02-4. Add Failover (0) | 2017.10.01 |
| 1-02-5. Scale Horizontally (0) | 2017.10.01 |
| 1-02-6. Coping with Failure (0) | 2017.10.01 |