OLTP VS OLAP 기본비교

OLTP와 OLAP는 일종의 데이터 처리 방식이다.

OLTP / OLAP를 이야기하면 자연스레 ROW 지향 데이터 베이스/ Column지향 데이터 베이스가 언급된다.

즉 각 데이터 처리방식에 맞는 특성을 지닌 데이터 베이스를 활용해야 한다는 것이다.

Row 지향 / Column 지향 데이터 베이스에 대해서도 추후 정리할 예정이다.

OLTP

서비스는 색인을 사용해 일부 키에 대한 레코드를 찾고, 레코드는 사용자 입력을 기반으로 삽입되거나 갱신된다.

이런 애플리케이션은 대화식이기 때문에 이를 온라인 트랜잭션 처리 즉 OLTP라고 부른다.

트랜잭션은 그때그때 키에 해당하는 적은수의 레코드를 반환한다.

OLTP시스템은 실제 서비스 운영에 이용되므로, 높은 가용성과 낮은 지연시간의 트랜잭션 처리를 기대한다.

이런 상황에서 대량의 데이터를 불러오는 분석질의는 OLTP의 성능을 저하한다.

OLTP는 로우지향방식으로 데이터를 배치한다. 테이블에서 한 로우의 모든 값은 서로 인접하게 저장된다. 이점은 문서 데이터 베이스와 유사하다.

 

OLAP

최근 데이터 베이스를 분석용으로도 많이 사용하지 시작했다. 분석은 트랜잭션과는 접근 패턴이 매우 다르다.

분석시에는 많은 레코드를 한번에 집계해온다.

분석 질의는 원시 데이터를 반환하는 것이 아니라 많은 수의 레코드를 스캔해서 레코드당 일부 칼럼만 읽어 집계통계를 계산해야 한다.

이러한 데이터베이스 사용패턴을 온라인 분석처리 즉 OLAP라고 부른다.

 

OLAP에서 사용되는 칼럼지향 방식은 모든 값을 하나의 로우에 저장하지 않는다. 각 칼럼별로 모든 값을 함께 저장한다. 각 칼럼을 개별 파일에 저장하면 질의에 사용되는 칼럼만 읽고 구분 분석하면 된다.

 

또한 칼럼지향 저장소는 대개 압축에 적합해서 디스크 처리량을 줄일 수 있다.

가장 효과적인 기법으로 비트맵부화하 방법으로 비트맵 색인을 활용한다.

중복된 칼럼값들 내에서 n개의 고유값을 가진 칼럼을 가져와서 개별 비트맵으로 변환할 수 있다.

이러한 압축을 더 효율적으로 하기 위해 정렬키를 설정한다. 이러한 정렬 순서는 로우 지향 저장소에서의 색인과 비슷한 개념이다.

그러나 이러한 작업들은 모두 읽기에 최적화되어있고, 쓰기에 적합하지 않다. 이러한 해결책으로 이미 언급된 LSM트리색인을 활용할 수 잇다.

LSM 트리 색인에 대해서는 블로그에 정리해 두었으니 참고(링크)

 

 

데이터웨어하우스

OLAP데이터 처리 방식의 필요성에 대응해 등장한 데이터웨어하우스는 분석가들이 OLTP에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터 베이스이다.

운영 데이터 베이스로는 OLTP 즉 트랜잭션 처리에 용이 하도록 로우 지향 저장소를 활용하게 되고 대표적으로 my sql, postgresql 이다.
분석용 데이터 베이스인 dw는 칼럼 지향 저장소로써 OLAP 처리에 용이해야 하고 이를 위해 다양한 데이터 베이스를 활용한다.
이와 관련해서는 클라우드 데이터 웨어하우스 서버를 활용하던지 빅 데이터 분산 처리 엔진에 데이터 웨어하우스 서버를 구축해서 활용하기도 한다.

1. MPP데이터베이스 : 완성한 비정규화 테이블의 고속 집계에 적합. 즉 SQL로 집계화/ 조회 하는 업무가 대부분일 때 적절하다,그러나 확장성 및 유연성에는 분산 시스템이 유리하다. 대량의 텍스트 처리나 데이터 처리를 프로그래밍하거나, NoSQL 데이터베이스에 저장된 데이터를 집계하고 싶은 경우가 이런 경우이다.

2. Hive : 데이터 양에 좌우되지 않는 쿼리 엔진이다. 안전성이 장점이다.

3. Presto : 속도 중시 & 대화형 쿼리엔진, 모든 데이터를 SQL로 집계하기 위한 중심적인 존재. 그러나 대화식 쿼리의 실행에 특화되어 있으므로 텍스트 처리 중심의 프로세스와 데이터 구조화에는 적합하지 않다.

4. Spark : 분산시스템을 사용한 프로그래밍 환경. ETL프로세스부터 SQL에 이르기까지의 일련의 흐름을 하나의 데이터 파이프라인으로 기술할 수 있다는 장점.