ClickHouse 파티션 키, 잘게 쪼갤수록 빠를까?

Q: 이벤트를 실시간으로 쪼개 저장하면 조회가 빨라질까?

빨라지지 않는다. 오히려 파트 수가 늘어나면서 Too many parts 오류와 병합 정체가 먼저 온다. ClickHouse 공식 문서는 대부분의 워크로드에 partition key 자체가 필요 없고, 필요하더라도 보통 월 단위면 충분하다고 명시한다 ClickHouse 공식 문서. 조회 성능을 좌우하는 것은 파티션이 아니라 ORDER BY다. 파티션 카디널리티는 대략 100~1,000개 이하, 넓게 잡아도 1,000~10,000개 이하가 권장 범위다. 월 단위보다 촘촘한 파티셔닝은 일반적으로 불필요하다는 것이 공식 입장이다. 조회에 걸리는 파티션 수가 max_threads / 2보다 작으면 스레드 활용도가 떨어진다. 고카디널리티 값(사용자 ID, 클라이언트명 등)은 PARTITION BY가 아니라 ORDER BY 앞부분에 둬야 한다. 실무에서 자주 보이는 대조는 이렇다. 한쪽은 이벤트 시각을 월 단위로만 자르는 보수적 파티션 키, 다른 쪽은 실시간 집계 편의를 노리고 날짜·사용자·국가를 조합한 세분화 파티션 키다. 후자는 대시보드 쿼리가 특정 파티션만 스캔하도록 만들려는 의도에서 나오지만, 공식 문서 기준으로는 이 설계가 병합 효율을 떨어뜨리고 파트 폭증을 부를 가능성이 높다고 지적된다 ClickHouse MergeTree 문서.

Q: 쿼리 병렬성은 파티션 개수와 어떤 관계일까?

파티션이 너무 적어도, 너무 많아도 병렬 효율이 떨어진다. 문서는 쿼리가 훑는 파티션 수가 max_threads / 2보다 충분히 커야 스레드 활용이 정상화된다고 설명한다. 반대로 파티션을 지나치게 잘게 쪼개면 배치 단위 처리가 행 단위 처리로 퇴화해 오히려 오버헤드가 커진다. 세분화 파티션은 이 두 극단 중 후자로 치우치기 쉽다.

Q: 실측 근거로 정리하면 어떻게 갈릴까?

| 항목 | 월 단위 파티션 | 일/사용자/국가 세분화 파티션 | |---|---|---| | 파티션 카디널리티 | 12~수십 개/년 | 수천~수백만 조합 가능 | | 병합 정체 위험 | 낮음 | Too many parts 발생 가능 | | 쿼리 병렬성 | max_threads/2 기준 충족 쉬움 | 파티션당 작업량 과소화 위험 | | 파티션 크기 균등성 | 상대적으로 균등 | 트래픽 편차 그대로 반영 | | 조회 최적화 주체 | ORDER BY가 담당 | 여전히 ORDER BY가 담당, 파티션은 보조 |

Q: 세분화 파티션에서 되돌리려면 무엇이 드나?

파티션 키는 ALTER TABLE로 즉시 바뀌지 않는다. 새 파티션 키를 가진 테이블을 만들고 INSERT SELECT로 전체 데이터를 재적재해야 하며, 이 과정에서 원본 테이블 크기만큼의 디스크와 시간이 추가로 든다. 비동기 인서트와 중복 제거 옵션이 함께 켜져 있던 환경이라면 파티션 키 크기가 0으로 잘못 계산되는 문제도 2026년 changelog에서 수정된 바 있어, 재적재 시점의 ClickHouse 버전 확인이 필요하다. 서비스 중단 없이 전환하려면 이중 쓰기 기간을 두고 검증 쿼리로 두 테이블의 집계 결과를 대조하는 절차가 사실상 필수다.

이벤트를 실시간으로 쪼개 저장하면 조회가 빨라질까?

빨라지지 않는다. 오히려 파트 수가 늘어나면서 Too many parts 오류와 병합 정체가 먼저 온다. ClickHouse 공식 문서는 대부분의 워크로드에 partition key 자체가 필요 없고, 필요하더라도 보통 월 단위면 충분하다고 명시한다 ClickHouse 공식 문서. 조회 성능을 좌우하는 것은 파티션이 아니라 ORDER BY다.

파티션 카디널리티는 대략 100~1,000개 이하, 넓게 잡아도 1,000~10,000개 이하가 권장 범위다.
월 단위보다 촘촘한 파티셔닝은 일반적으로 불필요하다는 것이 공식 입장이다.
조회에 걸리는 파티션 수가 max_threads / 2보다 작으면 스레드 활용도가 떨어진다.
고카디널리티 값(사용자 ID, 클라이언트명 등)은 PARTITION BY가 아니라 ORDER BY 앞부분에 둬야 한다.

실무에서 자주 보이는 대조는 이렇다. 한쪽은 이벤트 시각을 월 단위로만 자르는 보수적 파티션 키, 다른 쪽은 실시간 집계 편의를 노리고 날짜·사용자·국가를 조합한 세분화 파티션 키다. 후자는 대시보드 쿼리가 특정 파티션만 스캔하도록 만들려는 의도에서 나오지만, 공식 문서 기준으로는 이 설계가 병합 효율을 떨어뜨리고 파트 폭증을 부를 가능성이 높다고 지적된다 ClickHouse MergeTree 문서.

파트 개수는 왜 결과를 좌우할까?

파트 수가 늘어나면 병합(merge) 스레드가 더 많은 후보를 처리해야 하고, 병합 대상이 파티션 경계에 갇혀 서로 합쳐지지 못한다. 사용자별·국가별로 쪼갠 파티션은 각 파티션 안에서 파트가 작게 유지되고, 파티션 경계 때문에 병합 후보가 분리되어 정체가 누적된다. 결과적으로 인서트가 잦은 스트림일수록 Too many parts에 먼저 도달한다.

쿼리 병렬성은 파티션 개수와 어떤 관계일까?

파티션이 너무 적어도, 너무 많아도 병렬 효율이 떨어진다. 문서는 쿼리가 훑는 파티션 수가 max_threads / 2보다 충분히 커야 스레드 활용이 정상화된다고 설명한다. 반대로 파티션을 지나치게 잘게 쪼개면 배치 단위 처리가 행 단위 처리로 퇴화해 오히려 오버헤드가 커진다. 세분화 파티션은 이 두 극단 중 후자로 치우치기 쉽다.

파티션 크기 편차는 왜 문제가 될까?

편차가 크면 병렬 작업이 특정 스레드에 몰린다. 문서는 파티션 크기가 서로 비슷해야 스레드 간 작업량이 고르게 분배된다고 명시한다. 일별·국가별 조합 파티션은 트래픽이 적은 국가·요일에서 파티션이 극단적으로 작아지고, 트래픽이 몰리는 조합에서는 커져 편차가 벌어지기 쉽다. 월 단위 파티션은 이 편차가 상대적으로 완만하다.

실측 근거로 정리하면 어떻게 갈릴까?

항목	월 단위 파티션	일/사용자/국가 세분화 파티션
파티션 카디널리티	12~수십 개/년	수천~수백만 조합 가능
병합 정체 위험	낮음	`Too many parts` 발생 가능
쿼리 병렬성	`max_threads/2` 기준 충족 쉬움	파티션당 작업량 과소화 위험
파티션 크기 균등성	상대적으로 균등	트래픽 편차 그대로 반영
조회 최적화 주체	`ORDER BY`가 담당	여전히 `ORDER BY`가 담당, 파티션은 보조

세분화 파티션에서 되돌리려면 무엇이 드나?

파티션 키는 ALTER TABLE로 즉시 바뀌지 않는다. 새 파티션 키를 가진 테이블을 만들고 INSERT SELECT로 전체 데이터를 재적재해야 하며, 이 과정에서 원본 테이블 크기만큼의 디스크와 시간이 추가로 든다. 비동기 인서트와 중복 제거 옵션이 함께 켜져 있던 환경이라면 파티션 키 크기가 0으로 잘못 계산되는 문제도 2026년 changelog에서 수정된 바 있어, 재적재 시점의 ClickHouse 버전 확인이 필요하다. 서비스 중단 없이 전환하려면 이중 쓰기 기간을 두고 검증 쿼리로 두 테이블의 집계 결과를 대조하는 절차가 사실상 필수다.

그럼 세분화 파티션이 정당화되는 경우는 언제일까?

정당화되는 경우는 딱 하나, TTL 삭제나 파티션 단위 드롭이 운영 요구사항일 때다. 예를 들어 특정 날짜 단위로 데이터를 통째로 폐기해야 하는 보존 정책이 있다면 일 단위 파티션이 관리 편의를 준다. 반대로 조회 성능 개선이 목적이라면 파티션을 잘게 쪼갤 것이 아니라 ORDER BY 앞부분 컬럼 선택과 정렬 키 순서를 먼저 재검토해야 한다. 카디널리티가 100~1,000개를 넘어가는 순간부터는 관리 이득보다 병합 비용이 커진다고 보는 편이 안전하다.

핵심 정리

ClickHouse 조회 성능의 핵심은 파티션이 아니라 ORDER BY다.
파티션 카디널리티는 100~1,000개, 넓게 잡아도 1,000~10,000개 이하를 넘기지 않는다.
사용자·국가 같은 고카디널리티 값은 ORDER BY 앞부분에 두고 PARTITION BY에는 넣지 않는다.
세분화 파티션은 병합 정체·파트 폭증·스레드 불균형을 동시에 유발할 수 있다.
파티션 세분화는 TTL 기반 데이터 폐기 같은 관리 요구가 명확할 때만 예외적으로 선택한다.

더 알아보기

실시간 분석 엔진: 아키텍처와 설계 판단 — 이 주제의 종합 가이드