1장. ClickHouse 개요 — 왜 빠른가

같은 데이터, 같은 쿼리인데 100배 빠른 이유가 있습니다. 열 저장·벡터화 실행·immutable 파트 — ClickHouse 속도의 3대 비밀을 그림으로 파헤칩니다.

1.1 OLAP의 극단에 서 있는 데이터베이스

ClickHouse는 OLAP(Online Analytical Processing, 온라인 분석 처리) 워크로드에 특화된 컬럼 지향(column-oriented) DBMS입니다. 모든 데이터베이스는 OLTP와 OLAP 사이의 스펙트럼 위 어딘가에 있는데, ClickHouse는 처음부터 "가능한 한 빠른 OLAP 시스템"을 목표로 OLAP 쪽 극단에 자리 잡았습니다.

공식 문서는 ClickHouse를 "true column-oriented DBMS"라고 부릅니다. 단순히 데이터를 컬럼 단위로 저장하는 것을 넘어, 쿼리 실행 자체가 컬럼(벡터) 단위로 이루어진다는 뜻입니다. 이 두 가지가 이 장의 핵심 주제입니다.

1.2 행 저장 vs 열 저장 — 집계 쿼리가 읽는 데이터량

100개 컬럼을 가진 테이블에서 딱 2개 컬럼만 쓰는 분석 쿼리를 떠올려 보세요. 행 저장에서는 한 행의 모든 컬럼이 디스크에 붙어 있으므로 필요 없는 98개 컬럼도 함께 읽어야 합니다. 열 저장에서는 컬럼마다 파일이 분리되어 있어 필요한 파일만 읽습니다.

1.3 보너스: 압축률의 극적인 차이

열 저장의 이점은 I/O 감소만이 아닙니다. 같은 타입·같은 분포의 값이 물리적으로 연속 배치되므로 압축 알고리즘이 반복 패턴을 훨씬 잘 찾아냅니다.

-- country 컬럼만 놓고 비교해 보면:
-- 행 저장: Korea, (다른 컬럼들...), USA, (다른 컬럼들...), Japan, ...
--   → 패턴이 끊겨서 LZ4 압축률 ~50%
-- 열 저장: Korea, Korea, Korea, USA, USA, Japan, Japan, ...
--   → 반복 패턴이 명확 → LowCardinality + LZ4로 ~95%까지 압축

CREATE TABLE user_events
(
    user_id  UInt64,
    country  LowCardinality(String),  -- 고유값이 적은 문자열에 특효
    amount   UInt32
)
ENGINE = MergeTree
ORDER BY (country, user_id);

1.4 벡터화 실행 — CPU를 쥐어짜는 방법

저장만 열 단위인 것이 아니라, 연산도 열(배열) 단위로 합니다. 행 하나씩 처리(row-at-a-time)하는 대신 수천 개 값의 배열(vector/chunk)에 연산을 한 번에 적용하는 것을 벡터화 쿼리 실행(vectorized query execution)이라고 합니다. 이 아이디어는 1957년 APL 언어까지 거슬러 올라가는, 과학 계산 분야에서 수십 년간 검증된 접근입니다.

쿼리 처리 속도를 높이는 또 다른 접근으로 런타임 코드 생성(runtime code generation)이 있습니다. 쿼리마다 기계어 코드를 즉석에서 만들어 여러 연산을 하나로 융합(fuse)하는 방식입니다. 공식 문서는 CMU 연구를 인용하며 두 접근의 결합이 최선이라고 밝히고, 실제로 ClickHouse는 벡터화를 주축으로 삼되 제한적인 코드 생성을 보조적으로 사용합니다.

1.5 스토리지의 설계 철학 — MergeTree는 LSM Tree가 아니다

ClickHouse의 대표 스토리지 엔진 MergeTree는 겉보기에 RocksDB류의 LSM Tree와 닮았지만, 결정적 차이가 있습니다. MEMTABLE(인메모리 쓰기 버퍼)도 WAL(Write-Ahead Log)도 없습니다. INSERT된 데이터는 프라이머리 키 순서로 정렬되어 즉시 디스크에 새 파트(part)로 기록됩니다.

이 구조에서 세 가지 중요한 성질이 나옵니다.

• INSERT와 SELECT의 완전 격리: INSERT는 새 파트를 만들 뿐 기존 데이터를 건드리지 않으므로, 동시 실행 중인 SELECT에 영향을 주지 않습니다. SELECT는 쿼리 시작 시점의 파트 스냅샷을 봅니다.
• 동시 INSERT 간 동기화 불필요: 각자 자기 파트만 만들면 되니까요.
• Merge-time Computation: 머지는 어차피 파트를 읽고 다시 쓰는 작업이므로, 그 김에 중복 제거·집계 같은 변환을 얹어도 추가 비용이 미미합니다.

1.6 Data Pruning — 읽지 않는 것이 가장 빠르다

공식 문서의 명언: "The fastest way to read data is to not read it at all." ClickHouse는 불필요한 데이터를 건너뛰기 위한 세 가지 장치를 제공합니다.

-- 잘 설계된 프라이머리 키는 스캔량을 극적으로 줄인다
EXPLAIN indexes = 1
SELECT count() FROM user_events WHERE country = 'Korea';

-- PrimaryKey  Parts: 1/4  Granules: 12/3257   ← 3257개 중 12개만 읽음!

1.7 확장 모델 — 수직과 수평

수직 확장: ClickHouse는 쿼리 플랜을 여러 lane으로 펼쳐 코어당 하나씩 병렬 실행합니다. 각 lane이 테이블의 서로 다른 범위를 처리하므로 코어 수에 비례해 빨라집니다(3장에서 스레드 모델을 다룹니다).

수평 확장: 단일 노드로 부족하면 테이블을 샤드(shard)로 분할해 여러 노드에 분산합니다(8장). 단, 공식 문서가 인정하는 제약이 있습니다 — 클러스터는 elastic하지 않습니다. 새 샤드를 추가해도 데이터가 자동으로 리밸런싱되지 않으므로, 초기 샤딩 전략이 중요합니다.

✍️ 이해도 체크