PostgreSQL에서 ClickHouse로의 전환, 왜 선택했나
대용량 데이터를 다루는 시스템에서 데이터베이스 엔진의 선택은 곧 성능의 한계를 결정한다. Momentic은 하루 200만 건 이상의 쿼리와 총 200억 건의 엔트리를 처리하는 캐싱 시스템을 운영하면서, 기존 PostgreSQL 기반 아키텍처의 한계에 직면했다. PostgreSQL은 OLTP(온라인 트랜잭션 처리) 환경에 최적화된 행(row) 지향 데이터베이스로, 개별 레코드의 삽입·수정·조회에는 강하지만 대규모 집계 쿼리나 컬럼 단위 스캔이 빈번한 워크로드에서는 성능 저하가 발생하기 쉽다.
이에 Momentic은 컬럼 지향(column-oriented) 데이터베이스인 ClickHouse로의 전환을 결정했다. ClickHouse는 동일한 컬럼의 데이터를 연속적으로 저장하는 구조 덕분에 집계 쿼리, 범위 스캔, 대용량 읽기 작업에서 압도적인 성능을 발휘한다. 특히 캐싱 시스템처럼 특정 키에 대한 최신 값 조회나 시계열 기반 집계가 반복적으로 발생하는 패턴에서는 컬럼 지향 구조가 유리하다.
아키텍처 전환에서 고려해야 할 실무 포인트
데이터베이스 엔진 교체는 단순한 마이그레이션이 아니라 쿼리 패턴, 데이터 모델, 운영 방식 전반의 재설계를 의미한다. ClickHouse는 PostgreSQL과 달리 UPDATE/DELETE 연산이 비용이 크고, 트랜잭션 지원이 제한적이다. 따라서 쓰기 집약적이거나 잦은 업데이트가 필요한 시스템에는 적합하지 않을 수 있다.
-- ClickHouse에서의 집계 쿼리 예시
SELECT cache_key, max(updated_at) AS last_updated, count() AS hit_count
FROM cache_entries
WHERE created_at >= today() - 7
GROUP BY cache_key
ORDER BY hit_count DESC
LIMIT 100;
위와 같이 대량의 행을 집계하는 쿼리는 ClickHouse에서 PostgreSQL 대비 수십 배 빠른 응답을 보여주는 경우가 많다. 반면 단건 업데이트가 빈번한 구조라면 ReplacingMergeTree나 CollapsingMergeTree 같은 ClickHouse 전용 엔진 선택과 머지 전략을 신중히 설계해야 한다.
-- ReplacingMergeTree 테이블 정의 예시
CREATE TABLE cache_entries (
cache_key String,
value String,
updated_at DateTime
) ENGINE = ReplacingMergeTree(updated_at)
ORDER BY cache_key;
운영 관점에서는 ClickHouse의 비동기 머지 특성으로 인해 최신 데이터가 즉시 반영되지 않을 수 있으므로, 읽기 쿼리에 FINAL 키워드를 활용하거나 애플리케이션 레이어에서 중복 제거 로직을 별도로 두는 전략이 필요하다.
대규모 캐싱 시스템에서의 성능 개선 의미
Momentic의 사례에서 주목할 점은 200억 건이라는 엔트리 규모에서 평균 응답 지연을 약 250ms 수준으로 유지했다는 것이다. 이는 단순한 인덱스 튜닝이나 쿼리 최적화로는 달성하기 어려운 수치로, 근본적인 스토리지 엔진 교체가 가져다주는 구조적 이점을 보여준다.
4년차 이상의 백엔드 개발자라면 시스템의 병목이 애플리케이션 코드가 아닌 데이터베이스 엔진 자체의 특성에서 비롯될 수 있음을 인식해야 한다. 특히 캐시 히트율 분석, 쿼리 로그 집계, 사용 패턴 리포팅 등 읽기 중심의 분석성 워크로드가 늘어나는 시점이라면 컬럼 지향 데이터베이스 도입을 진지하게 검토할 필요가 있다.
정리
- PostgreSQL은 OLTP에 강하지만, 대용량 집계·스캔 워크로드에서는 컬럼 지향 DB인 ClickHouse가 구조적으로 유리하다.
- ClickHouse 전환 시 UPDATE/DELETE 제한, 비동기 머지 특성 등 PostgreSQL과의 차이를 반드시 아키텍처 설계 단계에서 고려해야 한다.
- 스토리지 엔진 교체는 쿼리 패턴과 데이터 모델 전반의 재설계를 수반하며, 읽기 중심의 대규모 캐싱 시스템에서 가장 큰 효과를 발휘한다.