'Too Many Parts' 에러와 배치 인서트 원칙
ClickHouse 공식 문서(clickhouse.com/docs) 및 기술 블로그 종합 — MergeTree부터 분산 아키텍처까지 (웹 리서치, 2026) — ClickHouse 공식 문서 + Altinity/Tinybird 등 기술 블로그 교차 확인
이 모듈을 다 읽으면
- Too Many Parts 에러가 왜 발생하는지 근본 원인을 설명할 수 있다
- 이를 예방하는 인서트 방식(배치 크기, 빈도)을 판단할 수 있다
ClickHouse 운영에서 가장 흔히 마주치는 'Too many parts' 예외의 근본 원인(작고 잦은 INSERT)과 예방책을 정리한다.
Too Many Parts — 무엇이 한계를 넘었나
MergeTree 테이블에 활성 파트(active part) 수가 설정된 한계를 넘으면 ClickHouse는 추가 INSERT를 거부하며 'Too many parts' 예외를 던진다(에러 메시지에 보통 'Merges are processing significantly slower than inserts'라는 문구가 함께 나온다 — 병합이 INSERT 속도를 못 따라가고 있다는 신호). 주된 원인은 (1) 행 단위로 자주, 작게 동기(synchronous) INSERT를 보내는 애플리케이션 패턴, (2) 고카디널리티 파티션 키(모듈 3 참고 — 파티션이 잘게 나뉘면 병합이 파티션 경계를 못 넘어 파트가 안 합쳐짐), (3) 디스크 처리량 부족이나 여유 공간 부족으로 병합 자체가 느려지는 리소스 경합이다.
핵심 포인트
- 활성 파트 수가 한계를 넘으면 INSERT 자체가 거부된다 — '병합이 INSERT를 못 따라간다'는 신호
- 주 원인: 잦고 작은 동기 INSERT / 고카디널리티 파티션 키 / 디스크 리소스 경합
예방책 — 배치를 크게, 드물게
클라이언트 쪽에서 행을 모아 배치로 묶어 INSERT하는 것이 핵심 원칙이다 — 배치 하나에 최소 1,000행, 이상적으로는 10,000~100,000행을 담고, 동기 INSERT 빈도를 대략 초당 1회 수준으로 유지하는 것이 권장된다. INSERT를 적게, 크게 하면 그만큼 생성되는 파트 수가 줄어 백그라운드 병합 부담도 줄어든다. 애플리케이션이 실시간으로 자잘한 이벤트를 계속 보내야 하는 구조라면, 클라이언트나 중간 버퍼(예: Kafka, 또는 ClickHouse의 Buffer 테이블 엔진)에서 일정 시간/건수 단위로 모았다가 배치로 흘려보내는 아키텍처가 필요하다.
핵심 포인트
- 배치당 최소 1,000행, 이상적으로 10,000~100,000행 / 동기 INSERT는 대략 초당 1회 수준 권장
- 실시간 이벤트가 잦다면 중간에 버퍼링(Kafka, Buffer 테이블 등)해서 배치로 모아 흘려보내야 한다