이전 글에서는 엘라스틱서치 인덱스의 전체적인 구조에 대해 알아보았다. 이번에는 두 편에 걸쳐 /refresh, /flush API 의 동작 원리에 대해 알아보겠다. 엘라스틱서치에서 문서 색인 작업은 루씬이 담당하기 때문에 루씬과 엘라스틱서치 모두 어떻게 일하는지 살펴보고 동작 방법을 육안으로도 확인해볼 것이다.
<루씬 관점에서>
문서 색인 요청을 하면, 루씬은 곧바로 세그먼트를 생성하지 않는다. 왜냐면 세그먼트 생성이란 곧 디스크에 쓰는 것을 말하는데, 이 작업은 리소스가 많이 들기 때문이다.
In-memory buffer
그렇기 때문에 가장 먼저 하는 일은 In-memory buffer 에 쌓는 것이다. 메모리 기반이기 때문에 작업 속도는 빠르다. 하지만 아직 문서는 검색할 수 없다. 왜? 아직 세그먼트가 생성되지 않았으니까!
다음 단계는 세그먼트를 생성하는 것이다. 세그먼트를 생성하는 방법은 쓰기 위치에 따라 2가지 방법이 있다.
1) Flush
: 시스템 캐시에 데이터를 쓴다. 물리 디스크에 바로 쓰는 것보다 비교적 비용이 적게 들며 세그먼트가 생성되었으므로 검색이 가능한 상태가 된다. flush 까지만 해도 문서를 검색할 수 있지만 캐시이다 보니 데이터가 유실될 위험이 있다. 그러므로 주기적으로 commit 도 해줘야한다.
2) Commit
: 물리 디스크에 데이터를 쓴다. 세그먼트가 생성되었으므로 검색이 가능한 상태가 된다. 쓰기 리소스가 많이 들지만 물리 디스크에 기록되므로 비로소 안전한 상태가 된다.
루씬에서 세그먼트를 생성하는 2가지 작업을 엘라스틱서치에서는 다른 용어로 불린다.
ElasticSearch API | Lucene |
/refresh | flush 작업 수행 |
/flush | commit 작업 수행 |
그럼 다음 글에서 엘라스틱서치 관점에서 루씬과 연관해 /refresh, /flush API 가 어떻게 동작하는지 눈으로 직접 살펴보자
참고
루씬 인 액션 (책)
엘라스틱서치 실무 가이드 (책)
https://programming.vip/docs/in-depth-elasticsearch-index-creation.html
ElasticSearch refresh, flush API 동작 원리 (1): Lucene 관점
글 읽어주셔서 언제나 감사합니다. 좋은 피드백, 개선 피드백 너무나도 환영합니다.
'SearchDeveloper > ElasticSearch' 카테고리의 다른 글
[트러블슈팅] Too many dynamic script compilations within, max: [75/5m] (0) | 2022.11.16 |
---|---|
ElasticSearch Full GC 해결 과정 (2) | 2022.09.11 |
ElasticSearch refresh, flush API 동작 원리 (2): ElasticSearch 관점 + translog (0) | 2022.07.30 |
ElasticSearch Lucene 인덱스 구조 (0) | 2022.07.10 |
Spring-Data-Elasticsearch VS. Rest-high-level-client (0) | 2020.10.25 |