6장. Part Merges — 백그라운드 머지의 동작 원리

INSERT는 가볍게, 무거운 일은 나중에 몰아서 — ClickHouse가 "Merge-time Computation"이라 부르는 이 전략의 심장부, 백그라운드 머지를 단계별로 들여다봅니다.

6.1 왜 머지가 필요한가

4장에서 배웠듯이 ClickHouse는 INSERT 한 번마다 불변(immutable) 파트를 하나씩 만듭니다. 파트는 한번 쓰이면 절대 수정되지 않죠. 그런데 이대로 방치하면 어떻게 될까요? 파트가 수천, 수만 개로 늘어나고, SELECT 쿼리는 그 파트를 전부 열어서 읽어야 합니다. 파일을 여는 비용, 인덱스를 각각 확인하는 비용이 눈덩이처럼 불어납니다.

그래서 ClickHouse는 백그라운드에서 작은 파트들을 끊임없이 큰 파트로 합칩니다. 공식 문서는 이 설계를 두 문장으로 요약합니다.

즉 머지는 단순한 청소부가 아닙니다. 파트 수 제어 + 엔진별 데이터 처리(중복 제거, 집계 등)라는 두 가지 임무를 수행하는, ClickHouse 성능 철학의 핵심 장치입니다. 머지는 파티션 단위로 일어나며, 압축 크기가 약 150GB(max_bytes_to_merge_at_max_space_in_pool)에 도달한 파트는 더 이상 머지 대상이 되지 않습니다.

6.2 머지 트리 — 작은 파트가 큰 파트로 수렴하는 과정

파트가 머지를 거칠 때마다 이름 끝의 merge level이 1씩 증가합니다. INSERT 직후의 파트는 level 0, 한 번 머지되면 level 1, 다시 머지되면 level 2… 이렇게 시간이 지나며 계층 구조(트리)가 만들어집니다. 이것이 MergeTree라는 이름의 유래입니다.

실제 system.parts에서 이 수렴 과정을 관찰할 수 있습니다.

-- 초기: 24개 파트가 4개로 머지된 상태 (level 1)
   ┌─name────────┬─level─┬────rows─┐
1. │ all_0_5_1   │     1 │ 6368414 │
2. │ all_12_17_1 │     1 │ 6442494 │
3. │ all_18_23_1 │     1 │ 5977762 │
4. │ all_6_11_1  │     1 │ 6459763 │
   └─────────────┴───────┴─────────┘

-- 시간 경과 후: 하나로 최종 수렴 (level 2)
   ┌─name───────┬─level─┬─────rows─┐
1. │ all_0_23_2 │     2 │ 25248433 │
   └────────────┴───────┴──────────┘

6.3 머지 한 번의 내부 — 4단계 파이프라인

머지 스레드 하나가 파트 몇 개를 골라 합칠 때, 내부적으로는 항상 같은 4단계를 거칩니다. 압축된 컬럼 파일을 풀고 → 정렬 순서를 유지하며 합치고 → 새 인덱스를 만들고 → 다시 압축해 저장하는 흐름입니다.

단일 서버는 background_pool_size(기본값은 대략 CPU 코어 수의 절반 수준)만큼의 머지 스레드를 동시에 돌립니다. 파트가 너무 커서 한꺼번에 메모리에 올리기 부담스러우면, 블록 청크 단위로 나눠 처리하는 vertical merging 모드가 자동으로 선택됩니다(메모리 절약 ↔ 속도 저하 트레이드오프).

6.4 엔진별 머지 — "Merge-time Computation"의 실체

머지의 ② 병합 단계는 테이블 엔진에 따라 근본적으로 다른 일을 합니다. "모든 데이터 처리를 백그라운드 머지로 이관한다"는 원칙이 바로 여기서 실현됩니다.

가장 많이 쓰이는 ReplacingMergeTree로 "머지 시점의 중복 제거"가 어떻게 동작하는지 봅시다. 핵심은 머지 전에는 중복이 그대로 보인다는 점입니다.

6.5 FINAL과 OPTIMIZE — 머지를 기다릴 수 없을 때의 선택지

머지 전의 중복이 문제라면 두 가지 "강제" 수단이 있지만, 둘 다 비용이 큽니다.

SELECT ... FINAL — 쿼리 시점에 머지 로직 적용

FINAL은 올바른 결과를 주지만 느립니다. 이유는 세 가지입니다: ① 파트별 병렬 읽기가 깨지고 같은 키끼리 비교하는 단일 스레드 구간이 생김, ② primary index로 좁힌 granule보다 더 넓게 읽어야 함, ③ 메모리에서 머지 로직을 실행하는 추가 CPU·메모리 비용. 파트 수가 많을수록 저하가 심해집니다. 프로덕션에서는 아래 argMax 패턴이 더 일반적입니다.

-- 머지 전: 중복 2행이 보인다
SELECT * FROM user_grade WHERE user_id = 123;

-- FINAL: 올바르지만 느림 (병렬성 깨짐 + 추가 스캔)
SELECT * FROM user_grade FINAL WHERE user_id = 123;

-- 권장 패턴: argMax — ver이 최대인 행의 grade 반환. 병렬 실행 유지
SELECT user_id, argMax(grade, ver) AS latest_grade
FROM user_grade
WHERE user_id = 123
GROUP BY user_id;

OPTIMIZE TABLE — 수동 머지 트리거

-- 하나의 머지 사이클 실행
OPTIMIZE TABLE mydb.mytable;

-- 모든 파트를 하나로 최종 머지 (매우 무거움!)
OPTIMIZE TABLE mydb.mytable FINAL;

-- 특정 파티션만 최종 머지
OPTIMIZE TABLE mydb.mytable PARTITION '2024-01-01' FINAL;

6.6 머지 모니터링과 운영 체크리스트

머지 상태는 system.merges(진행 중), system.part_log(이력), system.parts(파트 건강)로 관찰합니다.

-- 진행 중인 머지 확인
SELECT database, `table`, partition_id,
    round(progress * 100, 1) AS progress_pct,
    num_parts,
    formatReadableSize(total_size_bytes_compressed) AS total_size,
    formatReadableTimeDelta(elapsed) AS elapsed,
    merge_type, merge_algorithm
FROM system.merges
ORDER BY elapsed DESC;

-- 파트 수가 위험 수위인 테이블 식별 (level 0가 많으면 머지 지연)
SELECT database, `table`,
    count() AS active_parts,
    min(level) AS min_level
FROM system.parts
WHERE active
GROUP BY database, `table`
HAVING active_parts > 100
ORDER BY active_parts DESC;

머지가 밀릴 때는 다음 순서로 원인을 확인하세요.

1. INSERT 속도가 머지 속도를 초과 → 배치 크기 증가(9장) 또는 background_pool_size 증가
2. 디스크 I/O 병목 → 디스크 처리량 확인 (특히 HDD 환경)
3. 파티셔닝 과다 → 파티션당 파트 수 확인 (5장)
4. Mutation 진행 중 → system.mutations에서 is_done = 0 확인. Mutation이 머지 스레드를 점유합니다

✍️ 이해도 체크