Clickhouse 데이터 웨어하우스로서의 한계와 단점

2024.11.22 - [데이터 엔지니어링] - BigQuery에서 ClickHouse로 이벤트 로그 데이터 분석 환경 개선하기

이전에 빅쿼리를 이용하다가 클릭하우스로 넘어온 이후 이벤트 로그 분석에서는 빠른 성능을 경험했다. 특히 몇억 건의 대량의 이벤트 데이터를 단순 집계하거나 필터링할 때 ClickHouse가 확실히 좋은 성능을 보여줬다. 하지만 최근 MySQL 데이터를 클릭하우스로 마이그레이션하면서 데이터 웨어하우스 용도로 쓰려다 보니 몇 가지 단점들이 보이기 시작했다.

---

1. JOIN 연산에서의 한계

클릭하우스는 기본적으로 INNER JOIN 이외의 JOIN 연산을 다루기 어렵다. 그 이유는 ClickHouse의 엔진 설계상 JOIN 연산이 메모리에서만 수행되기 때문이다. 게다가 ClickHouse는 단일 프라이머리 인덱스만 허용하고 보조 인덱스를 제공하지 않아서 여러 테이블을 키로 연결할 때 성능 저하가 있었다.

실제로 MySQL에서 자주 활용하던 정규화된 테이블 여러 개를 ClickHouse로 그대로 옮긴 후 쿼리 테스트를 해봤는데, JOIN이 포함된 쿼리는 성능이 현저히 떨어졌다. 몇십만개 수준의 테이블인데도 인덱스가 미비하다보니 단순 id JOIN에서도 15초가 걸리는 것을 보았다. (mysql에서는 전부 불러와도 0.2초 수준)

2. 복잡한 SQL 기능 미지원

클릭하우스는 간단한 SELECT 문과 간단한 집계에는 매우 빠르지만, 복잡한 SQL 쿼리나 윈도우 함수가 섞인 복잡한 분석 쿼리에는 제약이 있었다. 예를 들어 아래와 같은 스칼라 서브쿼리는 클릭하우스에서 지원하지 않는다. 클릭하우스가 열기반 데이터베이스다 보니까 아래 처럼 한 행씩 읽어서 처리하는 방식이 지원되지 않는다.

SELECT s.id,
       (SELECT COUNT(*) FROM contracts c WHERE c.student_id = s.id) AS contract_count
FROM students s;

• 위 쿼리를 클릭하우스에서 실행하면 부모 쿼리의 컬럼을 서브쿼리에서 참조할 수 없다는 에러 문구가 발생한다.

아래 쿼리 처럼 join을 먼저 하고 집계를 할 수 있게 수정해야 실행이 되는데, 문제는 만약 위처럼 클릭하우스에서 지원하지 않는 형태의 쿼리들을 다른 사람들이 사용하고 있을 때이다. 이를 클릭하우스에서 적용되는 형태로 바꿔주는 것도 리소스 소모가 생겼다.

SELECT s.id AS student_id, COUNT(c.id) AS contract_count
FROM students s
LEFT JOIN contracts c ON s.id = c.student_id
GROUP BY s.id;

 

3. 데이터 수정 및 트랜잭션 제약

데이터 수정(UPDATE/DELETE)에 대한 지원이 매우 제한적이다. 일단 데이터를 넣으면 이후 수정이나 삭제가 어렵기 때문에, 특히 정확성이 중요한 데이터라면 문제가 될 수 있다. ReplacingMergeTree 엔진을 사용하면 중복을 제거 할 수 있긴하다. ReplacingMergeTree(updated_at) 으로 엔진을 설정하면 order by 된 key를 updated_at 기준으로 최신값만 남게 된다. 하지만 이것도 실시간으로 중복이 제거되는 것이 아니고 한번씩 최적화 작업을 하면서 제거 되는 것이여서 쿼리를 하는 사람들이 불편함을 겪었다. 그리고 스키마가 만약 변경된 경우도 수정이 되지 않아 새로운 컬럼을 추가하던지, 테이블을 새로 만들어서 마이그레이션 하던지 해야 했다. 지금은 테이블 수가 몇 안되서 관리가 된다고 쳐도 확장해서 사용하기엔 데이터 관리에 리소스가 생각 이상으로 들게 될 것이라고 느꼈다.

---

마이그레이션 과정에서 든 개인적인 생각이지만 MySQL에서 데이터를 옮길 때 데이터 규모가 크지 않다면 굳이 클릭하우스를 선택할 필요가 없다는 것이다. RDS 환경에서는 MySQL 데이터를 PostgreSQL로 마이그레이션하는 작업이 상대적으로 간단하기 때문이다. 데이터 이전도 간단하고 트랜잭션도 지원하고 테이블 관계도 지원하고, 이벤트 로그 같은 insert 위주의 대용량 데이터가 아니라면 일반적인 데이터 분석에서는 PostgreSQL 같은 전통적인 DB가 훨씬 효율적이라고 느꼈다. (심지어 이미 PostgreSQL를 사용하고 있기도 했고..) 이 부분은 의견을 더 강하게 내지 못한 것 같아 아쉽다.

---

결론

ClickHouse는 뛰어난 성능을 자랑하는 OLAP 전용 데이터베이스지만, JOIN 연산의 제약, 복잡한 SQL 지원 부족, 인덱싱의 한계, 그리고 데이터 수정 기능 제한이라는 확실한 단점이 있다. 이벤트 로그 분석처럼 특정 목적에선 강력한 도구지만, 일반적인 데이터 웨어하우스 용도로 MySQL 데이터를 그대로 옮기는 식으로 접근하면 적합하지 않다. 결국 데이터의 특성과 분석 요구사항에 따라, 적절한 데이터베이스를 선택하고 이에 맞는 데이터 모델링 전략을 마련하는 것이 가장 중요하다.