백그라운드 머지 적체, SELECT는 왜 느려지나

백그라운드 머지 적체가 SELECT를 늦추는 진짜 원인은 무엇인가?

머지 적체는 파트(Part) 수 증가로 인한 읽기 증폭과, 머지 스레드가 CPU·I/O를 선점하는 리소스 경합이 결합된 결과다. late materialization이나 머티리얼라이즈드 뷰는 이 증상을 완화하지만 쓰기-머지-읽기가 자원을 나눠 쓰는 구조 자체를 없애지는 못한다. 진단은 "읽기가 느리다"가 아니라 "파트가 몇 개 쌓였고, 그중 어디서 시간이 새는지"를 분리해서 봐야 한다.

이 글은 LSM-tree 계열 컬럼 스토어(ClickHouse MergeTree 계열을 대표 사례로)에서 백그라운드 머지가 밀렸을 때 SELECT 지연이 발생하는 경로와 진단 지표, 적용 범위를 다룬다. 파일 포맷의 바이트 단위 구현은 다루지 않는다.

• 파트 수 증가 → 머지 읽기 증폭 → SELECT의 파트 스캔 비용 증가가 기본 경로다
• lazy materialization은 특정 쿼리(Top N, LIMIT)에서 최대 1,500배 개선 사례가 보고됐다ClickHouse 문서
• 보조 인덱스가 있는 환경에서는 Row Store가 Column Store보다 오히려 1.8배 빠른 실측 사례가 있다
• 머티리얼라이즈드 뷰는 읽기 지연을 줄이지만 쓰기 경로의 지연과 최신성을 대신 내준다
• 표준 진단은 elapsed time과 CPU time을 분리해 "대기"인지 "연산"인지 먼저 가른다

파트 적체는 컬럼 스토어 내부에서 무엇을 바꾸는가?

MergeTree류 엔진은 삽입마다 작은 파트를 만들고 백그라운드에서 이를 큰 파트로 합친다. 머지가 밀리면 파트 수가 그대로 쌓이고, SELECT는 더 많은 파트를 열어 인덱스를 조회하고 병합 정렬해야 한다. late materialization이 컬럼 단위로 값 해석을 미뤄도, 열어야 할 파트 자체가 늘면 파일 핸들과 인덱스 조회 횟수는 파트 수에 비례해 증가한다. 즉 late materialization은 파트 내부 비용을 줄이지 파트 개수 문제를 줄이지 않는다.

어느 단계에서 시간이 새는지 어떻게 구분하는가?

느린 쿼리를 진단할 때 표준 절차는 총 소요시간과 CPU 시간을 나눠 보는 것이다. 실행 중인 요청의 total_elapsed_time·cpu_time, 과거 실행의 last_elapsed_time·last_worker_time, 실제 실행계획의 ElapsedTime·CpuTime을 비교하면 시간이 대기에서 새는지 연산에서 새는지 구분된다SQL Server 문서. 컬럼 스토어에서는 여기에 "머지 대기 중인 파트 수"와 "머지 스레드 점유율"을 더해야 한다 — CPU 시간은 낮은데 elapsed time만 긴 구간이 길다면 대부분 머지와의 리소스 경합이다.

머지 압박은 왜 읽기 증폭으로 이어지는가?

late materialization과 압축은 읽기 경로 최적화 기법이지 쓰기 경로를 대체하지 않는다. Column-Store 비교 연구는 late materialization이 약 3배, 압축은 조건에 따라 자릿수 단위 개선을 낸다고 보고했지만, 두 기법 모두 이미 정리된 파트를 전제로 한다. 머지가 밀려 파트가 파편화된 상태에서는 압축률과 late materialization의 효과 모두 파트 경계마다 재계산돼 이득이 줄어든다.

lazy materialization은 실제로 얼마나 차이를 만드는가?

ClickHouse의 lazy materialization 도입은 Top N 쿼리에서 최대 1,500배 성능 개선을 보고했다 — 필요한 컬럼만 먼저 읽고 LIMIT 이후 나머지 컬럼을 읽어 디스크 I/O를 줄인 결과다. 다만 이 수치는 뉴스 요약 기사 기준으로, 버전·데이터셋·쿼리 패턴이 공식 벤치마크 문서로 명시되지 않아 정렬 후 제한(LIMIT) 쿼리 패턴에 국한된 값으로 보는 편이 안전하다. 같은 맥락에서 SAP S/4HANA 환경의 2025년 실측은 보조 인덱스가 없을 때 Row Store와 Column Store의 단건 조회 차이가 평균 2ms 내외로 미미했고, 인덱스가 있으면 Row Store가 약 1.8배 빠르다고 보고했다. 머지 적체 문제와 별개로, 컬럼 스토어가 항상 유리한 것은 아니라는 근거다.

머티리얼라이즈드 뷰로 우회하면 무엇을 내주는가?

머티리얼라이즈드 뷰는 자주 쓰는 집계 결과를 미리 계산해 저장해 읽기 지연을 줄인다. 대신 갱신 주기만큼 최신성을 내주고, 뷰 자체도 쓰기 경로를 통해 갱신되므로 머지 적체가 심한 시점에는 뷰 갱신도 함께 지연된다. 이 구조는 머지 압박을 없애는 게 아니라 읽기 경로와 쓰기 경로 중 어디서 지연을 흡수할지 위치를 옮기는 조치에 가깝다.

이 진단 절차는 언제 유효하고 언제 무의미한가?

파트 적체·머지 경합 진단은 삽입이 지속적으로 들어오는 컬럼 스토어 기반 엔진에서 유효하다. 반대로 보조 인덱스가 잘 걸린 Row Store 기반 단건 조회에서는 머지 적체 개념 자체가 성립하지 않거나 영향이 작다. 2026년 기준으로도 이 구분은 유효하며, 쿼리가 느리면 곧바로 머지 문제로 단정하기보다 인덱스 유무와 쿼리 패턴부터 확인하는 순서가 필요하다.

핵심 정리

• SELECT 지연은 읽기 자체보다 파트 적체로 인한 읽기 증폭과 머지-읽기 리소스 경합의 결합으로 설명된다
• lazy/late materialization은 파트 내부 비용을 줄이는 기법이며 파트 개수 문제 자체는 줄이지 않는다
• 진단은 elapsed time과 CPU time을 분리하고, 여기에 머지 대기 파트 수를 더해 봐야 한다
• 머티리얼라이즈드 뷰는 읽기 지연을 쓰기 경로 지연·최신성 저하로 맞바꾸는 조치다
• 보조 인덱스가 있는 Row Store 환경에서는 이 진단 절차 자체가 크게 의미 없을 수 있다

더 알아보기

실시간 분석 엔진: 아키텍처와 설계 판단 — 이 주제의 종합 가이드