컬럼형 저장소로 분석 쿼리 개선 경험
약 90초
행 지향 DB에서 컬럼형 OLAP으로 전환해 분석 성능을 높인 경험
졸업 작품에서 일간 판매 분석 쿼리가 데이터가 늘수록 느려졌습니다. MySQL에서 전체 기간 집계를 하면 5만 건 기준으로 8초가 넘었습니다. 분석 쿼리에 행 지향 DB가 맞지 않는다는 걸 그때 처음 알았습니다.
DuckDB를 사이드 프로젝트에서 써봤던 경험이 있어서 도입해 봤습니다. 같은 데이터에 대해 집계 쿼리를 실행했더니 400ms로 줄었습니다. 컬럼형 저장 방식이 집계 연산에 얼마나 유리한지 직접 체감했습니다.
실패 경험도 있었습니다. DuckDB는 인-메모리 기반이라 서버 재시작 시 데이터를 다시 로드해야 했고, 운영 환경에서 메모리 예산을 초과하는 문제가 생겼습니다. 자주 조회되는 집계 결과는 미리 계산해 별도 테이블에 캐싱하는 방식을 추가해 해결했습니다.
분석 성능은 DB 선택부터 시작된다는 걸 그때 처음 배웠습니다.
이 결의 특징
MySQL 집계 쿼리가 5만 건 기준 8초 걸리던 것을 DuckDB로 400ms까지 줄이고, 인메모리 특성 탓에 재시작 시 재로드와 메모리 초과 문제를 캐싱 테이블로 해결한 흐름이 담겨 있습니다.
이 결이 통하는 자리
8초에서 400ms라는 구체 수치와 이후 메모리 문제 해결 과정이 함께 남아 있을 때 통합니다. 분석 성능은 DB 선택부터 시작된다는 결론이 실제 전환에서 나온 것임이 드러나면 면접관이 신뢰하는 결이 보입니다.