[ClickHouse] ClickHouse JOIN이 느린 이유와 최적화 전략

 

 

 

 

 ClickHouse를 처음 쓰다 보면 한 번쯤 이런 경험을 한다. MySQL에서는 아무 문제 없이 돌아가던 JOIN 쿼리가 ClickHouse에서는 유독 느리거나, WHERE 조건을 다 걸었는데도 풀스캔 수준의 시간이 걸리는 것이다. 이 글에서는 그 이유를 ClickHouse의 내부 동작 방식에서 찾고, 실제로 쓸 수 있는 최적화 전략을 정리한다.

 

 

 

 

---

어떤 상황인가

 수억 건의 유저 행동 로그(page_view_log)와 주문 데이터(order_log)를 JOIN해서 페이지를 본 특정 기간, 특정 유저의 구매 건수를 집계한다고 해보자. 아래처럼 쓰는 것이 자연스럽다.

SELECT count(*)
FROM default.page_view_log p
  JOIN default.order_log o
      ON p.user_id = o.user_id
    AND p.session_id = o.session_id
WHERE o.order_date BETWEEN '20260604' AND '20260610'
  AND o.user_id = 'user_001'

 

 그런데 이 쿼리는 유독 느리다. 

 실제로 왼쪽 테이블 약 3억 건, 오른쪽 테이블 약 7천만 건의 데이터를 위의 쿼리로 조회했을 때 약 1분 40초가 걸렸다.

 

 

 

 반면 아래처럼 서브쿼리로 먼저 필터링하면 체감이 다를 정도로 빠르게 실행된다.

SELECT count(*)
FROM
    (SELECT * FROM default.order_log
     WHERE order_date BETWEEN '20260604' AND '20260610'
       AND user_id = 'user_001'
    ) O
    INNER JOIN (
        SELECT * FROM default.page_view_log
        WHERE user_id = 'user_001'
          AND created_at > '20260504'
    ) P ON P.user_id = O.user_id AND P.session_id = O.session_id

 

실제로 위의 개선된 쿼리로 다시 조회했을 때 약 0.6초가 걸렸다.

 

 

 

 

 

두 쿼리의 논리적 결과는 같다. 그런데 왜 실행 시간이 다를까?

 

 

 

 

 

---

이유 1 - ClickHouse는 Predicate Pushdown을 자동으로 하지 않는다

 MySQL, PostgreSQL 같은 RDBMS는 Cost-Based Optimizer(CBO) 를 탑재하고 있다. 테이블 통계를 바탕으로 "어떤 순서로 실행하면 비용이 가장 낮을지"를 계산하고, WHERE 조건을 JOIN 이전 단계로 밀어 넣는 Predicate Pushdown을 자동으로 수행한다.

 

 

Cost-Based Optimizer

https://docs.oracle.com/en/database/oracle/oracle-database/21/tgsql/query-optimizer-concepts.html#GUID-298EDC61-405A-4E25-AEF6-C795E32AAC93

 

 

 CBO는 테이블 통계를 바탕으로 실행 비용을 계량화해서, 가장 낮은 비용의 실행 계획을 자동으로 선택하는 옵티마이저다. 테이블 행 수, 컬럼 카디널리티, 값의 분포(히스토그램), 인덱스 유무 같은 통계 정보를 활용해 "A 방법은 예상 비용 1200, B 방법은 예상 비용 340" 식으로 계산한 뒤 최적 순서를 결정한다.

 

 이게 필요한 이유는 쿼리를 실행하는 방법이 하나가 아니기 때문이다. 아래 쿼리 하나만 해도 실행 순서가 여러 가지다.

SELECT * FROM orders o JOIN users u ON o.user_id = u.id
WHERE o.created_at > '2026-01-01' AND u.country = 'KR'

• orders를 먼저 필터링한 뒤 users와 JOIN하거나
• users를 먼저 필터링한 뒤 orders와 JOIN하거나
• 두 테이블을 통째로 JOIN한 다음 WHERE를 적용하거나

 

 

 어떤 순서가 빠른지는 데이터 분포에 따라 다르다. country = 'KR'이 전체 유저의 90%라면 users 필터는 별 도움이 안 되고, created_at 조건이 orders를 1%로 줄인다면 거기서 먼저 필터링하는 게 훨씬 유리하다. CBO는 이 판단을 사람 대신 자동으로 해준다.

 

 

 

 

 

Predicate Pushdown 

 "Predicate(조건)를 Pushdown(밀어 넣는다)"이라는 이름 그대로, WHERE 조건을 가능한 한 데이터 소스에 가깝게 밀어 넣어 일찍 필터링하는 최적화다. 데이터는 늦게 걸러낼수록 손해다. 100만 건을 JOIN한 뒤 1만 건만 남기는 것보다, 먼저 1만 건으로 줄인 뒤 JOIN하는 게 당연히 빠르다.

 

-- 개발자가 작성한 쿼리
SELECT * FROM orders o JOIN users u ON o.user_id = u.id
WHERE o.created_at > '2026-01-01' AND u.country = 'KR'

-- 옵티마이저가 Predicate Pushdown 적용 후 실행하는 형태
SELECT * FROM
    (SELECT * FROM orders WHERE created_at > '2026-01-01') o
JOIN
    (SELECT * FROM users WHERE country = 'KR') u
ON o.user_id = u.id

 

 JOIN 전에 양쪽을 각자 줄여놓으니, 붙여야 할 데이터 자체가 작아진다. 개발자가 WHERE를 어디에 두든 옵티마이저가 알아서 이 순서로 재구성한다.

 

 

 단, Predicate Pushdown이 항상 가능한 건 아니다. HAVING처럼 집계 이후에 적용되는 조건이나, 비결정적 함수(NOW() 등)가 포함된 조건은 밀어 넣을 수 없다.

-- HAVING: 집계가 끝나야 cnt 값이 생기므로 GROUP BY 이전으로 밀어 넣을 수 없다
SELECT user_id, count(*) AS cnt
FROM orders
GROUP BY user_id
HAVING cnt > 10

-- 비결정적 함수: 실행 시점마다 값이 달라지므로 pushdown이 제한된다
WHERE created_at > NOW() - INTERVAL 7 DAY

 

 

 

 

 

ClickHouse에서는?

 ClickHouse도 일부 Cost-Based 최적화를 지원하지만, MySQL·PostgreSQL의 CBO처럼 JOIN 실행 순서나 Predicate Pushdown이 RDBMS 수준으로 보장되지는 않는다. 단일 테이블에 대한 단순한 조건은 pushdown되기도 하지만, JOIN이 포함된 복잡한 쿼리에서는 WHERE 조건이 JOIN 이후에 적용되는 경우가 많다. 옵티마이저가 알아서 해줄 거라고 믿고 쓰기 어렵다.

page_view_log (전체) × order_log (전체) → JOIN → WHERE 필터

 

 필터가 붙기 전에 이미 수억 건짜리 테이블 두 개가 전부 조인된다. 쿼리가 느린 건 당연한 결과다.

 

 pushdown이 되더라도 부분적으로만 적용되거나 아예 되지 않는 경우가 많아, 결과를 예측하기 어렵다. 결국 뒤에서 다룰 "서브쿼리로 먼저 줄이기" 패턴은 CBO + Predicate Pushdown을 개발자가 직접 명시적으로 구현하는 것과 같다.

 

 

 

 

 

---

이유 2 - Hash Join은 오른쪽 테이블을 메모리에 통째로 올린다

 ClickHouse의 기본 JOIN 알고리즘은 Hash Join이다.

1. 오른쪽 테이블 전체를 해시 테이블로 메모리에 적재
2. 왼쪽 테이블을 스트리밍하면서 해시 테이블과 매칭

 

https://clickhouse.com/blog/clickhouse-fully-supports-joins-hash-joins-part2

https://clickhouse.com/blog/clickhouse-fully-supports-joins-hash-joins-part2

 

 해시 테이블은 키로 즉시 조회가 가능한 자료구조다. 오른쪽을 메모리에 올려두고, 왼쪽 행이 들어올 때마다 해당 키로 바로 찾아 매칭하는 방식이다. 조회 자체는 빠르지만, 오른쪽 테이블 전체가 메모리에 들어가야 한다는 전제가 있다.

 

 오른쪽 테이블이 필터링되지 않은 대용량 로그라면 수억 건이 메모리에 올라가야 하고, 메모리가 부족하면 디스크로 넘쳐 더 느려진다. 서브쿼리로 미리 걸러서 오른쪽을 소량으로 줄이면, 메모리 적재 비용 자체가 작아져 전체 처리 시간이 크게 단축된다.

 

 

 

 

 

ClickHouse와 RDBMS, 설계 목적이 다르다

 위의 두 가지 이유(Predicate Pushdown 미보장, Hash Join의 메모리 적재 방식)는 모두 ClickHouse가 RDBMS와 근본적으로 다른 설계 철학을 갖고 있기 때문에 생긴다.

 

항목	RDBMS	ClickHouse
설계 목적	OLTP - 다양한 쿼리 패턴을 균형 있게 처리	OLAP - 단일 테이블 대규모 스캔 특화
옵티마이저	Cost-Based, 통계 기반 실행 계획 수립	상대적으로 단순한 Rule-Based
Predicate Pushdown	자동 수행	제한적, 명시적으로 작성해야 함
JOIN 알고리즘 선택	Nested Loop / Hash / Merge 중 자동 선택	기본 Hash Join 고정

 

 

 ClickHouse는 처음부터 "단일 테이블 집계를 극한으로 빠르게" 하는 데 집중해서 설계됐다. 복잡한 옵티마이저 대신 컬럼 스토리지와 벡터화 연산에 투자했고, 그 결과 단일 테이블 집계는 빠르지만 JOIN은 개발자가 직접 챙겨야 한다.

 

 

 

 

 

---

최적화 전략

 Dictionary, View처럼 DDL 권한이 필요한 방법도 있지만, 여기서는 쿼리 작성 수준에서 바로 적용할 수 있는 방법만 다룬다.

 

 

1. 서브쿼리로 데이터를 먼저 줄이기

 가장 기본이자 가장 효과적인 방법이다. JOIN 전에 각 테이블을 서브쿼리로 필터링해서 실제 JOIN 대상 데이터를 최소화한다. 앞에서 본 두 번째 쿼리가 이 원칙을 적용한 형태다.

SELECT count(*)
FROM
    (SELECT * FROM default.order_log
     WHERE order_date BETWEEN '20260604' AND '20260610'
       AND user_id = 'user_001'
    ) O
    INNER JOIN (
        SELECT * FROM default.page_view_log
        WHERE user_id = 'user_001'
          AND created_at > '20260504'
    ) P ON P.user_id = O.user_id AND P.session_id = O.session_id

 

 

 

2. 작은 테이블을 오른쪽에 배치

 Hash Join 특성상 오른쪽 테이블이 메모리에 올라가므로, 항상 더 작은 쪽을 오른쪽에 두어야 한다.

-- 나쁨: 필터링되지 않은 대용량 테이블이 오른쪽
FROM order_log O
JOIN page_view_log P ON ...

-- 좋음: 필터링된 작은 쪽이 오른쪽
FROM (SELECT * FROM page_view_log WHERE ...) P
JOIN (SELECT * FROM order_log WHERE ...) O ON ...

 

 

 

3. JOIN 알고리즘 명시적 지정

SETTINGS로 알고리즘을 직접 지정할 수 있다.

SELECT ...
FROM A JOIN B ON ...
SETTINGS join_algorithm = 'grace_hash'

 

알고리즘	특징
hash	기본값. 오른쪽 전체를 메모리에 적재
partial_merge	메모리를 아낄 때. 속도는 느림
grace_hash	대용량 JOIN. 디스크를 보조로 활용
auto	메모리 상황에 따라 자동 선택

 

 

 

 

 

---

마치며

 ClickHouse에서 JOIN 성능은 옵티마이저를 믿는 것이 아니라 개발자가 실행 순서를 직접 설계하는 데서 나온다. 서브쿼리로 데이터를 충분히 줄이고, 작은 쪽을 오른쪽에 두는 것만으로도 대부분의 성능 문제는 해결된다.