7장. Primary Index — 희소 인덱스의 원리와 키 설계

모든 행이 아니라 8,192행마다 하나만 기록하는 "듬성듬성한" 인덱스 — 그런데도 3천만 행에서 3개 granule만 읽어냅니다. B-Tree와 완전히 다른 이 인덱스를 이해해야 키 설계에서 실수하지 않습니다.

7.1 Sparse Index — B-Tree와 무엇이 다른가

PostgreSQL 같은 전통적 RDBMS의 B-Tree 인덱스는 모든 행을 인덱싱합니다. 행이 10억 개면 인덱스 엔트리도 10억 개죠. 반면 ClickHouse의 primary index는 희소(sparse)합니다 — 데이터를 granule(기본 8,192행)이라는 덩어리로 나누고, 각 granule의 첫 번째 행의 키 값만 기록합니다.

왜 이렇게 만들었을까요? 공식 문서의 답: "단일 서버에서 수조(trillions) 행을 유지하면서도 인덱스의 메모리 소비가 눈에 띄지 않아야 하기 때문". 1조 행 ÷ 8,192 ≈ 1.2억 엔트리, 키가 10바이트면 약 1.2GB — B-Tree라면 TB 단위가 필요한 데이터입니다. 대신 단일 행을 찾을 때도 최소 1 granule을 읽어야 하고, 유니크 제약을 걸 수 없다는 대가를 치릅니다.

7.2 인덱스는 어떻게 만들어지는가

예시 테이블로 INSERT 시 일어나는 일을 따라가 봅시다.

CREATE TABLE uk.uk_price_paid_simple
(
    date   Date,
    town   LowCardinality(String),
    street LowCardinality(String),
    price  UInt32
)
ENGINE = MergeTree
ORDER BY (town, street);   -- sorting key = 인덱스의 기반

7.3 쿼리 실행 — granule을 건너뛰며 스캔 범위를 좁힌다

이제 핵심입니다. 인덱스는 "어느 행에 데이터가 있다"고 알려주는 게 아니라, "이 granule에는 절대 없다"를 증명해서 건너뛰게 해줍니다. B-Tree가 목적지를 찍어주는 내비게이션이라면, sparse index는 "이 구역은 볼 필요 없음" 딱지를 붙이는 검문소에 가깝습니다.

이 과정은 EXPLAIN indexes = 1로 직접 관찰할 수 있습니다. Granules: X/Y에서 X가 충분히 작은지가 인덱스 효율의 핵심 지표입니다.

EXPLAIN indexes = 1
SELECT max(price)
FROM uk.uk_price_paid_simple
WHERE town = 'LONDON' AND street = 'OXFORD STREET';

         PrimaryKey
           Keys: town, street
           Condition: and((street in ['OXFORD STREET', ...]), (town in ['LONDON', ...]))
           Parts: 3/3
           Granules: 3/3609     ← 3,609개 중 3개만 읽는다!

7.4 ORDER BY 키 설계 — 순서만 바꿔도 850배

sparse index의 효율은 전적으로 ORDER BY 키 설계에 달려 있습니다. 공식 best-practices의 제1원칙은 이것입니다.

로그인 이벤트 테이블로 나쁜 설계와 좋은 설계를 비교해 봅시다. 저카디널리티 컬럼은 status(약 4개 값), 고카디널리티 컬럼은 user_id(수백만 값)이고, 주요 쿼리는 WHERE status = 'failed' AND event_time >= ...입니다.

키 설계 5원칙 정리

인덱스가 안 먹히는 필터 패턴

-- 나쁨: 키의 앞부분(status)을 건너뛰고 date만 필터 → skip 불가
WHERE date = '2024-04-05'

-- 나쁨: 복잡한 함수 래핑 → 최적화기가 인덱스를 우회할 수 있음
WHERE transform(status) = 'failed'

-- 나쁨: 부정 조건 → 대부분의 granule이 매칭되어 skip 효과 없음
WHERE status != 'ok'

-- 좋음: 키 순서대로 필터
WHERE status = 'failed' AND date >= '2024-04-01'

-- 좋음: IN 절 — 여러 범위를 각각 이진 탐색
WHERE status IN ('failed', 'timeout')

7.5 Ordering Key vs Primary Key, 그리고 튜닝 포인트

공식 문서에서 두 용어를 혼용하지만 엄밀하게는 다릅니다.

• Ordering Key (ORDER BY): 디스크 상 데이터의 물리적 정렬 순서를 정의
• Primary Key (PRIMARY KEY): sparse index에 저장되는 컬럼을 정의

보통은 동일하며, PRIMARY KEY를 지정하지 않으면 ORDER BY 키가 자동으로 primary key가 됩니다. 별도 지정은 "정렬은 3개 키로, 인덱스는 앞 2개만"처럼 인덱스 크기를 줄이고 싶을 때 사용합니다.

-- 데이터는 (a, b, c)로 정렬, sparse index는 (a, b)만 저장
CREATE TABLE t (...)
ENGINE = MergeTree
ORDER BY (a, b, c)
PRIMARY KEY (a, b);

-- 인덱스 내용을 직접 들여다보기
SELECT mark_number + 1 AS entry, town, street
FROM mergeTreeIndex('uk', 'uk_price_paid_simple')
ORDER BY mark_number ASC
LIMIT 10;

✍️ 이해도 체크