왜 성능이 빠른가

가장 빠른 읽기는
읽지 않는 것입니다

ClickHouse의 속도는 하나의 비결이 아니라, 저장 방식부터 CPU 명령어 수준까지 모든 계층에서 불필요한 일을 덜어낸 결과입니다. 데이터를 덜 읽고, 읽은 데이터는 최대한 효율적으로 처리합니다.

학계에서도 검증된 설계

ClickHouse의 아키텍처를 다룬 첫 논문이 2024년 데이터베이스 분야 최고 학회인 VLDB에 채택되었습니다. 채택률이 약 20%인 학회로, 창립자 Alexey Milovidov가 직접 발표했습니다.

쿼리 한 건이 지나는 길

다섯 개 계층에서 속도를 만듭니다

데이터가 저장될 때부터 결과가 나올 때까지, 각 단계에서 ClickHouse가 하는 일을 순서대로 정리했습니다.

  1. Layer 1

    저장 계층

    INSERT가 들어올 때마다 테이블에 새 조각(part)을 하나 만듭니다. 기존 데이터와 맞추는 작업이 없어 쓰기가 디스크 속도에 가깝게 이루어집니다.

    독립적인 동시 쓰기
    각 INSERT가 서로를 기다리지 않아 많은 쓰기가 동시에 들어와도 느려지지 않습니다.
    백그라운드 병합
    작은 조각들은 뒤에서 큰 조각으로 합쳐집니다. 정렬·정리 작업을 조회 시점이 아니라 병합 시점에 처리합니다.
    쓰기와 읽기 분리
    병합 중에도 조회가 잠기지 않아 데이터 적재와 분석을 동시에 돌릴 수 있습니다.
    실시간 적재
    데이터는 들어오는 즉시 조회 대상이 됩니다.
  2. Layer 2

    데이터 건너뛰기

    조건에 맞지 않는 데이터는 아예 디스크에서 읽지 않습니다. 성능을 좌우하는 가장 큰 요소입니다.

    기본 키 인덱스
    데이터를 기본 키 순서로 정렬해 두고 이진 탐색으로 필요한 범위만 찾습니다. 데이터가 늘어도 탐색 시간은 완만하게 늘어납니다.
    프로젝션
    같은 데이터를 다른 정렬 순서로 한 벌 더 유지해, 자주 쓰는 여러 필터 조건 모두에 빠르게 응답합니다.
    스키핑 인덱스
    데이터 블록마다 최솟값·최댓값, 고유값 목록 같은 통계를 붙여 조건과 무관한 블록을 통째로 건너뜁니다.
  3. Layer 3

    압축

    대부분의 분석 DB가 컬럼형 압축을 하지만, ClickHouse는 압축 방식을 테이블 전체가 아니라 컬럼마다 고르고, 데이터의 생김새에 맞춘 인코딩을 범용 압축 앞에 겹쳐 씁니다. 압축률뿐 아니라 압축을 푸는 속도까지 컬럼 단위로 조절할 수 있다는 점이 다릅니다.

    2단계 코덱 체인
    먼저 데이터 특성에 맞는 인코딩으로 값을 작은 숫자나 반복 패턴으로 바꾸고, 그 결과를 LZ4·ZSTD로 한 번 더 압축합니다. 예: CODEC(DoubleDelta, LZ4)
    데이터 타입별 전용 인코딩
    타임스탬프·증가하는 정수는 Delta·DoubleDelta, 센서값 같은 실수는 Gorilla·FPC, 범위가 좁은 숫자는 T64로 필요한 비트만 남깁니다.
    LowCardinality 타입
    국가, 상태 코드처럼 종류가 적은 문자열은 사전 인코딩 타입으로 저장해 문자열 대신 작은 정수만 기록합니다.
    정렬 키가 압축을 돕는다
    ORDER BY에 값 종류가 적은 컬럼을 앞에 두면 같은 값이 연속으로 붙어 반복 구간 압축이 크게 효과를 냅니다. 추가 저장 비용 없이 압축률이 올라갑니다.
    속도와 압축률을 컬럼별로 선택
    자주 조회하는 컬럼은 압축 해제가 빠른 LZ4(약 2배, 초당 3~5GB 해제), 오래 보관할 컬럼은 압축률이 높은 ZSTD(약 2.5~3배)로 나눠 지정합니다.
    • 10.8배ClickBench 1억 행 데이터ClickHouse 9.26GiB, PostgreSQL 약 100GiB로 같은 데이터를 저장
    • 15~20배Character.AI 운영 환경컬럼 평균 압축률, 일부 컬럼은 50배까지
    • 5~6배Seemplicity같은 데이터를 PostgreSQL 대비 5~6분의 1 용량으로 저장
  4. Layer 4

    쿼리 처리

    읽어 온 데이터는 CPU와 코어를 최대한 활용해 처리합니다.

    벡터화 실행
    값을 한 개씩이 아니라 묶음 단위로 처리해 CPU 캐시를 효율적으로 쓰고, SIMD 명령어로 여러 값을 한 번에 계산합니다.
    하드웨어별 최적화
    세대별 SIMD 명령어에 맞춘 연산자를 여러 벌 준비해, 실행하는 서버에서 가장 빠른 것을 자동으로 고릅니다.
    코어 단위 병렬 처리
    쿼리를 코어 수만큼의 작업 경로로 나눠 각자 다른 데이터 범위를 처리합니다. 코어를 늘리면 그만큼 빨라집니다.
    서버 단위 확장
    데이터가 한 대를 넘어서면 여러 서버로 나눠 저장하고 쿼리를 자동으로 분산 실행합니다.
  5. Layer 5

    저수준 최적화

    범용 구현 하나로 모든 경우를 처리하지 않고, 데이터와 쿼리 특성에 맞는 구현을 골라 씁니다.

    30종 이상의 해시 테이블
    GROUP BY와 JOIN에 쓰는 해시 테이블을 미리 30가지 넘게 준비해 키 타입과 데이터 분포에 맞춰 선택합니다.
    상황별 알고리즘
    정렬 하나도 데이터 타입, 메모리 여유, 부분 정렬 여부에 따라 다른 알고리즘을 씁니다.
    적응형 조인
    해시 조인을 기본으로 하되, 큰 테이블끼리 조인할 때는 병합 조인으로 전환합니다.
    근사 계산
    정확도를 조금 양보해도 되는 집계는 근사 함수와 샘플링으로 훨씬 빠르게 답합니다.

컬럼 기반 저장

필요한 컬럼만 읽기 때문에 빠릅니다

행 기반 DB는 한 행의 값을 붙여 저장하므로, 컬럼 세 개만 필요해도 행 전체를 디스크에서 읽어야 합니다. ClickHouse는 컬럼별로 따로 저장해 쿼리에 쓰이는 컬럼만 읽습니다.

SELECT event_date, user_id, revenue FROM events WHERE event_date = today()

행 기반 저장필요 없는 컬럼까지 행 전체를 읽음
컬럼 기반 저장 (ClickHouse)쿼리에 쓰인 3개 컬럼만 읽음

공개 벤치마크

누구나 재현할 수 있는 벤치마크로 검증합니다

ClickHouse는 성능 수치를 자체 테스트로만 주장하지 않습니다. 쿼리, 데이터, 실행 스크립트를 모두 공개한 벤치마크에서 다른 데이터베이스와 같은 조건으로 비교하고, 결과를 웹에서 누구나 확인할 수 있게 합니다.

2.24배 2018년 대비 현재 버전의 쿼리 속도. 아래 네 가지 벤치마크를 합산한 결과로, 같은 하드웨어에서도 엔진 개선만으로 계속 빨라지고 있음을 보여줍니다.
벤치마크쿼리 수데이터 규모측정 내용
ClickBench42개1억 행웹 분석 로그 기반 대표 분석 쿼리
MgBench15개2억 행머신 생성 로그 분석
Star Schema13개6억 행DW 표준 스타 스키마 조인·집계
NYC Taxi Rides4개34억 행뉴욕 택시 운행 기록 집계
ClickBench 결과 보기 벤치마크 전체 보기

더 알아보기

ClickHouse 도입을 검토하고 계신가요?

현재 사용 중인 시스템과 데이터 규모를 알려주시면, 적합한 구성과 PoC 계획을 제안해 드립니다.

도입 상담 신청
이메일
support@planit.ai
전화
02-569-8601~2
주소
서울 강남구 테헤란로 63길 20, JJ빌딩 2층