MySQL 3분 vs ClickHouse 0.3초, 같은 쿼리입니다

ClickHouse는 행(Row) 단위인 MySQL과 달리 열(Column) 단위로 데이터를 저장해, 집계에 필요한 칼럼만 읽는다. 그래서 SUM, COUNT, AVG 같은 분석 쿼리에서 불필요한 I/O를 줄이고 대량 조회 성능을 끌어올린다.

설계 철학도 다르다. MySQL은 단건 조회와 INSERT/UPDATE/DELETE, 트랜잭션 정합성이 중요한 OLTP에 맞고, ClickHouse는 로그·통계·리포트처럼 수십억~수조 건을 빠르게 읽는 OLAP에 맞다.

적합한 패턴은 다음과 같다.

• 일별·월별 매출 합산 같은 날짜 범위 + 집계
• 수천만 건 이벤트 로그의 조건부 COUNT
• 서비스별·날짜별·타입별 다중 GROUP BY

반대로 단건 조회, 빈번한 UPDATE/DELETE, 결제·주문 같은 트랜잭션은 MySQL이 더 적합하다. ClickHouse의 UPDATE는 ReplacingMergeTree 기반이고 DELETE는 Mutation으로 처리돼 즉시성이나 소량 수정에 불리하다.

성능 테스트는 5,000만 건 이벤트 로그(6개 칼럼)를 대상으로 진행됐다. 같은 데이터, 같은 쿼리, 같은 서버 스펙에서 비교했으며 MySQL의 PK와 ClickHouse의 ORDER BY 정렬 키가 역할부터 다르다는 점도 전제로 맞췄다. 결과는 다음과 같았다.

• 월별 집계: MySQL 49초, ClickHouse 0.2초
• 3중 GROUP BY: MySQL 208초, ClickHouse 0.3초
• COUNT/DISTINCT: MySQL 67초, ClickHouse 0.2초
• View 조회: MySQL 94초, ClickHouse 0.398초
• Materialized View: 0.1초
• 동시 요청 10개: MySQL 평균 48초, ClickHouse 0.9초
• 저장 용량: 5.6GB에서 2.6GB
• 대량 적재: 849초에서 49초

MySQL 문법 호환성도 확인됐다. DATE_FORMAT, IF, CASE WHEN, LIKE, IN, BETWEEN, HAVING과 서브쿼리가 동작했고, MySQL Client(포트 7004)로도 접속이 가능했다.

NHN Cloud 내부에서는 Notification Hub, Cab-Verify, Resource Watcher에 ClickHouse를 적용했다. Notification Hub는 카카오 비즈센터 통계를 ClickHouse에 적재해 다양한 조건의 집계를 제공했고, Cab-Verify는 최대 1억 건의 토큰 인증 이력을 관리하며 10억 건 이상 확대를 대비했다. Resource Watcher는 배치 조회를 분리해 MySQL 슬로 쿼리와 failover 위험을 줄였다. 결론은 분명하다. 정합성이 중요한 트랜잭션은 MySQL, 대규모 집계·분석은 ClickHouse가 맡는 구성이 가장 효과적이다.