9장. INSERT 전략 선택

"한 번에 얼마나, 얼마나 자주 넣을 것인가" — 이 단순한 질문의 답이 "Too many parts" 장애와 안정적인 수집 파이프라인을 가릅니다. 배칭, async insert, 포맷·압축까지 INSERT의 모든 선택지를 정리합니다.

9.1 INSERT 한 번에 일어나는 일 — 고정 오버헤드의 존재

ClickHouse의 INSERT는 기본적으로 동기(synchronous)입니다. 쿼리 하나가 곧바로 디스크에 파트 하나를 만듭니다. 그런데 파트 하나를 만드는 데는 행이 10개든 10만 개든 거의 일정한 고정 비용이 듭니다.

-- 서버 측 INSERT 처리 파이프라인
클라이언트: ① 배칭 → ② 사전 정렬(선택) → ③ 포맷 → ④ 압축(선택) → ⑤ 전송
서버:      ⑥ 수신 → ⑦ 압축 해제 → ⑧ 파싱 → ⑨ in-memory Block 구성
           → ⑩ 프라이머리 키 정렬 → ⑪ sparse index 생성
           → ⑫ 컬럼별 압축 → ⑬ 디스크에 새 파트 기록

⑩~⑬은 행 수와 무관하게 항상 수행됩니다. 그래서 배치가 클수록 행당 비용이 급감합니다. 공식 권장 수치는 명확합니다.

9.2 파트 폭발 — 안티패턴과 배칭의 극적인 차이

초당 수백 번의 소량 INSERT가 왜 장애로 이어지는지, 그리고 같은 데이터를 배치로 넣으면 어떻게 달라지는지 비교해 봅시다.

9.3 재시도해도 안전하다 — INSERT 멱등성

네트워크는 언제든 끊길 수 있습니다. "INSERT가 성공했는지 모르겠는데 다시 보내면 중복되지 않을까?" — MergeTree는 이 문제를 INSERT 중복 제거(deduplication)로 해결합니다.

9.4 배칭이 불가능하다면 — Async Insert

수백~수천 개의 에이전트가 실시간으로 소량 데이터를 계속 쏘는 observability 환경에서는 클라이언트 측 배칭이 어렵습니다. 이럴 때 배칭을 서버에게 맡기는 것이 async_insert입니다.

-- 사용자 레벨로 활성화
ALTER USER default SETTINGS async_insert = 1;

-- 또는 쿼리 레벨
INSERT INTO mytable SETTINGS async_insert = 1 VALUES (...);

9.5 포맷·압축·인터페이스 — 전송 경로의 선택

압축은 LZ4(기본)가 대부분 최적입니다 — 빠르고 가벼우며 50% 이상 크기를 줄입니다. 리전 간 전송이나 클라우드 egress 비용처럼 네트워크 비용이 높을 때만 ZSTD(높은 압축률, CPU 부하 증가)를 고려하세요. Native 포맷 + LZ4 조합이 최고 수집 성능을 냅니다.

✍️ 이해도 체크