ElasticSearch - 인덱스와 샤드

ElasticSearch	RDBMS
index	database
mapping	schema
document	row

 

인덱스

문서가 저장되는 공간, 문서를 저장하기위해서는 인덱스가 반드시 존재해야한다.
인덱스를 설계하는 것이 ElasticSearch를 사용하기 위해 고려해야하는 첫 단계이다.

 

 

인덱스 설계

사용패턴과 문서의 특성에 따라 설계해야한다. 

 

케이스	장점	단점
하나의 인덱스를 사용할 때	관리해야 할 인덱스의 수가 적어 관리 리소스가 적게 발생한다.	쿼리와 문서의 구조가 복잡해 질 수 있다.
여러개의 인덱스로 나눌 때	각각의 경우에 최적화된 쿼리와 문서 구조를 사용 할 수 있다.	관리해야 할 인덱스의 수가 많아 관리 리소스가 발생할 수 있다.

하나의 인덱스로 단수하게 시작 -> 사용패턴에 따라 인덱스를 별도로 운영

---

 

 

샤드

인덱스에 색인되는 문서가 저장되는 공간
하나의 인덱스를 반드시 하나 이상의 샤드를 가진다.

 

종류	역할
프라이머리 샤드	문서가 저장되는 원본 샤드, 색인과 검색 성능에 모두 영향을 줌
레플리카 샤드	프라이머리 샤드의 복제 샤드, 검색 성능에 영향을 줌 프라이머리 샤드에 문제가 생기면 레플리카 샤드가 프라이머리 샤드로 승격

 

PUT /library/_settings

{
    "index": {
    "number_of_shards" : 3,
    "number_of_replicas" : 1
    }
}

위의 경우는 프라이머리 샤드는 3개 레플리카 샤드도 3개 이다 

레플리카 샤드 (number_of_shards X number_of_replicas), 인덱스의 총 샤드 개수는 6개이다. 

 

PUT /library/_settings

{
    "index": {
    "number_of_shards" : 5,
    "number_of_replicas" : 2
    }
}

위의 경우는 프라이머리 샤드는 5개 

레플리카 샤드는 10개(number_of_shards X number_of_replicas) 

인덱스의 총 샤드 개수는 15개이다. 

 

---

 

샤드 라우팅

문서가 샤드에 저장되는 순서, 방법

A	B	C	D
0	1	2	0

이와같이 3개의 샤드가 있다고 가정해보자.

문서들은 0~2번까지의 샤드에 고르게 저장 됩니다.

A,B,C,D 라는 문서가 있다면 순서대로 0~2번 샤드에 고르게 저장이 된다. 

 

그래서 샤드의 개수가 바뀐다면 문서가 저장되는 규칙이 완전히 바뀌게 됩니다. 

Routing Rule = (문서의 ID) % (샤드의 개수)

 

샤드 개수가 변환이 없는 경우 

0	1	2	0
A	B	C	D

 

샤드 개수가 변환이 있는 경우 

0	1	2	3
A	B	C	D

중간에 이렇게 샤드의 개수가 바뀌게 된다면 D라는 문서의 경우에 기존의 경우에는 0번 샤드에, 샤드의 개수가 변경된 후에는 3번 샤드에 들어가게 되어 이후 추가적인 문서의 경우까지도 영향을 준다. 

 

 

따라서 인덱스를 생성할 때 프라이머리 샤드의 개수를 설정하는 것은 아주 중요하다.

이유는 중간에 변경이 불가능하기 때문이다.

number_of_shards의 기본값은 1이다. 이렇게 기본값으로 설정한다면 성능에 큰 영향을 미친다. 

이에 관한 내용은 추후에 다시 알아보도록 하겠다. 

 

인덱스 템플릿

PUT _index_template/base_template

{
    "index_patterns": ["nginx-logs-*"],
    "template": {
    	"settings": {
          "number_of_shards": 3,
          "number_of_replicas": 2
        }
     }
}

 nginx-logs-로 시작하는 모든 인덱스는 프라이머리 샤드 3개, 레플리카 샤드 6개로 생성을 하여라는 것이다.