데이터베이스 성능 비교: SingleStore vs. ClickHouse 실전 분석

 

안녕하세요 에이플랫폼 입니다.

이번 글에서는 두 인기 데이터베이스인 SingleStore와 ClickHouse의 성능을 비교한 실전 분석 결과를 공유합니다.

두 시스템은 유사한 사용 목적을 갖고 있어 많은 사용자들이 선택의 기로에 놓이는데요. 이를 돕기 위해 각 데이터베이스의 성능을 객관적인 지표로 평가하고, 특히 SingleStore를 효과적으로 활용할 수 있는 방법을 살펴보겠습니다.

특히 눈여겨볼 부분은, 대규모 데이터 분석에서 핵심적인 역할을 하는 조인(Join) 쿼리에서 ClickHouse가 기대와 달리 낮은 성능을 보였다는 점입니다.

이러한 결과는 빅데이터 기반의 업무 환경에서 최적의 데이터베이스를 선택할 때 중요한 시사점을 제공합니다.

 

---

테스트 방법

이번 성능 비교 테스트는 TPC-DS 데이터셋을 기반으로 진행되었습니다.

TPC-DS는 현대적인 분석 워크로드에 필요한 다양한 기능을 활용하며, 스타 스키마 구조를 채택하고 있습니다.

이를 통해 실제 사용 사례를 반영한 객관적인 성능 결과를 제공하는 것을 목표로 합니다.

분석을 위해 선별된 TPC-DS 쿼리와 커스텀 쿼리를 사용하였으며, TPC-DS가 포함하는 99개의 복잡한 쿼리를 통해 조인(Join), 공통 테이블 표현식(CTE) 등 현대 분석 시스템의 주요 기능을 평가했습니다.

하지만 ClickHouse는 모든 쿼리를 실행할 수 없다는 제한점이 존재하므로, 일부 쿼리를 선별하고 DS 스키마를 활용한 추가 쿼리를 포함하여 테스트를 진행했습니다.

테스트 환경

• 데이터셋: 1TB TPC-DS 데이터셋
• ClickHouse Cloud: 2x(59 vCores, 236 GB RAM)
• SingleStore Helios: S-8 구성 (64 vCPU, 512GB RAM)

Round 1: 첫 번째 실험

첫 번째 실험에서는 총 10개의 쿼리를 실행하여 성능을 측정했습니다.

이 실험은 다양한 쿼리 유형을 테스트할 수 있도록 설계되었으며, 여러 유형의 집계 및 필터링을 포함하고 있습니다.

특히, 한 개를 제외한 모든 쿼리에 조인(Join)이 포함되어 있어, 데이터베이스가 복잡한 조인 연산을 처리하는 능력을 평가할 수 있었습니다.

ClickHouse의 성능 문제

테스트 결과, ClickHouse가 조인(Join) 쿼리에서 예상보다 현저히 느린 성능을 보인다는 점이 확인되었습니다.

대부분의 쿼리에서 ClickHouse는 SingleStore보다 수천 배 느린 속도를 기록했으며, 이 결과는 처음에는 상당히 충격적이었습니다.

실험에 포함된 모든 그래프에서 동일한 패턴이 나타났으며, 아래의 그래프는 그 대표적인 예시입니다.

성능 비교 그래프

아래 그래프는 TPC-DS 쿼리 3번을 실행한 결과를 나타냅니다.

이 실험에서는 벤치마크에서 제공하는 원본 TPC-DS 스키마와 쿼리를 그대로 사용했으며, ClickHouse는 튜닝 없이 기본 설정에서 실행되었습니다.

사용한 쿼리

첫 번째 라운드의 워크로드에는 TPC-DS 쿼리 3(아래)과 TPC-DS 쿼리에서 영감을 받은 분석 쿼리를 포함하여 총 10개의 혼합된 쿼리가 포함되었습니다.

모든 쿼리는 1시간 런타임 동안 단일 스레드 모드에서 실행되었으며, 이를 통해 각 시스템의 성능을 보다 정교하게 평가할 수 있었습니다.

 define AGGC= 
text({"ss_ext_sales_price",1},{"ss_sales_price",1},{"ss_ext_discount_amt",1},{
"ss_net_profit",1});
 define MONTH = random(11,12,uniform);
 define MANUFACT= random(1,1000,uniform);
 define _LIMIT=100;

select  dt.d_year 
       ,item.i_brand_id brand_id 
       ,item.i_brand brand
       ,sum([AGGC]) sum_agg  /* sum(ss_ext_sales_price) sum_agg */
 from  date_dim dt 
      ,store_sales
      ,item
 where dt.d_date_sk = store_sales.ss_sold_date_sk
   and store_sales.ss_item_sk = item.i_item_sk
   and item.i_manufact_id = [MANUFACT] 
   and dt.d_moy=[MONTH]  
 group by dt.d_year 
      ,item.i_brand 
      ,item.i_brand_id 
 order by dt.d_year
         ,sum_agg desc
         ,brand_id
 limit 100

▲ 그림 1: 1라운드 테스트 결과 - ClickHouse vs. SingleStore 성능 비교 (TPC-DS 쿼리 3번, 튜닝 전)

실험 결과의 의미

모든 쿼리에서 SingleStore가 ClickHouse를 압도적으로 앞서는 성능을 보였으며, 경우에 따라 몇 배 이상의 차이를 기록했습니다.

이러한 성능 차이는 단순한 벤치마크 수치의 문제가 아니라, 실제 애플리케이션 환경에서 심각한 성능 저하를 초래할 수 있는 근본적인 격차를 의미합니다.

 

---

Round 2: ClickHouse에 최적의 환경 제공

두 번째 실험에서는 ClickHouse에게 유리한 조건을 제공하기 위해 대부분의 조인을 제거한 상태에서 테스트를 진행했습니다.

이 실험을 통해 다양한 쿼리 유형에서 SingleStore와 ClickHouse가 각각 어떤 영역에서 강점을 가지는지 보다 명확하게 비교할 수 있도록 했습니다.

테스트에서는 작은 조인 하나(매우 작은 테이블과의 조인)와 큰 조인 하나만 유지했습니다.

이는 조인이 불가피한 상황을 고려한 선택으로, 다음과 같은 경우에서 조인은 반드시 필요합니다.

• 개인정보 보호를 위해 민감 데이터를 별도 테이블로 분리하는 경우
• 다양한 관점에서 데이터를 분석할 수 있도록 유연성을 확보하는 경우
• 팩트 테이블을 다시 작성하지 않고 차원 데이터를 업데이트할 수 있는 기능이 요구되는 경우

ClickHouse의 튜닝 과정

이러한 이유로 일부 조인을 유지하면서 ClickHouse를 튜닝하기로 했습니다.

첫 번째 튜닝 과정에서는 쿼리의 조인 순서를 재정렬하여 최적화를 시도했습니다.

벤치마크에서는 쿼리를 다시 작성하여 조인 순서를 조정할 수 있지만,

비즈니스 인텔리전스(BI) 도구에서 자동 생성되는 쿼리 환경에서는 이러한 최적화가 현실적으로 어렵다는 한계가 있습니다.

그럼에도 불구하고 이 튜닝 과정은 ClickHouse 성능을 크게 향상시키는 결과를 가져왔습니다.

여전히 존재하는 성능 차이

다음 그래프는 튜닝되지 않은 ClickHouse VS 튜닝된 ClickHouse VS SingleStore 의 성능을 비교한 결과입니다.

튜닝을 통해 ClickHouse의 성능이 개선되었음에도 불구하고, 대규모 조인 시나리오에서는 여전히 SingleStore가 상당한 성능 우위를 유지하고 있었습니다.

사용한 쿼리

두 번째 라운드의 워크로드는 큰 조인과 작은 조인을 포함한 3개의 쿼리로 구성되었습니다.

모든 쿼리는 1시간 동안 단일 스레드 모드에서 실행되었으며, 이를 통해 각 시스템이 다양한 조인 유형을 처리하는 방식과 성능 차이를 평가할 수 있었습니다.

define YEAR=random(1998, 2002, uniform);
define _LIMIT = 100;
define BP= text({"1001-5000",1},{">10000",1},{"501-1000",1});
define MS= dist(marital_status, 1, 1);

select i_item_desc
      ,w_warehouse_name
      ,d1.d_week_seq
      ,sum(case when p_promo_sk is null then 1 else 0 end) no_promo
      ,sum(case when p_promo_sk is not null then 1 else 0 end) promo
      ,count(*) total_cnt
from catalog_sales
join inventory on (cs_item_sk = inv_item_sk)
join warehouse on (w_warehouse_sk=inv_warehouse_sk)
join item on (i_item_sk = cs_item_sk)
join customer_demographics on (cs_bill_cdemo_sk = cd_demo_sk)
join household_demographics on (cs_bill_hdemo_sk = hd_demo_sk)
join date_dim d1 on (cs_sold_date_sk = d1.d_date_sk)
join date_dim d2 on (inv_date_sk = d2.d_date_sk)
join date_dim d3 on (cs_ship_date_sk = d3.d_date_sk)
left outer join promotion on (cs_promo_sk=p_promo_sk)
left outer join catalog_returns on (cr_item_sk = cs_item_sk and 
cr_order_number = cs_order_number)
where d1.d_week_seq = d2.d_week_seq
  and inv_quantity_on_hand < cs_quantity 
  and d3.d_date > d1.d_date + 5
  and hd_buy_potential = '[BP]'
  and d1.d_year = [YEAR]
  and cd_marital_status = '[MS]'
group by i_item_desc,w_warehouse_name,d1.d_week_seq
order by total_cnt desc, i_item_desc, w_warehouse_name, d_week_seq
LIMIT 100;

 

▲ 그림 2: 2라운드 테스트 결과 - 대규모 조인에서의 튜닝된 ClickHouse 성능

또한, 소규모 조인 테스트에서도 ClickHouse의 성능이 향상되었지만, 여전히 SingleStore가 더 뛰어난 성능을 보이는 모습이 확인되었습니다.

사용한 쿼리

define SDT = random(2450816,2452642,uniform); 

select s_store_id 
  ,count(ss_quantity) as store_sales_quantitycount
       ,avg(ss_quantity) as store_sales_quantityave
       ,stddev_samp(ss_quantity) as store_sales_quantitystdev
       ,stddev_samp(ss_quantity)/avg(ss_quantity) as store_sales_quantitycov
   	  ,sum(ss_sales_price) as store_sales_spricesum
  	  ,avg(ss_sales_price) as store_sales_spriceave
  ,avg(ss_wholesale_cost) as store_sales_wscostave
  ,sum(ss_list_price) as store_sales_lpricesum
  ,avg(ss_list_price) as store_sales_lpriceave
  ,sum(ss_ext_tax) as store_sales_taxsum 
  ,max(ss_ext_sales_price) as store_sales_espricemax
  ,min(ss_ext_list_price) as store_sales_elpricemin 
from store_sales,  
     store
where  s_store_sk = ss_store_sk AND
       ss_sold_date_sk = SDT
group by s_store_id;

 

▲ 그림 3: 2라운드 테스트 결과 - 소규모 테이블 조인 성능

이론적으로 소규모 조인은 ClickHouse에 더 유리할 것으로 예상되었지만, 실제 테스트 결과 SingleStore의 성능이 더 우수하게 나타났습니다.

 

---

핵심 발견사항과 중요한 시사점

지금까지의 결론

• ClickHouse는 좋은 성능을 위해 튜닝이 필요합니다
• 튜닝하지 않은 SingleStore가 튜닝하지 않은 ClickHouse보다 훨씬 우수합니다.
• ClickHouse가 SingleStore의 성능에 맞출 수 있는지 계속 확인해보겠습니다.

이번 실험을 통해 단순한 성능 지표를 넘어, 데이터베이스 선택 시 고려해야 할 중요한 시사점을 얻을 수 있었습니다.

📋 운영 복잡성

ClickHouse는 광범위한 튜닝이 필요하여 상당한 운영 부담이 크다는 점이 확인되었습니다.

수용 가능한 성능을 달성하려면 깊은 전문 지식과 지속적인 최적화가 요구되며, 이는 총 소유 비용(TCO) 증가로 이어집니다.

⚡ 기본 성능

SingleStore는 별도의 튜닝 없이도 뛰어난 성능을 제공하며, 이는 낮은 운영 복잡성을 의미합니다.

결과적으로 분석 솔루션을 도입하려는 조직이 더 빠르게 가치를 실현할 수 있는 환경을 제공합니다.

🔗 실제 조인 요구사항

조인 성능 차이는 단순한 벤치마크 결과가 아닙니다.

실제 빅데이터 분석 환경에서는 다음과 같은 이유로 조인이 필수적입니다.

• 민감한 개인정보를 분리하여 관리
• 데이터에 대한 유연한 접근 방식 확보
• 팩트 테이블을 재작성하지 않고 차원 데이터를 업데이트할 수 있는 기능 제공
• 무결성 유지, 저장 효율성 증대 및 비즈니스 분석가의 이해도를 높이기 위한 스타 스키마 모델 유지

⚙️ 구성 복잡성

ClickHouse는 기존 데이터베이스 시스템보다는 데이터베이스 프레임워크에 가까운 방식으로 작동합니다.

이로 인해 배포 환경에 따라 극적으로 다른 성능 특성을 보이며,

수많은 구성 옵션이 존재하여 최적화를 위한 추가적인 학습과 노력이 필요합니다.

 

---

현대 데이터 분석에서 이러한 결과가 중요한 이유

이번 실험에서 관찰된 성능 차이는 AI 및 분석 애플리케이션을 구축하는 조직에 직접적인 영향을 미칩니다.

조인 연산은 대부분의 실제 분석 워크로드의 필수 요소이며,

ClickHouse의 조인 성능 제한은 조직이 쿼리 성능과 데이터 아키텍처 모범 사례 사이에서 불필요한 선택을 강요받을 수 있음을 의미합니다.

또한 ClickHouse의 튜닝 요구사항은 조직이 데이터베이스 최적화와 데이터 변환에 많은 리소스를 투자해야 한다는 점을 시사합니다.

이러한 작업은 데이터 파이프라인을 더욱 복잡하게 만들고, 추가적인 지연시간을 초래하며,

결과적으로 분석 애플리케이션을 통한 비즈니스 가치 창출 과정에서 집중력을 분산시킵니다.

 

---

ClickHouse는 분석 분야에서 널리 사용되고 있지만, 이번 테스트 결과 조직이 신중하게 고려해야 할 성능 격차와 운영 복잡성 문제가 존재함을 확인할 수 있었습니다.

반면, SingleStore는 프로덕션 AI 및 분석 애플리케이션에 필요한 단순성과 안정성을 유지하면서, 다양한 워크로드에서 뛰어난 기본 성능을 제공합니다.

🏆 SingleStore가 제공하는 이점

분석 데이터베이스를 평가하는 기업이라면 다음을 주목해야 합니다.

• SingleStore는 광범위한 튜닝 없이도 우수한 성능을 발휘하는 견고하고 사용자 친화적인 솔루션을 제공합니다.
• 이를 통해 데이터베이스 최적화에 소모되는 시간을 줄이고, 더 중요한 비즈니스 가치 창출에 집중할 수 있습니다.

🚀 명확한 성능 차이

실제 분석 워크로드에서 SingleStore는 AI 및 분석 이니셔티브를 진행하는 기업이 요구하는 성능과 운영의 단순성을 제공합니다.

모든 테스트에서 SingleStore가 ClickHouse를 압도적으로 앞섰으며, 경우에 따라 수 배 이상의 성능 차이를 기록했습니다.

이러한 격차는 단순한 벤치마크 수치의 문제가 아니라, 실제 애플리케이션 환경에서 심각한 성능 저하를 초래할 수 있는 근본적인 차이를 의미합니다.

 

SingleStore의 연구는 지속적으로 진행될 예정이며, 향후 새로운 내용에 대해 에이플랫폼 블로그에서 빠르게 전달해 드리겠습니다.