같은 관계형 데이터베이스라도 무엇에 쓰느냐에 따라 설계가 정반대로 간다. OLTP(Online Transaction Processing)는 업무가 실제로 일어나는 자리에서 짧은 트랜잭션을 많이 처리하고, OLAP(Online Analytical Processing)는 쌓인 데이터를 뒤져 집계한다. 하나의 시스템으로 둘 다 잘하기 어렵기 때문에, 대개 OLTP 에서 발생한 데이터를 OLAP 쪽으로 옮겨 놓고 분석한다.
| 항목 | OLTP | OLAP |
|---|---|---|
| 목적 | 거래 기록 · 상태 변경 | 집계 · 추이 분석 |
| 질의 형태 | 짧고 많다. 건별 조회와 갱신 | 길고 적다. 대량 스캔과 집계 |
| 접근 단위 | 행 하나 또는 몇 건 | 컬럼 전체, 수백만~수십억 행 |
| 스키마 | 정규화. 중복을 없앤다 | 비정규화. 스타 · 스노플레이크 스키마 |
| 저장 방식 | 행 지향 | 컬럼 지향이 유리 |
| 동시 사용자 | 많다 (수백~수만) | 적다 (분석가 · 대시보드) |
| 갱신 | 상시. 초당 수천 건 | 배치 적재가 기본. 갱신은 드물다 |
| 성능 지표 | 트랜잭션 처리량 · 응답 지연 | 스캔 처리량 · 질의 완료 시간 |
| 데이터 범위 | 최근 · 현행 상태 | 과거 이력 전체 |
| 대표 제품 | Oracle · PostgreSQL · MySQL | ClickHouse · Snowflake · BigQuery · Impala · Trino |
정규화 여부가 성격을 가장 잘 드러낸다. OLTP 는 같은 값을 두 곳에 두지 않으려 한다. 갱신할 자리가 하나여야 데이터가 어긋나지 않기 때문이다. OLAP 는 반대로 조인을 줄이려 값을 일부러 펼쳐 둔다. 어차피 갱신하지 않으므로 중복이 문제가 되지 않는다.
OLTP 는 한 행 전체를 한 번에 읽고 쓰므로 행을 붙여 저장하는 편이 유리하다. 주문 한 건을 조회할 때 그 행이 한 블록 안에 들어 있으면 디스크 접근이 한 번으로 끝난다.
OLAP 는 수억 행 중 서너 컬럼만 본다. 컬럼별로 모아 두면 필요한 컬럼만 읽으면 되고, 같은 컬럼의 값은 성질이 비슷해 압축이 잘 든다. Parquet · ORC 같은 파일 포맷과 컬럼 지향 DBMS 가 이 성질을 쓴다.
OLTP 가 무엇을 지키는 시스템인지는 결제 흐름에서 잘 드러난다.
여기서 지켜야 하는 것은 "재고는 차감됐는데 주문은 없는" 상태가 생기지 않는 것이다. 이것이 ACID 가 필요한 이유이고, OLAP 시스템이 잘하지 않는 일이다.
한편 이 주문 데이터가 하루치 매출 추이, 상품별 전환율, 이탈 구간 분석으로 쓰이는 순간부터는 OLAP 의 일이 된다. 같은 데이터를 OLTP DB 에서 직접 집계하면 운영 트랜잭션과 자원을 다투게 되므로, 보통 별도 저장소로 옮긴 뒤 분석한다.
둘을 한 시스템에서 처리하려는 시도를 HTAP(Hybrid Transactional/Analytical Processing)이라 부른다. 행 저장과 컬럼 저장을 함께 두고 같은 데이터를 두 형태로 유지하는 방식이 많다. 다만 쓰기 부하가 커지고 구조가 복잡해지므로, 분석 지연이 정말 문제가 되는지 먼저 확인하고 도입한다.
Iceberg · Delta Lake 같은 테이블 포맷이 나오면서 분석 저장소에도 행 단위 갱신과 스냅샷 격리가 들어왔다. 그래도 목표는 여전히 다르다. 테이블 포맷의 갱신은 "잘못 들어온 데이터를 고치기 위한 것" 이지, 초당 수천 건의 거래를 받기 위한 것이 아니다.