주식 데이터 100GB 쌓고 나서야 DB 설계 잘못된 걸 깨달은 개발자의 눈물겨운 이주기

요약 한 개발자가 주식 데이터 분석 프로젝트를 운영하며 겪은 데이터베이스 아키텍처 전환 경험담입니다. 작성자는 첫 번째 버전(v1)에서 OLTP 엔진인 MySQL InnoDB를 사용해 주식 데이터 분석 환경을 구축했습니다. InnoDB는 한 행의 모든 컬럼을 디스크의 동일한 위치에 저장하고 B-tree 인덱스와 MVCC(다중 버전 동시성 제어)를 통해 쓰기 작업 중에도 읽기를 차단하지 않는 특성을 지닙니다. 작성자는 금융 데이터 테이블(`FinancialData`)에 일시, 시가, 고가, 저가, 종가 및 각종 지표를 한데 모아두고 해시 파티셔닝(100개 파티션)을 적용해 100GB가 넘는 대용량 데이터를 처리했습니다. 그러나 분석용 보조 지표 테이블들이 날짜 컬럼 없이 `FinancialDataID`로만 기본 테이블과 조인되도록 설계되어 있어 쿼리 성능 문제가 심각해졌습니다. 결국 100GB가 넘는 상태에서 날짜 컬럼을 추가하기 위해 임시 테이블과 스케줄러 기반의 고통스러운 업데이트 작업을 거쳐야 했습니다. 시스템 운영 5년 차에 접어들며 작성자는 정작 분석 작업에서는 테이블당 2~3개 컬럼만 필요한데도 행 기반 엔진 특성상 전체 컬럼을 읽어야 하는 비효율을 깨달았고, 단 하나의 핵심 최적화를 위해 OLAP 스택(Iceberg 레이크하우스)으로 아키텍처를 전면 전환하게 된 내부 과정을 상세히 다루고 있습니다.