[Elasticsearch] force merge 에 대한 정리
Elastic/Elasticsearch 2021. 8. 4. 08:12공식 문서 참고)
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html
API)
POST /my-index-000001/_forcemerge
force merge 는 너무 많이 생성된 Segments 파일을 병합 하거나 삭제 된 문서를 물리적으로 병합 하면서 제거 하거나 하는 작업을 수행 하게 됩니다.
보통은 merge policy 에 의해서 자동으로 수행이 되긴 하지만 간혹 수동으로 실행을 해야 할 때도 발생을 합니다.
그럼 Segments 파일을 어느 정도 수준으로 유지 하는게 좋을까요?
그 전에 확인할 사항이 있습니다.
1. Segment 파일에 문서 수가 많나요?
2. Segment 파일에 문서의 크기가 큰 것일까요?
결국 이 Segments 파일은 IndexWriter 즉, 색인 보다는 검색에 영향을 많이 주는 요소라고 보면 됩니다.
짧은 용량의 Segments 파일이 많이 있다고 가정 하면 파일 수 만큼의 IndexeReader 가 준비 되어야 하고 그에 맞는 thread 가 일을 해야 하기 때문에 다소 성능이 떨어 질 수도 있습니다.
반대로, 용량이 큰 Segments 파일이 있다고 하면 Single thread 로 동작 하기 때문에 역시 성능이 떨어 질 수 있기도 합니다.
그래서 가장 최적의 Segment file 의 크기와 수를 구해야 검색 성능을 확보 할 수 있습니다.
보통은 Primary shard 와 Replica shard 를 가지고 접근을 하게 됩니다. 그러다 Node 수준까지 접근 하게 되고 더 나아가 Application 수준까지 ...
Segment 파일이 가질 수 있는
- 최대 문서의 수는 Integer.MAX_VALUE (2,147,483,519) 만큼 가질 수 있습니다.
- 문서 하나의 최대 크기는 2GB 입니다.
제가 제안 하는 범용적인 Segment 파일은
- 최대 문서 수는 1천만 ~ 5천만
- Segment file 크기는 2GB ~ 5GB
- Segment file 수는 Core 크기와 같거나 1/2 만큼
정도 인것 같습니다.
Segment 는 Lucene 기준으로 검토를 하셔야 하고 Elasticsearch 기준으로 확장 한다고 하면 Shard 까지 검토를 하셔야 합니다.
제가 제안한 정보를 기준으로 단순 예를 들어 보면)
- 코어가 10개 라고 하고
- 1/2 만큼의 Segments file : 5개
- Shard 1개의 크기는 5 개 Segments file x 2GB : 10GB
대략 Node와 Shard size estimation 하는 방법에서 제시 한 것과 어느 정도 부합 한다는 것을 볼 수 있습니다.