OLTP와 OLAP (OLTP vs OLAP)
목차
- 왜 OLTP와 OLAP을 구분해야 하는가
- OLTP란
- OLAP이란
- OLTP와 OLAP 비교
- Row Store와 Column Store
- Data Warehouse, Data Lake, Lakehouse
- ETL과 ELT
- 분석 시스템으로 데이터를 넘기는 방식
- Druid 같은 실시간 OLAP 저장소는 어디에 맞는가
- 면접 포인트
- 참고 자료
왜 OLTP와 OLAP을 구분해야 하는가
많은 백엔드 면접에서 “서비스 DB와 분석 DB를 왜 분리하느냐”가 꼬리질문으로 이어집니다.
이때 핵심은 단순히 기술 이름을 나열하는 것이 아니라,
트랜잭션 처리와 분석 질의는 요구사항이 다르다는 점을 설명하는 것입니다.
예를 들어:
- 주문 생성, 결제 승인, 재고 차감은 OLTP 감각에 가깝습니다.
- 일별 매출 집계, 코호트 분석, 리텐션 대시보드는 OLAP 감각에 가깝습니다.
즉, 이 문서는
데이터베이스를 어떤 질의 패턴과 저장 구조로 운영할지를 설명합니다.
서비스 전체 설계에서 언제 분석 파이프라인이 필요한지는 분산 데이터 처리 (Distributed Data Processing) 문서와 같이 보면 더 자연스럽습니다.
OLTP란
OLTP(Online Transaction Processing) 는 서비스의 실시간 트랜잭션 처리에 최적화된 시스템을 말합니다.
대표 특징은 다음과 같습니다.
- 짧고 빈번한 요청
- row 단위 읽기/쓰기
- 강한 정합성과 트랜잭션이 중요
- 지연 시간이 짧아야 함
대표 예시는 다음과 같습니다.
- 회원 가입
- 주문 생성
- 결제 승인
- 재고 차감
OLTP 시스템을 설명할 때는 보통 다음 감각이 중요합니다.
- 핵심 목표: 정확한 상태 전이와 낮은 지연
- 잘 맞는 질의: PK lookup, 짧은 range query, 소수 row 수정
- 주의점: 무거운 집계와 전체 스캔을 같이 얹으면 본업 트랜잭션이 흔들릴 수 있음
즉, OLTP는
비즈니스 상태를 안전하게 바꾸는 시스템이라고 설명하는 편이 좋습니다.
OLAP이란
OLAP(Online Analytical Processing) 는 대규모 데이터를 읽고 집계하며 분석하는 시스템을 말합니다.
대표 특징은 다음과 같습니다.
- 많은 row를 읽는 질의
- 집계, group by, scan 중심
- 지연보다 분석 효율과 대량 처리량이 중요
- 실시간 트랜잭션보다 리포팅과 의사결정 지원이 중심
대표 예시는 다음과 같습니다.
- 일/주/월 매출 분석
- 사용자 행동 로그 집계
- 대시보드용 다차원 분석
- 추천/ML용 feature 집계
OLAP을 설명할 때 중요한 포인트는 다음과 같습니다.
- 핵심 목표: 대량 데이터에 대한 효율적인 읽기와 집계
- 잘 맞는 질의: 집계, scan, filter, group by, drill-down
- 주의점: OLTP처럼 자주 갱신되는 세밀한 트랜잭션 시스템과는 요구가 다름
즉, OLAP은
운영 트랜잭션을 처리하기 위한 DB가 아니라 분석과 리포팅을 위한 데이터 시스템입니다.
OLTP와 OLAP 비교
| 항목 | OLTP | OLAP |
|---|---|---|
| 주 목적 | 실시간 업무 처리 | 대규모 분석과 집계 |
| 대표 질의 | 짧은 lookup, insert, update | scan, join, aggregation |
| 데이터 범위 | 소수 row 중심 | 많은 row를 한 번에 읽음 |
| 중요 지표 | 낮은 지연, 정합성, 동시성 | 집계 성능, 대량 읽기 효율 |
| 저장 감각 | row 중심이 자연스러움 | columnar가 유리한 경우가 많음 |
| 예시 | 주문, 결제, 계정 | 대시보드, 리포트, 행동 분석 |
면접에서는
“OLTP는 서비스 DB, OLAP은 분석 DB” 정도로 끝내기보다,
왜 같은 DB에 다 넣으면 충돌이 생기는지까지 말하면 답변이 강해집니다.
예를 들어:
- OLTP는 짧은 요청과 락 경합에 민감함
- OLAP는 많은 데이터를 읽고 집계하므로 I/O와 CPU를 크게 씀
- 둘을 같은 시스템에 억지로 얹으면 핵심 서비스 트랜잭션이 흔들릴 수 있음
Row Store와 Column Store
OLTP와 OLAP 차이를 저장 구조까지 연결하면 답변이 더 좋아집니다.
| 항목 | Row Store | Column Store |
|---|---|---|
| 저장 단위 | 한 row의 컬럼들이 함께 저장 | 같은 컬럼 값들이 함께 저장 |
| 잘 맞는 경우 | 소수 row 조회, update | 집계, scan, 압축 |
| 장점 | 개별 row 읽기/쓰기 효율 | 필요한 컬럼만 읽기 쉬움, 압축 효율 |
| 주의점 | 대량 집계에서 비효율적일 수 있음 | 잦은 row 단위 갱신에는 불리할 수 있음 |
이 비교를 너무 기계적으로 외울 필요는 없지만,
다음 정도는 설명할 수 있으면 좋습니다.
- OLTP: 주문 한 건, 회원 한 명을 빠르게 읽고 수정하는 게 중요
- OLAP: 수백만 건에서
country,date,revenue같은 일부 컬럼만 읽어 집계하는 게 중요
그래서 OLAP 계열에서는 columnar 저장이 자주 등장합니다.
Data Warehouse, Data Lake, Lakehouse
분석 시스템을 말할 때 자주 같이 붙는 개념입니다.
| 개념 | 핵심 아이디어 | 면접에서의 설명 포인트 |
|---|---|---|
| Data Warehouse | 정제된 분석용 저장소 | 스키마와 SQL 분석 중심 |
| Data Lake | 다양한 원천 데이터를 원본 가깝게 저장 | 유연하지만 관리 규율이 중요 |
| Lakehouse | lake 유연성과 warehouse 관리성을 결합 | 파일 기반 분석 + 메타데이터/테이블 관리 |
좋은 답변은 이 셋을 경쟁 제품 이름으로만 설명하지 않고,
데이터를 얼마나 정제해서 저장하고, 어떤 질의 모델로 읽을 것인가의 차이로 설명하는 편입니다.
예를 들어:
- Warehouse: 정리된 분석 테이블에 SQL 질의
- Lake: 원본 이벤트와 중간 산출물을 넓게 저장
- Lakehouse: object storage 기반 데이터에 테이블 관리와 품질 규율을 추가
즉, 이 세 개념은
저장 위치보다 데이터 관리 방식과 분석 운영 모델의 차이로 보는 편이 좋습니다.
ETL과 ELT
분석 시스템으로 데이터를 옮길 때는 보통 ETL과 ELT가 같이 나옵니다.
| 방식 | 순서 | 잘 맞는 경우 |
|---|---|---|
| ETL | Extract → Transform → Load | 적재 전에 데이터 정제가 많이 필요할 때 |
| ELT | Extract → Load → Transform | 저장소/웨어하우스 안에서 변환을 유연하게 하고 싶을 때 |
면접에서는 둘 중 하나를 절대화하기보다 다음처럼 설명하면 좋습니다.
- ETL: 적재 전에 품질과 스키마를 강하게 통제
- ELT: 먼저 적재한 뒤 분석 플랫폼에서 유연하게 변환
워크로드와 조직의 데이터 운영 방식에 따라 둘 다 가능합니다.
분석 시스템으로 데이터를 넘기는 방식
서비스 DB에서 분석 시스템으로 데이터를 보내는 방식은 보통 다음과 같습니다.
- 배치 export
- CDC(Change Data Capture)
- 이벤트 스트림 적재
- 애플리케이션 단의 outbox 기반 전파
핵심은 OLTP 시스템이 본업을 망치지 않도록
분석용 읽기와 집계를 분리하는 것입니다.
보통 다음 구조가 많이 나옵니다.
- 서비스 DB에서 변경 발생
- CDC 또는 이벤트로 추출
- warehouse / lake / 실시간 분석 저장소로 적재
- BI, 대시보드, 모델 학습, 리포팅에서 사용
이 흐름은 분산 데이터 처리 (Distributed Data Processing) 문서와 직접 연결됩니다.
좋은 답변은 “배치로 옮깁니다”보다
정산처럼 약간 늦어도 되는 데이터인지, 실시간 대시보드처럼 freshness가 중요한지를 함께 말하는 편이 좋습니다.
Druid 같은 실시간 OLAP 저장소는 어디에 맞는가
Druid 같은 시스템은 OLAP 안에서도
낮은 지연의 집계와 slice-and-dice 분석에 초점을 둔 실시간 분석 저장소로 설명할 수 있습니다.1
예를 들어:
- 이벤트 로그를 실시간에 가깝게 적재하고
- 대시보드 질의를 빠르게 처리하고
- 사전 집계나 columnar 구조를 활용해 응답 시간을 낮추는 방식
면접에서는 Druid를 깊게 몰라도 다음 정도면 충분합니다.
- OLTP 대체재는 아님
- 전통적인 warehouse와도 결이 다를 수 있음
- 실시간에 가까운 OLAP 서빙 계층의 예시
즉, Druid는 이 문서에서는
OLAP 스펙트럼 안에서 실시간 분석에 더 치우친 예시 정도로 이해하면 충분합니다.
면접 포인트
- OLTP와 OLAP은 목적, 질의 패턴, 저장 구조가 다르므로 분리해서 설명하는 편이 좋습니다.
- OLTP는 정확한 상태 전이와 낮은 지연, OLAP는 대량 읽기와 집계 효율이 핵심입니다.
- row store와 column store 차이를 연결하면 답변 깊이가 좋아집니다.
- warehouse, lake, lakehouse는 제품명이 아니라 데이터 관리 방식의 차이로 설명하는 편이 좋습니다.
- 분석 시스템으로 데이터를 넘길 때는 CDC, 이벤트, 배치 적재 같은 경로를 함께 설명하면 실무 감각이 드러납니다.
- Druid 같은 시스템은 실시간 OLAP 예시로만 짚고, OLTP와 혼동하지 않는 것이 중요합니다.