OLTP vs OLAP

• **OLTP(Online Transaction Processing)**는 서비스가 실시간으로 읽고 쓰는 트랜잭션 처리용 DB 성격
• **OLAP(Online Analytical Processing)**는 모아둔 데이터를 다각도로 집계·분석하는 읽기 중심의 분석용 DB 성격
• 둘은 같은 “데이터베이스”라는 단어를 쓰지만, 최적화 목표가 정반대인 두 워크로드

왜 둘을 나누는가

• 운영 DB(OLTP)에 무거운 분석 쿼리를 직접 날리면, 운영 트래픽과 자원을 뺏어 서비스가 느려진다
• OLTP는 “쓰기/동시성/정합성”에, OLAP은 “대량 스캔/집계 속도”에 최적이라 한 DB가 둘 다 잘하기 어렵다
• 그래서 데이터 마트·데이터 웨어하우스 같은 OLAP 계층을 별도로 분리한다

한눈에 비교

기준	OLTP (운영 DB)	OLAP (분석 DB)
목적	주문/결제 등 실시간 트랜잭션	매출·전환율 같은 분석/리포팅
쿼리	짧고 많은 read/insert/update/delete	길고 복잡한 집계 read 위주
동시성	수백~수천 사용자 동시 쓰기	분석가 소수, 대량 스캔
스키마	정규화(normalized)	비정규화·차원 모델(star schema)
최적화	쓰기·정합성·복구	읽기·집계 속도
예시	MongoDB, MySQL 운영 인스턴스	Amazon Redshift, BigQuery

• OLAP의 사전 집계(pre-aggregation)는 강력해서, 같은 질문에 대해 OLTP 대비 극히 일부 시간(자료에 따라 ~0.1% 수준)만에 답하기도 한다

OLAP의 대표 동작 3가지

• Roll-up(consolidation): 상세 데이터를 요약으로 집계 (일별 → 월별)
• Drill-down: 요약에서 상세로 파고들기 (월별 → 일별 → 사용자별)
• Slice & dice: 특정 단면을 잘라 다른 각도로 보기 (지역×상품×기간)

데이터 마트와의 관계

• 데이터 마트는 전형적인 OLAP 계층의 산출물이다 — OLTP 원본을 가공해 분석에 맞게 비정규화한 테이블
• “운영 DB에 직접 쿼리하니 120초+ 걸린다”는 문제는 결국 OLTP에 OLAP 작업을 시킨 것이 원인이고, 분리(=마트)가 해법이다

참고 문서

• https://en.wikipedia.org/wiki/Online_transaction_processing
• https://en.wikipedia.org/wiki/Online_analytical_processing