Distributed 테이블 엔진과 샤딩
ClickHouse 공식 문서(clickhouse.com/docs) 및 기술 블로그 종합 — MergeTree부터 분산 아키텍처까지 (웹 리서치, 2026) — ClickHouse 공식 문서 + Altinity/Tinybird 등 기술 블로그 교차 확인
이 모듈을 다 읽으면
- Distributed 테이블이 실제 데이터를 저장하지 않는다는 것과 그 역할을 설명할 수 있다
- 샤딩 키가 쓰기 경로에서 어떤 역할을 하는지 판단할 수 있다
여러 노드에 흩어진 샤드를 하나의 논리적 테이블처럼 보이게 해주는 Distributed 엔진의 동작 원리를 정리한다.
Distributed 테이블 — 데이터를 안 갖고 라우팅만 한다
클러스터를 여러 샤드로 나눠 운영할 때, 각 노드에는 실제 데이터를 담는 로컬 MergeTree 테이블이 있고, 그 위에 Distributed 엔진으로 만든 '가상 테이블'을 하나 더 둔다. Distributed 테이블 자체는 실제 데이터를 전혀 저장하지 않고, 클러스터의 모든 샤드 주소를 알고 있을 뿐이다. 이 테이블에 SELECT를 하면 쿼리를 모든 샤드로 팬아웃(fan-out)해서 각자 실행시킨 뒤 결과를 모아 병합해 하나의 결과로 돌려준다 — 애플리케이션 입장에서는 여러 노드에 흩어진 데이터가 마치 테이블 하나인 것처럼 보인다.
핵심 포인트
- Distributed 테이블은 데이터를 저장하지 않고 샤드 주소만 알고 있는 가상 테이블
- SELECT 시 모든 샤드로 쿼리를 팬아웃하고 결과를 모아 병합(reduce)해서 반환한다
샤딩 키 — INSERT 시 어느 샤드로 보낼지 결정
Distributed 테이블에 데이터를 쓰려면(샤드가 1개보다 많으면 필수) sharding_key를 설정해야 한다. 이 키의 표현식(예: intHash64(user_id))을 각 행에 대해 계산해서 그 결과로 어느 샤드로 그 행을 보낼지 결정한다 — intHash64(user_id)처럼 해시 함수를 쓰면 특정 user_id의 모든 데이터가 항상 같은 샤드로 가면서도 전체적으로는 여러 샤드에 고르게 분산된다. 샤딩 키를 잘못 고르면(예: 카디널리티가 낮거나 분포가 치우친 컬럼) 특정 샤드에 데이터가 쏠리는 핫스팟 문제가 생길 수 있다.
핵심 포인트
- sharding_key 표현식(예: intHash64(user_id))으로 각 행이 어느 샤드로 갈지 결정된다
- 해시 함수 기반 샤딩 키는 같은 값이 항상 같은 샤드로 가면서도 전체적으로 고르게 분산시킨다
- 샤딩 키를 잘못 고르면 특정 샤드에 데이터가 쏠리는 핫스팟이 생길 수 있다