컬럼 지향 저장과 OLAP 최적화
ClickHouse 공식 문서(clickhouse.com/docs) 및 기술 블로그 종합 — MergeTree부터 분산 아키텍처까지 (웹 리서치, 2026) — ClickHouse 공식 문서 + Altinity/Tinybird 등 기술 블로그 교차 확인
이 모듈을 다 읽으면
- 컬럼 지향 저장이 행 지향 저장과 비교해 분석 워크로드에서 왜 유리한지 설명할 수 있다
- ClickHouse가 OLTP(트랜잭션 처리)에 부적합한 이유를 저장 구조 관점에서 판단할 수 있다
행 지향(row-oriented)과 컬럼 지향(column-oriented) 저장 방식의 근본적 차이와, ClickHouse가 OLAP에 최적화되고 OLTP에 부적합한 이유를 정리한다.
행 지향 vs 컬럼 지향 — 무엇을 읽어야 하는가
행 지향(row-oriented, 대부분의 RDB) 저장은 한 행의 모든 컬럼 값을 디스크에 연속으로 저장한다. 특정 행 하나를 통째로 읽거나 쓰는 트랜잭션(예: '이 주문 한 건을 조회/수정')에는 유리하다. 컬럼 지향(column-oriented) 저장은 반대로 같은 컬럼의 값들을 전부 연속으로 저장한다 — '전체 1억 행 중 amount 컬럼의 합계'를 구하는 분석 쿼리라면, amount 컬럼 하나만 순차적으로 읽으면 되고 다른 컬럼(고객명, 주소 등)은 디스크에서 아예 안 건드려도 된다. 게다가 같은 타입·비슷한 값이 연속으로 모여 있어 압축률도 훨씬 높다.
핵심 포인트
- 행 지향: 한 행을 통째로 읽는 트랜잭션에 유리(OLTP)
- 컬럼 지향: 필요한 컬럼만 읽고 나머지는 안 건드리는 분석 쿼리에 유리, 압축률도 높음(OLAP)
왜 OLTP에는 안 맞는가
컬럼 지향 저장은 '행 하나를 통째로 쓰거나 갱신하는' 작업에는 근본적으로 불리하다 — 한 행을 쓰려면 그 행이 걸쳐 있는 모든 컬럼 파일에 흩어져 써야 한다. 또한 ClickHouse의 데이터 파트는 불변(immutable)이라(모듈 2 참고) 행 단위 UPDATE/DELETE가 즉각 반영되는 게 아니라 비동기 mutation으로 처리되며 비용이 크다. 그래서 '초당 수천 건씩 개별 레코드를 갱신하는 주문 시스템' 같은 OLTP 워크로드에는 맞지 않고, '대량 데이터를 쌓아두고 집계·분석하는' OLAP 워크로드에 특화되어 있다.
핵심 포인트
- 컬럼 지향은 행 단위 쓰기/갱신에 근본적으로 불리 — 한 행이 여러 컬럼 파일에 흩어져 있기 때문
- 파트 불변성 때문에 UPDATE/DELETE는 즉각 반영이 아니라 비동기 mutation(비용 큼) — OLTP 부적합, OLAP 특화