10억 건 집계가 엔터 치자마자 끝난다: ClickHouse는 왜 이렇게 빠를까
한눈에 보는 요약
차트메트릭(Chartmetric) 창업자 조성문 님이 ClickHouse를 도입하며 겪은 경험과 그 속도의 원리를 정리한 글입니다. 핵심만 먼저 짚어보면 이렇습니다.
- 관계형 DB는 인덱스에 의존하는데, 분석 쿼리는 질문의 종류가 무한해서 미리 다 준비할 수 없습니다.
- 데이터 웨어하우스는 분산 오버헤드 때문에 작고 즉각적인 조회에는 오히려 굼뜹니다.
- ClickHouse는 마법이 아니라 "읽는 바이트 수와 불필요한 CPU 작업을 줄인" 결과입니다.
왜 기존 DB로는 부족했을까
관계형 DB(MySQL / PostgreSQL)의 한계
관계형 DB의 성능은 인덱스에서 나옵니다. 문제는 분석 업무의 성격이죠. "이 조건으로 묶어서 저 순서로 정렬해줘"라는 요청은 매번 형태가 달라지는데, 모든 질문에 맞는 인덱스를 미리 만들어 둘 수는 없습니다. 그 결과 수십억 행 규모에서 GROUP BY나 ORDER BY가 들어간 분석 쿼리는 답이 나오기까지 수 분씩 걸리기도 합니다.
데이터 웨어하우스(BigQuery / Redshift / Snowflake)의 한계
그렇다고 웨어하우스가 항상 정답인 것도 아닙니다. 이들은 서버 기동 → 작업 분할 → 결과 병합이라는 분산 처리 과정을 거칩니다. 대규모 배치 작업에서는 강력하지만, 대시보드에서 클릭 한 번에 튀어나와야 하는 작고 즉각적인 조회에는 이 준비 비용 자체가 부담이 됩니다.
발견의 순간: "엔터를 치는 순간 답이 나왔다"
계기는 의외로 소박했습니다. 저자는 ChartMogul을 고객으로 사용하다가 그 성능에 놀랐고, 창업자에게 직접 물어보면서 ClickHouse의 존재를 알게 됩니다.
확인 방식도 단순했습니다. 엔지니어가 자기 맥북에 ClickHouse를 설치하고 약 10억 건의 데이터를 넣은 뒤, 사내에서 악명 높던 집계 쿼리를 돌려본 것이죠. 결과는 "엔터를 치는 순간 답이 나왔다"였습니다. 클러스터도 아닌 노트북 한 대에서 말입니다.
빠른 이유 네 가지
1. 칼럼 단위 저장
행 전체를 통째로 읽는 대신 필요한 칼럼만 읽습니다. 게다가 같은 타입의 값이 나란히 모여 있으니 압축 효율도 훨씬 좋습니다. 읽어야 할 바이트 수 자체가 줄어드는 셈입니다.
2. 벡터화 처리
행을 하나씩 처리하면 행마다 함수 호출 오버헤드가 붙습니다. ClickHouse는 블록 단위로 묶어 계산해서 이 반복 비용을 걷어냅니다.
3. 병렬 처리
여러 CPU 코어가 데이터 조각을 나눠 맡아 부분 집계를 만들고, 마지막에 합산합니다. 코어를 놀리지 않는 구조입니다.
4. 희소 기본 인덱스(Sparse Primary Index)
B-tree처럼 모든 행을 색인하지 않습니다. 대신 약 8,192행마다 표식을 남겨두고, 조건에 해당하지 않는 데이터 묶음은 통째로 건너뜁니다. 인덱스를 정교하게 만드는 대신 "안 봐도 되는 걸 크게 버리는" 전략이죠.
만능은 아닙니다
원문이 특히 분명하게 선을 긋는 부분입니다. 도구마다 자리가 있습니다.
| 상황 | 더 나은 선택 | | --- | --- | | 개별 사용자 레코드 즉시 조회, 트랜잭션 안전성 | PostgreSQL | | 거대 조직 전체 데이터의 복잡한 분산 운영 | 데이터 웨어하우스 | | 방대한 이벤트·시계열·로그의 빠른 필터링과 집계 | ClickHouse |
저자의 회사는 현재 전체 데이터의 거의 절반을 ClickHouse로 처리하고 있으며, 나머지 영역도 계속 이전하는 중이라고 합니다. 전면 교체가 아니라 적합한 워크로드부터 옮겨가는 접근입니다.
마치며
결론은 담백합니다. ClickHouse는 물리 법칙을 어긴 마법이 아니라, 읽는 데이터의 양과 불필요한 CPU 작업을 집요하게 줄인 설계의 결과입니다.
데이터 분석이나 실시간 대시보드 때문에 쿼리 응답 시간을 고민하고 있다면, 한 번쯤 검토해 볼 만한 선택지입니다. 무엇보다 노트북 한 대에 설치해서 실제 데이터를 넣어보는 것만으로도 판단이 서는 도구라는 점이 매력적입니다.