ClickHouse vs. StarRocks 비교

실시간 분석 데이터베이스 시장에서 ClickHouse와 StarRocks는 가장 주목받는 두 오픈소스 솔루션입니다. 두 기술 모두 컬럼 기반 OLAP 데이터베이스로서 빠른 분석 쿼리를 목표로 하며, 각각 독자적인 강점과 설계 철학을 보유하고 있습니다.

흥미롭게도, 두 프로젝트는 서로를 경쟁자이자 좋은 자극제로 인식하며 건강한 경쟁 관계를 유지하고 있습니다. StarRocks 커뮤니티는 ClickBench 벤치마크에서 ClickHouse와의 경쟁을 "메시와 호날두의 라이벌 관계"에 비유하기도 했습니다.

이 글에서는 객관적인 벤치마크 데이터와 아키텍처 특성을 바탕으로 두 솔루션을 비교하고, 어떤 워크로드에 어떤 솔루션이 더 적합한지 실용적인 관점에서 살펴보겠습니다.

• 1. 벤치마크로 보는 성능 비교
• ClickBench: 단일 테이블 분석 쿼리
• SSB (Star Schema Benchmark): 다차원 분석
• TPC-H: 복잡한 다중 테이블 조인
• 동시성 처리
• 데이터 압축 및 적재
• 성능 요약
• 2. 아키텍처 비교: OSS와 Cloud의 차이
• ClickHouse 아키텍처
• ClickHouse OSS (Self-Managed)
• ClickHouse Cloud (Managed Service)
• StarRocks 아키텍처
• Shared-Nothing 모드 (BE 노드 사용)
• Shared-Data 모드 (CN 노드 사용)
• 아키텍처 비교 요약
• 3. 핵심 기능 비교
• 조인 처리
• UPDATE/DELETE 처리
• 인덱스 및 데이터 타입
• 데이터 포맷 및 통합
• 4. Data Lakehouse 지원 현황
• ClickHouse의 Lakehouse 전략
• StarRocks의 Lakehouse 전략
• 5. 유즈케이스별 권장 솔루션
• ClickHouse가 더 적합한 경우
• 1. 실시간 분석 및 Observability
• 2. 단일 테이블 중심의 고속 분석
• 3. 내부 분석 도구 (제한된 동시 사용자)
• StarRocks가 더 적합한 경우
• 1. Data Lakehouse / Hadoop 교체
• 2. Enterprise Data Warehouse (EDW)
• 3. 고동시성 BI 대시보드
• 4. 실시간 데이터 업데이트가 빈번한 워크로드
• 6. 오픈소스 커뮤니티 현황
• 기업 정보
• 커뮤니티 활동
• 라이선스 및 오픈소스 정책
• 7. 결론: 워크로드에 맞는 선택
• 선택 가이드 요약
• 하이브리드 접근
• 최종 권장

1. 벤치마크로 보는 성능 비교

두 데이터베이스의 성능을 객관적으로 비교하기 위해 업계에서 널리 사용되는 벤치마크 결과를 살펴보겠습니다. 중요한 점은 "어떤 것이 더 빠른가"는 "무엇을 측정하는가"에 전적으로 달려 있다는 것입니다.

ClickBench: 단일 테이블 분석 쿼리

ClickBench는 비정규화된 웹 분석 데이터셋에서 단일 테이블 분석 쿼리 성능을 측정합니다. 이 벤치마크에서 ClickHouse와 StarRocks는 매우 근접한 성능을 보여주며, 버전 업데이트마다 선두를 주고받는 양상을 보입니다.

ClickHouse의 MergeTree 스토리지 엔진은 조인 없이 넓은 플랫 테이블을 스캔하는 데 최적화되어 있어, 이러한 유형의 쿼리에서 일반적으로 약간의 우위를 보입니다.

SSB (Star Schema Benchmark): 다차원 분석

Star Schema Benchmark는 팩트 테이블과 디멘션 테이블 간의 조인을 포함한 차원 모델링 시나리오를 테스트합니다. Tinybird의 독립적인 벤치마크에 따르면, StarRocks는 SSB에서 ClickHouse 대비 약 1.87배 빠른 성능을 기록했습니다. 이는 StarRocks의 Cost-Based Optimizer(CBO)가 여러 테이블 간 조인 실행을 더 효율적으로 계획하기 때문입니다.

TPC-H: 복잡한 다중 테이블 조인

TPC-H는 다양한 카디널리티를 가진 복잡한 다중 테이블 조인을 포함합니다. 이 벤치마크에서 StarRocks는 ClickHouse 대비 3~5배 빠른 성능을 보여줍니다. ClickHouse의 Rule-Based 쿼리 플래너는 조인 순서 결정과 노드 간 데이터 이동에서 StarRocks의 CBO 대비 상대적으로 제약이 있습니다.

동시성 처리

고동시성 환경에서도 두 솔루션의 차이가 드러납니다. StarRocks는 쿼리 큐잉과 리소스 풀을 통해 높은 동시성을 더 효과적으로 처리하며, 수천 명의 동시 사용자(일부 시나리오에서 10,000명까지)를 지원할 수 있습니다. ClickHouse OSS는 500개 이상의 동시 쿼리에서 P95 레이턴시가 상승하는 경향이 있어, 사용자 수가 제한된 내부 분석 시나리오에 더 적합합니다.

데이터 압축 및 적재

데이터 압축률에서는 ClickHouse가 우위를 보입니다. 고급 스토리지 레이어 압축 기술을 통해 약 10% 이상 우수한 압축률을 달성하며, 데이터 규모가 커질수록 이 격차는 벌어집니다. 다양한 코덱(LZ4, ZSTD, Delta, DoubleDelta, Gorilla 등)을 조합하여 데이터 특성에 맞는 압축 전략을 수립할 수 있습니다.

데이터 적재 성능에서도 ClickHouse가 강점을 보입니다. 대용량 로그 적재 벤치마크에서 일관되게 빠른 성능을 보여주며, 특히 Materialized View 파이프라인이 포함된 시나리오에서 차이가 두드러집니다.

성능 요약

2. 아키텍처 비교: OSS와 Cloud의 차이

ClickHouse 아키텍처

ClickHouse는 배포 형태에 따라 아키텍처가 크게 다릅니다.

ClickHouse OSS (Self-Managed)

오픈소스 ClickHouse는 Shared-Nothing 아키텍처를 채택합니다:

• ClickHouse Server: 쿼리 처리와 데이터 저장을 모두 담당하는 모놀리식 서버
• ClickHouse Keeper (또는 ZooKeeper): 데이터 복제와 분산 DDL 조정을 위한 코디네이션 레이어
• ReplicatedMergeTree: 복제본 간 데이터 동기화를 위한 테이블 엔진

이 구조에서는 각 서버가 자신의 로컬 디스크에 데이터를 저장하고, 복제본 간에 데이터를 직접 통신하여 동기화합니다. S3 등 오브젝트 스토리지를 사용할 수 있지만, 메타데이터는 여전히 각 서버에 로컬로 저장됩니다.

장점: 단순한 구조, 배포 용이성, 독립적인 서버 운영 제약: 스케일 아웃 시 수동 샤딩 필요, 복제본 추가 시 데이터 재동기화 오버헤드

ClickHouse Cloud (Managed Service)

ClickHouse Cloud는 SharedMergeTree 엔진 기반의 Shared-Everything 아키텍처를 채택합니다:

• Stateless Compute Nodes: 쿼리 처리만 담당하는 무상태 서버
• Shared Object Storage (S3/GCS/Azure Blob): 모든 데이터와 메타데이터의 단일 저장소
• ClickHouse Keeper: 메타데이터 조정 및 동기화

SharedMergeTree에서는 복제본 간 직접 통신이 필요 없고, 모든 통신이 공유 스토리지와 Keeper를 통해 이루어집니다. 이를 통해:

• 수백 개의 복제본으로 동적 스케일링 가능
• 샤딩 없이 수평 확장
• Serverless 모델 지원 (자동 스케일 업/다운, 제로 스케일)
• Lightweight UPDATE 지원

주의: SharedMergeTree와 Lightweight UPDATE 등 일부 기능은 ClickHouse Cloud 전용이며 오픈소스에서는 사용할 수 없습니다.

StarRocks 아키텍처

StarRocks는 MPP(Massively Parallel Processing) 아키텍처를 기반으로 합니다:

Shared-Nothing 모드 (BE 노드 사용)

• Frontend (FE) Node: 메타데이터 관리, 쿼리 파싱, 실행 계획 수립
• Leader: 메타데이터 쓰기 및 클러스터 관리
• Follower: 메타데이터 복제 및 읽기 서비스
• Observer: 읽기 전용 확장 노드
• Backend (BE) Node: 쿼리 실행 및 데이터 저장

Shared-Data 모드 (CN 노드 사용)

StarRocks 3.0부터 스토리지-컴퓨팅 분리 아키텍처를 지원합니다:

• Compute Node (CN): BE와 동일한 기능을 수행하지만 데이터를 저장하지 않음
• Shared Storage: 오브젝트 스토리지에 데이터 저장

이 구조에서 Frontend가 쿼리 분석과 최적화를 전담하므로, 복잡한 조인 쿼리에서 더 정교한 실행 계획을 수립할 수 있습니다.

아키텍처 비교 요약

3. 핵심 기능 비교

조인 처리

ClickHouse는 "플랫 테이블 + 선계산(Pre-aggregation)" 모델을 선호합니다. 데이터를 적재 시점에 비정규화하고, Materialized View를 통해 집계를 미리 수행함으로써 쿼리 시점의 조인을 최소화합니다. 이 접근법은 단일 쿼리 성능을 극대화하지만, 데이터 파이프라인의 복잡도가 증가합니다.

StarRocks는 스타/스노우플레이크 스키마를 네이티브로 지원합니다. Broadcast Join, Shuffle Join, Colocate Join 등 다양한 조인 전략을 Cost-Based Optimizer가 자동으로 선택합니다. 이를 통해 정규화된 데이터 모델을 유지하면서도 우수한 쿼리 성능을 제공합니다.

UPDATE/DELETE 처리

ClickHouse OSS는 MUTATION 연산을 통해 비동기적으로 ALTER TABLE을 수행합니다. 실시간 업데이트보다는 배치 수정에 적합합니다. ClickHouse Cloud의 SharedMergeTree는 Lightweight UPDATE를 지원하여 더 효율적인 업데이트가 가능합니다.

StarRocks는 Primary Key 테이블에서 효율적인 upsert/delete 연산을 네이티브로 지원합니다. 동시 업데이트 중에도 효율적인 쿼리 성능을 유지할 수 있어, CDC 파이프라인과의 통합에 유리합니다.

인덱스 및 데이터 타입

ClickHouse는 Bloom Filter, N-Gram, Token, Min-Max, Set, Text, HNSW(벡터) 등 다양한 인덱스 타입을 지원합니다. 데이터 타입도 256비트 정수, 무제한 문자열 등 폭넓게 지원합니다.

StarRocks의 인덱스 지원은 상대적으로 제한적이지만, Bitmap Index와 Zone Map을 통해 필터링 성능을 최적화합니다. 데이터 타입은 128비트 정수, 65,553바이트 문자열 제한이 있습니다.

데이터 포맷 및 통합

ClickHouse는 70개 이상의 입출력 포맷을 지원하며, 300개 이상의 공식 통합이 문서화되어 있습니다.

StarRocks는 상대적으로 제한된 포맷을 지원하지만, MySQL 프로토콜 호환성을 통해 다양한 BI 도구와 쉽게 연동됩니다.

4. Data Lakehouse 지원 현황

두 솔루션 모두 Data Lakehouse 아키텍처 지원을 적극적으로 확대하고 있습니다.

ClickHouse의 Lakehouse 전략

ClickHouse는 네이티브 테이블의 뛰어난 성능을 유지하면서 오픈 테이블 포맷과의 통합을 확장하고 있습니다.

Iceberg 지원 (ClickHouse 25.x):

• Catalog 지원 (Unity, REST Catalog, Polaris 등)
• 파티션 프루닝 및 통계 기반 프루닝
• 스키마 진화 및 Time Travel
• Write 지원 (실험적)

Delta Lake 지원:

• Unity Catalog 통합
• Delta Kernel 통합
• 파티션 프루닝 및 스키마 진화
• Write 지원 (실험적)

ClickHouse Cloud는 Stateless Worker 기반의 서버리스 Lakehouse 쿼리를 개발 중이며, IcebergCluster 테이블 엔진을 통해 여러 노드에서 분산 읽기, 필터링, 집계를 수행할 수 있습니다.

StarRocks의 Lakehouse 전략

StarRocks는 처음부터 **"Lakehouse Query Engine"**을 핵심 포지셔닝으로 삼았습니다.

Data Lake 직접 쿼리:

• Apache Hive, Apache Iceberg, Delta Lake, Apache Hudi 테이블 직접 접근
• 외부 카탈로그를 통한 메타데이터 통합
• 네이티브 테이블과 외부 테이블 간 조인 가능

실제 사례:

• WeChat (Tencent): 1.3B 사용자 데이터 인프라를 Hadoop에서 Iceberg + StarRocks로 전환. 일 수조 건의 레코드를 처리하면서 서브초 쿼리 레이턴시 달성. 스토리지 비용 15배 절감.
• Tencent Games: Iceberg + StarRocks 조합으로 페타바이트 규모에서 서브초 쿼리 달성.

StarRocks는 Data Lake 위에서 별도의 데이터 적재 파이프라인 없이("Pipeline-free") 직접 고성능 쿼리를 수행할 수 있다는 점을 강조합니다. 이는 기존 Trino/Presto 대비 상당한 레이턴시 개선을 제공합니다.

5. 유즈케이스별 권장 솔루션

ClickHouse가 더 적합한 경우

1. 실시간 분석 및 Observability

시나리오: 로그, 메트릭, 트레이스 데이터의 고속 적재 및 실시간 검색/분석

ClickHouse는 Observability 영역에서 사실상의 표준으로 자리잡았습니다. Cloudflare, Uber, Shopify, GitLab 등 대규모 서비스들이 ClickHouse 기반 Observability 플랫폼을 운영합니다. 최근 출시된 ClickStack(ClickHouse + HyperDX + OpenTelemetry)은 이 영역에서의 입지를 더욱 강화했습니다.

적합한 이유:

• 초당 수백만 건 이상의 로그 적재 성능
• 뛰어난 압축률로 스토리지 비용 절감 (16x 압축 달성 사례)
• 풍부한 집계 함수와 시계열 분석 기능
• Materialized View를 통한 실시간 집계

2. 단일 테이블 중심의 고속 분석

시나리오: 비정규화된 대용량 테이블에서 빠른 애드혹 쿼리

웹 분석, 이벤트 분석, 사용자 행동 분석 등 단일 플랫 테이블을 대상으로 하는 분석에서 ClickHouse는 최고의 성능을 발휘합니다.

3. 내부 분석 도구 (제한된 동시 사용자)

시나리오: 데이터 엔지니어/분석가가 사용하는 내부 분석 플랫폼

동시 사용자 수가 제한적인 환경에서 ClickHouse는 가장 빠른 쿼리 응답 시간을 제공합니다.

StarRocks가 더 적합한 경우

1. Data Lakehouse / Hadoop 교체

시나리오: 기존 Hadoop/Hive 인프라를 현대화하면서 고성능 쿼리 엔진 필요

StarRocks는 처음부터 Data Lake 위에서의 직접 쿼리를 핵심 기능으로 설계했습니다. WeChat, Tencent Games의 사례처럼, 기존 Hadoop 인프라를 Iceberg/Hudi + StarRocks로 교체하면서 성능과 비용 모두를 개선한 사례가 다수 있습니다.

적합한 이유:

• Data Lake 위 별도 적재 파이프라인 불필요 ("Pipeline-free")
• Hive, Iceberg, Delta Lake, Hudi 네이티브 지원
• 기존 BI 도구와의 MySQL 호환성
• Trino/Presto 대비 현저히 낮은 쿼리 레이턴시

2. Enterprise Data Warehouse (EDW)

시나리오: 스타/스노우플레이크 스키마 기반의 전통적인 데이터 웨어하우스

정규화된 데이터 모델을 유지해야 하는 엔터프라이즈 환경에서 StarRocks의 강력한 조인 성능과 CBO는 큰 장점입니다.

적합한 이유:

• TPC-H에서 입증된 복잡한 조인 성능
• Cost-Based Optimizer의 정교한 실행 계획
• UPDATE/DELETE의 네이티브 지원
• 기존 EDW 도구들과의 호환성

3. 고동시성 BI 대시보드

시나리오: 수백~수천 명의 비즈니스 사용자가 동시에 접속하는 BI 플랫폼

StarRocks는 수천 명의 동시 사용자를 지원하도록 설계되었습니다. 리소스 격리와 쿼리 큐잉을 통해 대규모 동시 접속 환경에서도 안정적인 성능을 제공합니다.

4. 실시간 데이터 업데이트가 빈번한 워크로드

시나리오: CDC 파이프라인을 통한 지속적인 데이터 동기화, 주문 상태 변경 등

StarRocks의 Primary Key 테이블은 실시간 upsert/delete를 효율적으로 처리합니다. 자주 변경되는 차원 데이터를 다루는 시나리오에 적합합니다.

6. 오픈소스 커뮤니티 현황

기업 정보

커뮤니티 활동

ClickHouse는 유럽과 북미/남미 시간대에 걸쳐 광범위한 커밋 활동을 보여줍니다. 주말에도 의미 있는 활동이 있어 전 세계에 분산된 팀과 유연한 근무 환경을 갖추고 있습니다. 이는 다양한 시간대 커버리지와 빠른 엔지니어링 대응을 가능하게 합니다.

StarRocks는 아시아-태평양(특히 중국) 시간대에 커밋이 집중되어 있습니다. APAC 지역의 엔터프라이즈 고객 기반이 강하며, 특히 중국 내 대형 인터넷 기업들의 채택 사례가 많습니다.

라이선스 및 오픈소스 정책

두 프로젝트 모두 Apache 2.0 라이선스를 사용합니다. 다만 ClickHouse의 경우, SharedMergeTree와 Lightweight UPDATE 등 일부 고급 기능이 Cloud 전용으로 제공되어 오픈소스 커뮤니티에서 논의가 있었습니다. Altinity 등 커뮤니티 주도의 오브젝트 스토리지 개선 작업이 진행 중입니다.

StarRocks는 Apache Doris에서 포크되어 탄생했으며, 현재는 Linux Foundation 프로젝트로 운영됩니다. 초기 포크 과정에서 라이선스 관련 논쟁이 있었으나, 현재는 독자적인 코드베이스로 발전했습니다(80~90% 코드 재작성).

7. 결론: 워크로드에 맞는 선택

ClickHouse와 StarRocks는 모두 뛰어난 분석 데이터베이스이며, **"어느 것이 더 좋다"가 아니라 "어떤 워크로드에 더 적합한가"**의 관점에서 선택해야 합니다.

선택 가이드 요약

하이브리드 접근

실제로 많은 조직이 두 솔루션을 함께 사용하기도 합니다:

• Hot 데이터 (실시간 분석): ClickHouse의 네이티브 테이블
• Cold 데이터 (히스토리 분석): Data Lake (Iceberg/Hudi) + StarRocks 또는 ClickHouse

이런 하이브리드 아키텍처는 각 솔루션의 강점을 활용하면서 비용을 최적화할 수 있습니다.

최종 권장

• 실시간 분석, Observability, 높은 적재 처리량이 핵심이라면 → ClickHouse
• Lakehouse 구축, Hadoop 교체, 복잡한 조인 쿼리, 고동시성 BI가 핵심이라면 → StarRocks

어떤 선택을 하든, 실제 워크로드로 PoC를 수행하여 성능과 운영 복잡도를 직접 검증하는 것을 권장합니다. 벤치마크 수치는 참고자료일 뿐, 실제 데이터와 쿼리 패턴에서의 성능이 가장 중요합니다.

본 문서는 ClickHouse와 StarRocks의 기술적 비교를 목적으로 작성되었습니다. 두 솔루션 모두 활발히 발전 중이므로, 최신 버전의 기능과 성능을 확인하시기 바랍니다.