Lucene의 segment가 immutable한 이유

Elasticsearch의 Document의 수정, 삭제 동작이 발생되었을 때 실제 Document를 구성하고 있는 각 shard 내부 Segment는 바로 지워지지 않는다. 

 

대신 해당 세그먼트가 지워졌다고 mark만 하고 수정되었을 경우에는 새로운 세그먼트를 할당한다.

이렇게 동작하는 이유는 Lucene레벨에서 비용을 아끼기 위해서 사용된다고 알고는 있었는데 정확하게 왜 segment가 immutable한지 알지 못해서 정리해 봤다.

참조 : 구글 이미지 https://fdv.github.io/running-elasticsearch-fun-profit/003-about-lucene/003-about-lucene.html

---

 

1. 동시성 이슈

우선 개인적으로 생각했을 때는 immutable한 데이터의 경우 수정에 의한 고민을 할 필요가 없기 때문에 multi thread 환경에서 특별한 race condition을 고려할 필요가 없어서 이점이 있다고 생각했다. 

 

우연한 기회에 해당 부분에 대해 질문을 받았을 때 나도 multi thread 환경에서 동시성 문제에 이점이 있을 것 같다고 생각은 했지만 그게 정확한 이유인지 확실하지 않아서 모른다고 말씀드렸다. (잘못된 정보를 드릴까봐 걱정되어 모른다고 한게 아쉽다 -_ㅜ)

 

그래서 stackoverflow에 실제로 immutable한 segment에 이점에 대해  문의했고 그 응답으로 내 생각과 비슷한 답을 받을 수 있었다. 기본적으로 immutable한 속성에서 얻을 수 있는 이점과 비슷한 것 같다.

stackoverflow.com/questions/66025045/why-lucenes-segment-is-immutable

Why lucene's segment is immutable

 

 

 

2. cache

segment는 하나하나의 개별 파일들로 구성되어 있다. 그래서 이 file이 immutable한 속성을 가지게 되면 해당 데이터를 OS레벨에서 메모리에 올려서 캐시로 더 빠르게 접근할 수 있는 이점이 있게 된다. 

 

 

3. compresse algorithm

segment가 immutable한 이유 중 하나로 lucene에서 compresse 알고리즘으로 segment를 압축하고 있어서 압축된 Lucene의 segment 중 일부분을 지우기 위해서는 이를 다시 압축을 해제하고 지우고 다시 압축하는 과정이 번거롭고 cpu 바운드가 상승할 수 있기 때문에 immutable하고 나중에 schedule에 의한 merge에 지워진다는 이야기를 들은적이 있다.

 

실제로 elasticsearch 문서에 보면 lucene 4에서는 LZ4, Lucene 5에서는 DEFLATE를 사용해서 필드를 병합한다고 하는데 이 압축 방식이 segment를 immutable하게 만든 이유가 될 수도 있겠구나 생각이 들었다.

 

www.elastic.co/kr/blog/store-compression-in-lucene-and-elasticsearch

Store compression in Lucene and Elasticsearch