MergeTree 엔진 — Parts와 백그라운드 병합
ClickHouse 공식 문서(clickhouse.com/docs) 및 기술 블로그 종합 — MergeTree부터 분산 아키텍처까지 (웹 리서치, 2026) — ClickHouse 공식 문서 + Altinity/Tinybird 등 기술 블로그 교차 확인
이 모듈을 다 읽으면
- INSERT 한 번이 실제로 무엇을 만드는지(Part)를 설명할 수 있다
- 백그라운드 병합(merge)이 왜 필요하고 무엇을 하는지 설명할 수 있다
ClickHouse 테이블 엔진의 기본이 되는 MergeTree가 데이터를 Part 단위로 쓰고 백그라운드에서 병합하는 원리를 정리한다.
INSERT 한 번 = Part 하나
MergeTree 테이블에 INSERT를 실행하면, 그 배치의 행들이 ORDER BY 기준으로 정렬되고 프라이머리 인덱스가 붙은 하나의 불변(immutable) 파트(part)로 디스크에 저장된다. 파트는 한 번 쓰이면 절대 그 자리에서 수정되지 않는다 — 이는 뒤에서 다룰 UPDATE/DELETE, ReplacingMergeTree의 중복 제거 지연 등 여러 동작의 근본 원인이다.
핵심 포인트
- INSERT 한 번 → ORDER BY로 정렬되고 프라이머리 인덱스가 붙은 불변 파트 하나가 생성된다
- 파트는 절대 그 자리에서 수정되지 않는다 — 여러 MergeTree 동작의 근본 전제
백그라운드 병합(Merge) — 왜 필요한가
INSERT가 반복되면 작은 파트가 계속 쌓이는데, 파트가 너무 많으면 쿼리 하나가 그 많은 파트를 전부 훑어야 해서 느려진다. 그래서 ClickHouse는 백그라운드에서 작은 파트들을 계속 더 큰 파트로 합치는 merge를 수행한다 — 이 병합 과정에서 엔진별 특수 로직(ReplacingMergeTree의 중복 제거, SummingMergeTree의 값 합산, AggregatingMergeTree의 집계 상태 병합 등, 모듈 4 참고)도 함께 적용된다. 병합은 어디까지나 백그라운드에서 '알 수 없는 시점'에 일어나므로, INSERT 속도가 병합 속도를 계속 앞지르면 파트가 계속 쌓여 '너무 많은 파트' 문제(모듈 7 참고)로 이어진다.
핵심 포인트
- 파트가 많아지면 쿼리가 느려지므로 백그라운드에서 계속 작은 파트를 큰 파트로 병합한다
- 병합 시점에 엔진별 특수 로직(중복제거/합산/집계상태병합 등)도 함께 적용된다
- 병합은 언제 일어날지 알 수 없다 — INSERT가 병합보다 빠르면 파트가 계속 쌓인다