컬럼형 DB ClickHouse??

얼마 전 오픈서베이에서 주최한 DATA ON FIRE 25 컨퍼런스에 다녀왔다.

 

사람 구경도 하고 👀, 커피도 마시고 ☕, 무드등도 받고…

그러다 오픈서베이 개발자분이 나오셔서 기술적인 부분을 잠깐 설명하는 세션을 가졌었는데, DB를 ClickHouse를 쓰신다고 하셨다.

ClickHouse라는 DB를 처음 들어봐서 갑자기 궁금해졌다.

 

알아보니 ClickHouse는 러시아회사가 만든 OLAP(Online Analytical Processing) DB였다.

우리가 흔히 알고있는 전통적인 DB (MySql, PostgreSQL 등) 랑은 다른게 ClickHouse는 컬럼형 DB다.

 

컬럼형 DB는 엑셀처럼 생긴 데이터를 다룰 때 열 단위로 정보를 저장하고 읽는 방식이다.

 

 

행(row) 기반 DBMS 처리 방식

출처: Row-oriented DBMS (source : clickhouse.com/docs)

 

 

열(column) 기반 DBMS 처리 방식

출처: Column-oriented DBMS (source : clickhouse.com/docs)

 

보통 우리가 쓰는 전통적인 DBMS(예: MySQL, PostgreSQL)는 “행(row)” 단위로 데이터를 저장한다.

 

즉, 어떤 학생의 이름, 나이, 키, 점수 같은 정보를 한 줄에 몽땅 묶어서 저장하는 거죠. 그래서 뭔가 꺼내 쓸 때도,

“점수만 필요하다고? 미안~ 이름이랑 나이도 같이 들고 갈게.”

 

하는 식이다.

 

근데 열(column) 기반 DBMS는 다르다.

“점수만 달라고? 오케이, 점수 열만 깔끔하게 뽑아줄게요.”

 

하는 효율적인 스타일이다.

 

 

데이터 저장 예시

 

열(colunm) 기반 DBMS 저장소

사용자 ID 컬럼:
[1, 2, 3]

닉네임 컬럼:
["햄버거", "치즈버거", "불고기버거"]

이메일 컬럼:
["hamburger@example.com", "cheeseburger@example.com", "bulgogiburger@example.com"]

 

행(row) 기반 DBMS 저장소

[1, "햄버거", "hamburger@example.com"]
[2, "치즈버거", "cheeseburger@example.com"]
[3, "불고기버거", "bulgogiburger@example.com"]

 

• 컬럼형 구조라서 읽기 속도는 말도 안 되게 빠름
  SELECT 절에 쓴 컬럼만 읽으니까 불필요한 I/O가 없음.
• MERGE TREE라는 강력한 인덱싱 구조
  압축도 잘되고, 정렬도 잘돼서 쿼리 최적화에 유리하대요.
• Kafka, S3 연동 기본 탑재
  실시간 ingestion에도 강해서 실시간 분석 서비스도 가능!
• 운영 중인 회사에서는 서비스 지표나 로그 대시보드 외에도
  실시간 사용자 알림/추천용 데이터 저장소로도 사용 중이라고…

그래서 이런 컬럼형 DB는 주로 OLAP(Online Analytical Processing) 용도로 쓰이고 있다.

즉, "분석"에 특화된 데이터 처리 방식!

 

반대로 우리가 자주 들어본 MySQL, PostgreSQL 같은 OLTP(Online Transaction Processing) 시스템은,

회원가입, 주문처리, 결제처럼 실시간으로 데이터를 입력하고 수정해야 하는 상황에 최적화돼 있다.

즉, 초 단위로 트랜잭션이 일어나는 환경에선 행(row) 기반 DB가 훨씬 유리하다.

빠르게 쓰고, 정확하게 저장하고, 안정적으로 반영하는 게 핵심.

 

항목	OLTP	OLAP
목적	트랜잭션 처리	데이터 분석
주 용도	쇼핑몰, 은행, 서비스 운영	BI툴, 리포트, 대시보드
쿼리 유형	INSERT, UPDATE, DELETE 위주	SELECT + GROUP BY + JOIN 많음
구조	정규화 중심, 행 기반	비정규화 or 컬럼 기반
속도	빠른 처리속도 (쓰기 위주)	대용량 조회에 최적화 (읽기 위주)

 

 

✔ OLTP는 빠른 거래와 정확한 기록을 위한 DB

✔ OLAP은 넓고 깊은 분석을 위한 DB

 

그러나 컬럼형DB는 ClickHouse만 있는게 아니다.

 

주요 컬럼형 DBMS 비교

DBMS	특징	장점	단점
BigQuery	쿼리 날릴 때마다 돈 내는 대신, 인프라는 걱정 NO	완전 서버리스, 확장성 최강, TB 단위 쿼리도 클릭 몇 번	쿼리마다 비용 발생, 실시간성 부족
Amazon Redshift	AWS에서 만든 전통 강호 데이터 웨어하우스	복잡한 SQL/JOIN 가능, AWS 생태계와 찰떡궁합	셋업 필요, 비용 계산 복잡
Snowflake	클라우드 시대의 끝판왕	컴퓨트/스토리지 분리, 자동 확장, 멀티 클라우드 지원	가격이 비쌈, 구조가 상대적으로 블랙박스 느낌
Apache Druid	실시간 대시보드/로그 분석의 강자	빠른 ingest + 빠른 집계, 실시간 분석 특화	JOIN 매우 약함, 복잡한 쿼리 어려움

 

그럼에도 불구하고 ClickHouse는 셀프 호스팅이 가능하면서도 빠른 쿼리 속도, 실시간에 가까운 분석 성능이 강점이다.

결국 중요한건 우리 서비스에 필요한 스펙, 예산, 팀의 역량에 맞게 컬럼형 DB를 골라 써야 한다는 점!

 

그러나!

모든 기술이 그렇듯 단점도 존재한다.

 

• 복잡한 트랜잭션 처리에는 여전히 부적합
• JOIN 약하고, UPDATE/DELETE도 느림
• 트래픽 폭주나 파티션 설계 실패 시 성능 급락할 수 있음

 

 

💥 근데 진짜 "서비스 DB"로 써도 되나?

 

✔ 읽기 위주 서비스,
✔ 사용자 수 많고 쿼리 패턴 예측 가능한 경우,
✔ 데이터 모델이 denormalized 되어 있을 때

 

이 조건들이 맞으면, 실시간 서비스 조회 용도로 ClickHouse 쓰는 거, 요즘은 꽤 흔한 전략이다.

 

조만간 나도 테스트삼아 써봐야겠다라는 생각이 들었다.

 

ClickHouse 공식사이트

Fast Open-Source OLAP DBMS - ClickHouse