1편 · 약 10분

ClickHouse 아키텍처와 핵심 개념

OLAP 워크로드와 ClickHouse의 탄생

ClickHouse는 Yandex가 자체 웹 분석 플랫폼(Yandex.Metrica)을 위해 개발하고 2016년 오픈소스로 공개한 열 지향(columnar) OLAP 데이터베이스다. "초당 수십억 row를 집계해야 하는데 기존 솔루션이 느렸다"는 실무 문제에서 출발했다. 현재는 ClickHouse Inc.가 오픈소스와 클라우드 서비스(ClickHouse Cloud)를 함께 운영한다.

OLTP 데이터베이스(MySQL, PostgreSQL)가 "특정 row 몇 개를 빠르게 읽거나 쓰는" 트랜잭션 워크로드에 최적화됐다면, ClickHouse는 "수십억 row 중 3~5개 컬럼만 집계"하는 분석 쿼리를 위한 것이다.

열 지향 스토리지가 분석 쿼리에 유리한 이유

행 지향 DB는 한 row의 컬럼을 연속된 공간에 저장한다. 모든 컬럼을 빠르게 읽을 수 있지만, 50개 컬럼 중 3개만 필요한 집계 쿼리라도 50개 컬럼 전체를 디스크에서 읽어야 한다.

열 지향 DB는 컬럼 단위로 연속 저장한다. 세 가지 이점이 생긴다.

I/O 절감: 쿼리가 사용하는 컬럼 파일만 읽는다. 50개 컬럼 중 3개를 쓴다면 I/O가 94% 감소한다.
압축 효율: 같은 컬럼의 값은 타입과 분포가 유사해 LZ4·ZSTD 압축률이 행 지향 대비 훨씬 높다.
SIMD 벡터화: 같은 타입의 값이 연속 배치되므로 CPU SIMD 명령어로 한 번에 여러 값을 처리할 수 있다.

행 지향 (MySQL · PostgreSQL) 행1: id | name | price | qty | ts | … 행2: id | name | price | qty | ts | … 행N: id | name | price | qty | ts | …

→

열 지향 (ClickHouse) price: [1.2, 3.5, 8.0, …] ← 읽음 qty: [10, 5, 3, …] ← 읽음 ts: [t1, t2, t3, …] ← 읽음 id, name, … → 건너뜀

행 지향 vs 열 지향: 3개 컬럼만 읽는 분석 쿼리에서의 I/O 차이

핵심 아키텍처 구성요소

ClickHouse 서버는 단일 프로세스로 동작한다. 주요 내부 구성 요소는 다음과 같다.

MergeTree 스토리지 엔진: 거의 모든 테이블이 MergeTree 계열 엔진을 사용한다. 삽입된 데이터는 파트(part) 단위로 디스크에 기록되며, 백그라운드에서 병합(merge)된다.
벡터 쿼리 엔진: 한 번에 8,192행(그래뉼 단위)씩 처리한다. 행 단위 반복 대신 컬럼 단위 벡터 연산으로 CPU 효율을 높인다.
압축 레이어: 컬럼 파일마다 LZ4(기본) 또는 ZSTD 코덱을 개별 적용한다. 코덱은 컬럼 타입별로 따로 지정할 수 있다.
Distributed 테이블: 여러 샤드에 쿼리를 팬아웃(fan-out)하는 라우터다. 자체 데이터는 없고, 각 샤드의 로컬 MergeTree 테이블에 요청을 위임한다.

MergeTree의 파트와 병합 사이클

MergeTree 엔진은 LSM 트리에서 영감을 받은 구조다.

INSERT → 각 배치 삽입이 즉시 디스크의 새 파트(디렉토리)를 생성한다. 파트는 컬럼 파일, 기본 키 인덱스(primary.idx), 체크섬(checksums.txt)으로 구성된다.
백그라운드 병합 → 소형 파트들이 점차 큰 파트로 합쳐진다. ORDER BY 정렬 순서가 유지되고, 엔진 종류에 따라 중복 제거·집계가 수행된다.
파트는 불변(immutable) → 병합이 완료될 때까지 기존 파트는 그대로 보존되고, 완료 후 삭제된다.

INSERT 배치 →

소형 Parts (즉시 생성) 20240101_1_1_0 20240101_2_2_0 20240101_3_3_0

→ 백그라운드 병합 20240101_1_3_1 → 구 파트 삭제

MergeTree 파트 라이프사이클: INSERT → 소형 파트 → 병합 → 통합 파트 → 구 파트 삭제

파트 이름(20240101_1_3_1)은 파티션_최솟블록_최댓블록_병합레벨 형식이다. 병합 레벨이 높을수록 더 많이 병합된 파트다.

ClickHouse vs OLTP 데이터베이스

ClickHouse는 OLTP DB를 대체하지 않는다. 수집·트랜잭션은 MySQL·PostgreSQL이 담당하고, CDC·ETL로 ClickHouse에 데이터를 흘려 분석 쿼리만 담당하게 하는 구조가 일반적이다.

특성	ClickHouse	MySQL · PostgreSQL
워크로드	OLAP (집계·스캔)	OLTP (점 조회·DML)
스토리지	열 지향	행 지향
트랜잭션	제한적 (파트 단위)	완전한 ACID
JOIN	소형 테이블 권장	자유로운 JOIN
삽입 단위	대량 배치 권장	건별 OK
UPDATE/DELETE	비동기 mutation (무거움)	즉시 반영

UPDATE와 DELETE는 ClickHouse에서 비동기 변형(mutation) 연산이라 빠르지 않다. 잦은 단건 수정이 필요한 테이블에는 적합하지 않다.

한 줄 정리

ClickHouse는 열 지향 스토리지와 벡터 쿼리 엔진으로 수십억 행을 밀리초 단위로 집계하는 OLAP 데이터베이스이며, OLTP DB를 대체하는 것이 아니라 분석 레이어로 함께 쓰인다.

References

https://clickhouse.com/resources/engineering/what-is-columnar-storage
https://clickhouse.com/docs/engines/table-engines/mergetree-family
https://www.chaosgenius.io/blog/clickhouse-architecture/
https://severalnines.com/blog/clickhouse-storage-architecture-and-optimization/
https://medium.com/@anshs5103/clickhouse-under-the-hood-mergetree-lsm-architecture-and-disk-level-optimizations-13ea85fc684d