1. 엘라스틱서치에서 인덱스는 한 개 혹은 여러 개의 샤드로 구성된다.
2. 샤드는 루씬 인덱스, 엘라스틱서치가 데이터를 클러스터 내에 분산 저장하기 위한 단위다.
3. 샤드는 결국 클러스터 내에 인덱싱을 하거나 데이터 일부를 조회하기 위한 독립적인 검색 엔진의 역할을 갖는다.
4. 샤드는 한개 혹은 여러 개의 세그먼트로 구성되고, 세그먼트 개수가 많아지면 주기적으로 더 큰 세그먼트로 병합된다. 병합 작업은 리소스에 민감하며 디스크 I/O에 큰 영향을 받는다.
5. 매우 큰 샤드를 만드는 것은 피하자. 실 사용 관점에서 50GB를 넘기지 말자.
6. 데이터 보관 주기를 관리하기 위하여 가능한한 시간 기반 인덱스를 사용하자. 보관 주기에 따라 데이터를 그룹핑하여 인덱스를 저장하자. 시간 기반 인덱스는 프라이머리 샤드와 리플리카의 개수 조정을 쉽게 해주며, 후속 인덱스 생성시 이를 쉽게 변경할 수도 있다. 또한 데이터의 볼륨과 요구사항을 쉽게 반영할 수도 있게 한다.
7. 작은 샤드는 작은 세그먼트를 만들며 부하를 증가시킨다. 평균 샤드 크기를 수 GB와 수십 GB 사이를 유지하는 것이 권장된다. 시간 기반 데이터를 사용한 사례를 보면 20GB ~ 40GB 정도의 사이즈가 적당했다.
8. 각 샤드의 부하는 세그먼트 개수와 크기에 따라 결정된다. 피크 시간을 피해 인덱스에 더 이상 데이터가 입력되지 않으면 forcemerge 기능을 사용해 큰 세그먼트로 병합시키는 것이 권장된다.
9. 하나의 노드에 설정된 힙은 1GB당 20~25개 샤드가 적당했다.
10. 쿼리에서, 샤드당 단일 쓰레드가 쿼리를 실행한다. 많은 개수의 작은 샤드를 조회하면 각 샤드마다 처리 속도는 빨라지지만 더 많은 작업을 큐에 넣고 순서대로 처리해야 하므로, 적은 개수의 큰 샤드를 검색하는 것보다 반드시 빠르다고 보장할 수 없다. 결론적으로 1개 샤드의 권장하는 크기를 넘지 않는 선이라면, 작은 크기의 여러 샤드보다는 큰 크기의 적은 샤드가 더 효율적이다.
10. 시간 기반 인덱스에서, 데이터 볼륨에 맞게 일 단위, 주 단위, 월 단위 인덱스를 고려하자. 이는 시간이 지남에 따라 클러스터에 저장하는 인덱스와 샤드의 개수를 적게 유지하는데 도움이 된다.
11. 데이터 인덱싱량이 빈번하게 변하는 경우라면 rollover, shrink api를 활용해서 유연하게 대응할 수 있도록 하자. rollover 인덱스 api는 클러스터가 저장해야 하는 도큐먼트와 인덱스의 개수를 지정하거나, 저장해야할 도큐먼트의 최대 기간을 지정할 수 있다.
12. shrink api는 기존 인덱스를 더 적은 개수의 프라이머리 샤드를 가진 신규 인덱스로 shrink하게 해준다.
댓글 없음:
댓글 쓰기