[DE] OLTP vs OLAP

왜 분석용 DB를 따로 만들어야 하지?

 

이 질문에 대한 답이 바로 OLTP와 OLAP의 차이다.

 

OLTP - 서비스를 위한 DB

• OLTP(Online Transaction Processing)는 우리가 개발할 때 일반적으로 사용하는 DB
• MySQL, PostgreSQL

* 대표적인 OLTP 질문들
- 주문 #1234의 현재 상태는?
- 김철수의 장바구니에 상품 추가

• 행(Row) 단위로 데이터를 읽고 쓴다.
• 정규화가 잘 되어 있다.
• 소량의 데이터를 빠르게 처리한다.
• 실시간 읽기/쓰기가 많다.

 

OLAP - 분석을 위한 DB

• OLAP(Online Analytical Processing)는 분석 전용 DB
• BigQuery, Snowflake, Redshift

* 대표적인 OLAP 질문들
- 지난 3개월 지역별 매출 합계
- 상품 카테고리별 재구매율
- 요일별 평균 주문 금액 추이

• 열(Column) 단위로 데이터를 읽는다.
• 비정규화 되어 있다.
• 수백만~수억 건을 한 번에 집계한다.
• 주로 배치로 데이터를 적재한다.

 

왜 둘을 분리해야 하나

• 운영 DB에서 직접 분석 쿼리를 날리면 어떻게 될까?

-- 운영 DB에서 이 쿼리를 실행하면 테이블 풀스캔이 발생
SELECT region, SUM(amount)
FROM orders
JOIN customers ON orders.customer_id = customers.id
JOIN products ON orders.product_id = products.id
WHERE created_at >= '2024-01-01'
GROUP BY region;

• 수백만 건의 주문 데이터를 전부 읽으면서 DB에 엄청난 부하가 걸린다.
• 결과적으로 서비스 응답이 느려지거나 최악의 경우 장애로 이어진다.

 

컬럼 기반 저장이 분석에 유리한 이유

• OLAP DB가 분석에 빠른 핵심 이유 중 하나는 컬럼 기반 저장 방식이다.

행 기반 (OLTP)
┌────┬──────┬────────┬────────────┐
│ id │ name │ amount │ created_at │  ← 행 전체를 같이 저장
├────┼──────┼────────┼────────────┤
│  1 │ 김철수│  50000 │ 2024-01-01 │
│  2 │ 이영희│  30000 │ 2024-01-02 │
│  3 │ 박민수│  80000 │ 2024-01-03 │
└────┴──────┴────────┴────────────┘

컬럼 기반 (OLAP)
[id]          → 1, 2, 3, ...
[name]        → 김철수, 이영희, 박민수, ...
[amount]      → 50000, 30000, 80000, ...  ← amount만 읽으면 됨
[created_at]  → 2024-01-01, ...

• SUM(amount)를 계산할 때 행 기반은 모든 행을 읽어야 하지만, 컬럼 기반은 amount 열만 읽으면 된다.

 

데이터가 흐르는 방향

• 데이터 엔지니어링 핵심 흐름

[OLTP: MySQL / PostgreSQL]
        ↓
   ETL 파이프라인 (Airflow)   ← 데이터 엔지니어가 만드는 구간
        ↓
[OLAP: BigQuery / Snowflake]
        ↓
[대시보드: Tableau / Looker]

• OLTP에서 OLAP으로 데이터를 옮기는 구간
• 서비스 DB의 데이터를 분석에 적합한 형태로 변환해서 웨어하우스에 적재하는 것