elasticsearch(with lucene) force-merge에 대해서

merging하는 것은 그들 함께 merging함으로써 각 샤드의 세그먼스 수를 줄인다

또한 문서를 삭제함으로써 공간을 줄일 수도 있고 압축률 또한 좋아지고 중복된 데이터를 줄일 수도 있으며 세그먼트 수도 줄어들기 때문에 인덱스에 대한 검색, 집계와 정렬 할 때 좋다

보통 merging은 자동적으로 일어나게 되지만 때로는 merge 기능을 호출하여 유용하게 사용할 수도 있다

 

주의 할점은 force-merge(이하 fm)는 쓰기를 하지 않는 인덱스에만 적용해야 한다 지금은 수정 입력 삭제가 없더라도 미래에 생긴다면 주기적인 fm은 하지 않아야 한다 대신 백그라운드 merge 정책에 의존하면 된다 fm을 수행하고, 수행하면서 계속 쓰기 작업을 한다면 성능이 안좋아질 것이다

 

검색하다보니 두가이 이유가 있는데 거의 같은 말이긴 하지만 조금은 달라서 1,2으로 정리해보았다

 

1. 최대 5기가 세그먼트는 병합 정책에 의해서 병합이 진행되지만 그 이상의 용량을 가진 세금먼트는 병합이 진행되지 않는다 물론 문서를 삭제하거나 업데이트 하지 않는다면 문제가 전혀 될 것이 없지만 문서를 수정, 삭제 하는 경우에는 루씬은 기존 세그먼트에 있는 문성의 이전 버전을 삭제 표시하고 새 버전의 문서를 새로운 세그먼트에 저장한다 그런데 만약 삭제된 문서가 5gb 이상의 세그먼트에서 삭제, 수정되었을 경우에는 정리되지 않는다
2. 공식홈페이지에서는 읽기모드가 아닌 쓰기를 계속하는 인덱스에 fm을 수행하면 계속해서 수행하면 엄청 큰(5gb) 이상의 세그먼트가 만들어지게 되고 그 세그먼트는 백그라운드에서 merge 정책에서 머지 할 경우 대부분 삭제 된 문서로 구성될 때까지 병합을 하지 않게 된다 이것은 엄청 큰 세그먼트가 인덱스에 남아있는 원인이될 수 있고 디스크 사용량이 증가하고 검색 포퍼먼스가 매우 떨어지는 결과를 초래한다라고 말하고 있다

1번은 정리되지 않는다이고 2번 공홈에서는 대부분이 삭제로 마킹되면 삭제된다라고 얘기하고 있다

5gb의 대부분이 삭제되기는 어려우니 1번의 말도 틀린 말은 아닌 것 같다 보통 세그먼트를 작게 만들면 검색 속도가 빨라지는데

저렇게 커질 경우 느려지는 이유는 무엇일까? 쓰고 검색하고 하는 도중 merge를 하게 되는 경우도 그렇지만

삭제된 문서가 실제로 삭제가 되지 않으니까 그 문서도 순차적으로 읽어야 하니 더 느려질 수 밖에 없는 것 같다

 

fm을 요청하고 그 요청이 끊어져도 백그라운드에서 해당 작업이 수행중일 것이다 그때에 또 새로운 fm 요청을 해도 전에 요청했던 fm작업이 완료될 때 까지 새로운 fm요청은 block된다

 

타겟팅을 통해서 한번의 요청으로 여러 인덱스를 fm할 수 있다

1. 여러 백업 인덱스를 포함하는 하나 이상의 데이터 스트림
2. 여러 인덱스
3. 하나 이상의 인덱스 aliases
4. 클러스터 내에 모든 데이터 스트림과 인덱스들

fm은 일시적으로 디스크를 증가시킨다 그 이유는 머지시 하나의 기존 세그먼트들을 검색해서 새로운 세그먼트를 만들고 그 뒤에 기존 세그먼트를 삭제하기 때문에 일시적으로 증가 할 수 있다

 

참조

es의 공식문서를 번역 하였습니다

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html

Force merge API | Elasticsearch Reference [7.11] | Elastic

https://stackoverflow.com/questions/60226215/why-segment-merge-in-elasticsearch-requires-stopping-the-writes-to-index

Why segment merge in Elasticsearch requires stopping the writes to index