OLTP와 OLAP: 운영 DB와 분석 DB를 나누는 이유

이 세션의 목표

DBA가 데이터 플랫폼을 이해할 때 가장 먼저 나눠야 하는 축은 OLTP와 OLAP다. 둘 다 SQL을 쓰고 테이블을 다루지만 목적이 다르다.

OLTP는 서비스가 지금 발생시키는 거래를 안전하게 처리한다.
OLAP은 쌓인 데이터를 크게 읽고 집계해서 판단을 돕는다.

운영 DB에 무거운 분석 쿼리가 들어와 장애가 나는 대부분의 사고는 이 둘의 목적을 섞어서 생긴다.

OLTP: 현재 상태를 지키는 시스템

OLTP(Online Transaction Processing)는 주문 생성, 결제 승인, 로그인, 재고 차감처럼 작은 트랜잭션을 많이 처리하는 시스템이다.

중요한 기준은 다음과 같다.

기준	OLTP에서 중요한 이유
짧은 응답 시간	사용자 요청과 직접 연결됨
ACID 트랜잭션	돈, 재고, 권한처럼 틀리면 안 되는 상태 관리
동시성 제어	여러 사용자가 같은 데이터를 바꿔도 일관성 유지
인덱스 최적화	특정 행을 빠르게 찾고 갱신해야 함
백업/복구	서비스 장애와 데이터 손실을 막아야 함

OLTP DB의 대표 예시는 MySQL, PostgreSQL, Oracle, SQL Server 같은 RDBMS다.

OLAP: 과거와 패턴을 읽는 시스템

OLAP(Online Analytical Processing)은 대량 데이터를 읽고 집계하는 분석 시스템이다. “지난 6개월간 고객군별 매출 추세”, “취약점 데이터 수집량 변화”, “고객사별 동기화 지연 패턴” 같은 질문에 답한다.

OLAP은 보통 다음 특징을 가진다.

기준	OLAP에서 중요한 이유
대량 scan	많은 행을 읽고 집계함
columnar storage	필요한 컬럼만 읽어 집계 성능을 높임
병렬 처리	데이터를 여러 노드/파일로 나눠 처리함
과거 데이터 보관	트렌드 분석과 감사에 필요함
비즈니스 정의	“활성 사용자”, “정상 수집” 같은 지표 정의가 중요함

왜 운영 DB에서 분석을 하면 위험한가

운영 DB는 작은 트랜잭션을 많이 처리하도록 설계된다. 분석 쿼리는 그 반대다. 긴 시간 동안 많은 행을 읽고, 임시 테이블을 만들고, 정렬·집계를 수행한다.

문제는 다음처럼 나타난다.

buffer pool이 분석 쿼리 데이터로 오염되어 서비스 쿼리 cache hit가 떨어진다.
긴 쿼리가 lock, MVCC bloat, replication lag를 유발한다.
read replica로 보냈더라도 replica lag가 커져 운영 판단이 늦어진다.
분석팀이 만든 ad-hoc query가 어떤 인덱스를 타는지 DBA가 통제하기 어렵다.

분리 패턴

OLTP DB
orders · users · payments → CDC / Batch Export
binlog · snapshot · ETL → Lake / Warehouse
raw · curated · marts → BI / Report
dashboard · audit · ML

OLTP와 OLAP 분리 흐름

데이터를 빼내는 방식

방식	장점	주의점
Read replica	기존 RDBMS 구조를 활용하기 쉬움	replica lag, 장시간 쿼리, 운영 DB 부하 전파
Dump/Snapshot	단순하고 재현 가능	전체 추출 비용, freshness 한계
CDC/binlog	변경분만 전달 가능	ordering, schema change, idempotency 설계 필요
Application event	비즈니스 이벤트 의미가 명확	이벤트 누락/중복, DB 상태와 불일치 가능

DBA가 외워야 하는 구분

질문	OLTP 답	OLAP 답
주요 작업	INSERT/UPDATE/DELETE/point SELECT	scan/join/group by
데이터 모델	정규화 중심	비정규화·star schema 가능
성능 기준	p95/p99 latency	처리량, scan cost, dashboard refresh
장애 영향	서비스 장애	의사결정 지연, 리포트 오류
대표 저장소	MySQL, PostgreSQL	BigQuery, Snowflake, Redshift, ClickHouse, Hive/Spark

실무 판단법

운영 DB에 들어온 쿼리를 보고 다음 중 하나라도 해당하면 OLAP 쪽으로 보내는 것을 검토한다.

하루/한 달 단위 집계가 들어간다.
GROUP BY, ORDER BY, COUNT(DISTINCT ...)가 크다.
조회 범위가 수십만~수천만 행 이상이다.
결과가 사용자 요청 즉시 필요하지 않다.
같은 결과를 여러 사람이 반복해서 본다.

세션 과제

운영 DB slow query log에서 가장 무거운 SELECT 하나를 골라 다음을 적어보자.

이 쿼리는 OLTP 요청인가, OLAP 요청인가?
서비스 응답에 즉시 필요한가?
replica나 warehouse로 옮길 수 있는가?
옮긴다면 freshness는 몇 분/몇 시간까지 허용되는가?

References

https://www.ibm.com/think/topics/olap
https://www.ibm.com/think/topics/oltp
https://cloud.google.com/learn/what-is-a-data-warehouse