MergeTree 변형 — ReplacingMergeTree/AggregatingMergeTree와 FINAL의 함정
ClickHouse 공식 문서(clickhouse.com/docs) 및 기술 블로그 종합 — MergeTree부터 분산 아키텍처까지 (웹 리서치, 2026) — ClickHouse 공식 문서 + Altinity/Tinybird 등 기술 블로그 교차 확인
이 모듈을 다 읽으면
- ReplacingMergeTree의 중복 제거가 '즉시'가 아니라는 것과 그 이유를 설명할 수 있다
- FINAL을 쓸 때의 트레이드오프를 판단할 수 있다
- AggregatingMergeTree가 어떤 문제(uniq, quantile 같은 복잡한 집계)를 해결하는지 설명할 수 있다
MergeTree 계열의 중복제거/집계 특화 엔진과, '중복 제거가 왜 기대만큼 안 되는지'에 대한 실무 함정을 정리한다.
ReplacingMergeTree — 중복 제거는 '즉시'가 아니라 '병합 시점'
ReplacingMergeTree는 같은 ORDER BY 키 값을 가진 행이 여러 개 있으면(같은 데이터가 여러 번 INSERT됨) 병합 시점에 가장 최신 버전만 남기고 나머지를 제거한다. 여기서 흔한 오해가 있다 — 이 중복 제거는 INSERT 즉시 일어나는 게 아니라, 그 행들이 들어있는 파트들이 실제로 병합될 때만 일어난다. 병합은 백그라운드에서 예측 불가능한 시점에 일어나므로, 방금 중복 INSERT를 했다고 바로 SELECT 했을 때 중복 행이 그대로 보일 수 있다. 즉시 최신 값만 보고 싶다면 SELECT ... FROM table FINAL처럼 FINAL 키워드를 붙여 쿼리 시점에 강제로 병합 로직을 적용해야 한다.
핵심 포인트
- ReplacingMergeTree의 중복 제거는 INSERT 즉시가 아니라 파트가 실제로 병합될 때만 일어난다
- 즉시 최신 값만 보려면 FINAL을 붙여야 한다(그 전까지는 중복이 그대로 조회될 수 있다)
FINAL의 트레이드오프
FINAL은 아직 병합되지 않은 여러 파트를 쿼리 시점에 실시간으로 병합하며 읽어야 하므로, 특히 파트 수가 많거나 데이터가 대용량이면 쿼리가 눈에 띄게 느려질 수 있다. 그래서 실무에서는 FINAL을 매 쿼리마다 습관적으로 쓰기보다, (1) 정말 정확한 최신값이 필요한 경우에만 제한적으로 쓰거나, (2) argMax 같은 집계 함수로 직접 최신 행을 골라내거나, (3) 애초에 중복이 최소화되도록 애플리케이션 레벨에서 upsert 패턴을 관리하는 방식을 함께 고려한다.
핵심 포인트
- FINAL은 정확하지만 파트 수/데이터量이 크면 느려질 수 있다 — 매번 습관적으로 쓰지 말 것
- 대안: argMax 같은 집계 함수로 최신 행을 직접 선택하거나, 애플리케이션 레벨 upsert 관리
AggregatingMergeTree — 단순 합산을 넘어선 집계
SummingMergeTree는 같은 키의 숫자 컬럼을 병합 시점에 그냥 더하는 정도지만, uniq(고유값 개수)나 quantile(분위수) 같은 복잡한 집계는 '부분 결과를 어떻게 합칠지'가 단순 덧셈이 아니다. AggregatingMergeTree는 이런 집계 함수의 중간 상태(intermediate state)를 AggregateFunction이라는 특수 컬럼 타입으로 저장해두고, 병합 시점에 이 상태들을 올바르게 합친다. 보통 Materialized View(모듈 5)와 짝을 지어 쓴다 — 원본 테이블에 INSERT가 들어올 때마다 Materialized View가 그 데이터를 AggregatingMergeTree 대상 테이블에 집계 상태로 흘려보내, uniq/quantile 같은 값도 실시간에 가깝게 사전 집계해둘 수 있다.
핵심 포인트
- SummingMergeTree는 단순 합산, AggregatingMergeTree는 uniq/quantile 같은 복잡한 집계의 중간 상태(AggregateFunction 타입)를 관리한다
- Materialized View + AggregatingMergeTree 조합이 실시간에 가까운 사전 집계의 표준 패턴이다