Force Merge — 더 이상 안 바뀔 인덱스만 손대는 수동 압축
Elasticsearch Force Merge API 및 Geo 쿼리 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(indices-forcemerge, geo-point, geo-queries, query-dsl-geo-distance-query, query-dsl-geo-bounding-box-query) Elastic 공식문서 Force merge API
이 모듈을 다 읽으면
- force merge가 왜 읽기 전용(더 이상 쓰기가 없는) 인덱스에만 권장되는지 설명할 수 있다
- max_num_segments=1로 강제 압축할 때 필요한 임시 디스크 공간과 그 이유를 설명할 수 있다
elasticsearch-learn-02에서 다룬 세그먼트와 Lucene의 자동 병합, elasticsearch-learn-07에서 다룬 ILM Hot-Warm-Cold 계층을 전제로, 자동 병합에 맡기지 않고 관리자가 명시적으로 세그먼트를 강제 압축하는 Force Merge API를 정리한다.
왜 '더 이상 안 바뀌는' 인덱스에만 쓰라고 하는가
공식 문서는 force merge를 읽기 전용 인덱스(더 이상 쓰기 트래픽을 받지 않는 인덱스)에만 쓰라고 명시적으로 권고한다 — 대표적으로 데이터 스트림의 롤오버된 이전 백업 인덱스나, elasticsearch-learn-07의 ILM 계층에서 Warm/Cold로 넘어간 시계열 인덱스가 이런 경우다. 활발히 쓰기가 들어오는 인덱스에 force merge를 걸면, 5GB보다 큰 매우 큰 세그먼트가 만들어질 수 있는데 이런 초대형 세그먼트는 이후 일반 자동 병합의 대상이 되지 못한다 — 그러면 그 뒤로도 계속 작은 세그먼트만 쌓이며 디스크 사용량 증가와 검색 성능 저하로 이어질 수 있고, 스냅샷 비용도 더 커진다.
핵심 포인트
- force merge는 더 이상 쓰기를 안 받는 인덱스(롤오버된 백업 인덱스, ILM Warm/Cold 인덱스 등)에만 권장
- 쓰기 중인 인덱스에 걸면 5GB보다 큰 초대형 세그먼트가 생겨 이후 일반 자동 병합 대상이 안 됨 — 디스크 증가·검색 저하·스냅샷 비용 증가로 이어질 수 있음
max_num_segments=1 — 최대 3배 임시 디스크 공간이 필요할 수 있다
force merge로 shard의 모든 세그먼트를 단 하나로(max_num_segments=1) 합치는 극단적 압축을 걸면, 그 병합 과정에서 shard 저장 공간이 일시적으로 늘어난다 — 모든 세그먼트를 새 세그먼트 하나로 다시 쓰는 동안 옛 세그먼트들도 아직 지워지지 않은 채 남아있어야 하기 때문에, 경우에 따라 원래 크기의 최대 3배까지 여유 공간이 필요할 수 있다. 이는 elasticsearch-learn-02에서 다룬 세그먼트 불변성(옛 세그먼트를 즉시 덮어쓰지 못하고 새로 쓴 뒤 나중에 정리) 원칙이 force merge에서도 그대로 적용되는 것이다.
핵심 포인트
- max_num_segments=1로 전체를 하나로 합치면 병합 중 옛 세그먼트+새 세그먼트가 동시에 존재해 최대 원래 크기의 3배까지 임시 디스크 공간 필요
- elasticsearch-learn-02의 세그먼트 불변성 원칙(즉시 덮어쓰기 불가) 때문 — force merge라고 이 원칙에서 예외가 아님