join_algorithm — 메모리와 속도 사이에서 조인 방식을 고르기
ClickHouse join_algorithm 및 storage_policy(hot/cold 계층) 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(guides/joining-tables, guides/developer/ttl) ClickHouse 공식 문서 Joining tables
이 모듈을 다 읽으면
- hash join과 full_sorting_merge가 서로 다른 조건에서 유리한 이유를 설명할 수 있다
- direct 알고리즘이 Dictionary와의 조인에서 왜 가장 빠른지 설명할 수 있다
clickhouse-learn-15에서 다룬 Dictionary(인메모리 조회 테이블)를 전제로, ClickHouse가 두 테이블을 조인할 때 오른쪽 테이블 크기·정렬 상태·메모리 여유에 따라 여러 물리적 알고리즘 중 무엇을 고를지 결정하는 join_algorithm 설정을 정리한다.
hash/parallel_hash — 오른쪽 테이블이 메모리에 들어갈 때 가장 빠르다
hash join은 오른쪽(조인 대상) 테이블 전체로 인메모리 해시 테이블을 만들어두고, 왼쪽 테이블을 스트리밍하며 이 해시 테이블에 조회하는 방식이다 — 오른쪽 테이블이 메모리에 다 들어갈 만큼 작을 때 가장 빠르다. parallel_hash는 이를 멀티스레드로 병렬화한 변형으로, 조금 더 큰(그래도 메모리에는 들어가는) 데이터셋에서 성능을 개선해주지만 메모리 오버헤드는 기본 hash join보다 크다.
핵심 포인트
- hash join: 오른쪽 테이블로 인메모리 해시 테이블 생성 — 오른쪽 테이블이 메모리에 다 들어갈 때 가장 빠름
- parallel_hash: hash join의 멀티스레드 변형, 조금 더 큰 데이터셋에 유리하지만 메모리 오버헤드는 더 큼
full_sorting_merge/grace_hash — 메모리가 부족할 때의 대안
full_sorting_merge는 양쪽 테이블을 조인 키로 정렬한 뒤 병합하는 방식으로, 만약 테이블의 물리적 행 순서가 이미 조인 키와 일치한다면 정렬 단계 자체를 건너뛸 수 있어 메모리 사용량과 속도 모두에서 유리해진다. grace_hash는 해시 테이블을 만드는 접근은 유지하되 디스크로 스필(spill)할 수 있어, grace_hash_join_initial_buckets 설정으로 메모리-속도 트레이드오프를 조절 가능한 유연한 대안이다 — 반면 partial merge join은 메모리 제약이 극심할 때를 위한 선택지로, 디스크 스필을 감수하는 대신 조인 속도를 상당히 희생한다.
핵심 포인트
- full_sorting_merge: 양쪽을 정렬 후 병합 — 물리적 행 순서가 이미 조인 키와 일치하면 정렬 단계 생략돼 메모리·속도 모두 유리
- grace_hash: 해시 테이블 접근을 유지하며 디스크 스필 가능, grace_hash_join_initial_buckets로 메모리-속도 트레이드오프 조절 가능한 유연한 대안
direct — Dictionary와의 조인에서 가장 빠른 지름길
clickhouse-learn-15에서 다룬 Dictionary처럼 이미 메모리에 저장구조를 갖춘 대상(Dictionary나 key-value 엔진)과 조인할 때, 조인 키가 Dictionary의 키 속성과 일치하고 LEFT ANY JOIN 시맨틱이면 충분한 경우, direct 알고리즘은 별도의 해시 테이블을 새로 만드는 과정 없이 Dictionary가 이미 갖고 있는 저지연 인메모리 구조를 그대로 재사용한다 — 이 조건이 맞을 때는 다른 어떤 알고리즘보다도 빠르다.
핵심 포인트
- direct는 Dictionary/key-value 엔진과의 조인에서, 조인 키가 Dictionary 키와 일치하고 LEFT ANY JOIN이면 그 인메모리 구조를 그대로 재사용
- 이 조건에서는 새 해시 테이블을 만들 필요가 없어 다른 어떤 알고리즘보다도 빠름