OLTP VS OLAP (feat. 트랜잭션 ACID 특성)

 

OLTP 란?

Online Transactional Processing 의 약자, 그렇다면 Transactional이란 무엇일까? 트랜잭션처리가 가능한 작업들을 말한다. 그런 작업에서는 데이터의 ACID 특성을 보장하는 것이 중요한데 다음의 예시를 통해 트랜잭션의ACID 특성에 대해 알아보자

 

트랜잭션은 여러개의 DB 명령들을 하나의 단위로 실행시키는 일종의 커멘드 패턴이라고 볼 수 있다. 

 

ACID 특성이란?

Atomicity 원자성 :

트랜잭션 내 여러 작업들은 하나의 작업처럼 동작한다. 하나라도 실패하면 전체가 다 실패한 결과를, 전체가 다 성공해야 트랜잭션이 성공한 결과를 내보내야 한다.

 

Consistency 일관성 : 

트랜잭션이 성공적으로 완료되면 일관적인 DB상태를 유지해야한다.

여기서 일관적인 DB상태란 무엇일까? 데이터가 제약조건들을 다 만족하면서 모순되지 않은 상태를 유지하고있는것을 말한다. 예를들어 내 계좌가 마이너스 잔액을 허용하지 않는다고 가정하면, 여기서 제약 조건은 "마이너스 잔액을 허용하지 않음"이 된다. 즉, 잔액은 0원 미만이 될수 없다. 만약 계좌 잔액이 200만원인데 결제 트랜잭션에서 400만원을 결제 한다면, 그 결제 트랜잭션은 제약조건을 위배하고 모순된 상황을 만들어 내므로 실패해야 할것이다.

 

Isolation 고립성 :

고립성은 동시 트랜잭션을 처리하는데 사용됨.

동일한 테이블의 데이터를 수정하는 두 개의 트랜잭션이 동시에 발생하면 문제가 발생할 수 있기 때문에 하나의 트랜잭션이 수행되는 동안 다른 트랜잭션을 끼어들지 못하는 특성을 말한다.

 

Durability 지속성 :

트랜잭션이 정상적으로 완료되었다면 이 트랜잭션으로 인한 결과는 영구적으로 보존 되야 하는 특성을 말한다.

 

쿠팡과 같은 예약구매 사이트에서 새로 출시한 아이폰을 사기 위해 로그인한다고 상상해 보자.

• 구매 가능 수량이 1개 남은 시점에서 동시에 2명의 유저가 동시에 결제를 한다고해도 1명의 유저만 결제를 성공해야 하고 나머지 1명은 결제를 실패해야 한다.(Isolation, 고립성)
• 사용자가 결제와 함께 전체 결제 프로세스를 모두 완료한 경우에만 주문이 성공한 것으로 간주되야 한다. 만약 프로세스 중 하나라도 실패하게 된다면 전체 결제 과정이 실패한것으로 생각하고 처음으로 되돌아 가야한다. (Atomicity, 원자성)
• 사용자가 아이폰의 예약 주문을 성공적으로 완료하면 웹사이트에서는 잔여 수량이 1개 줄어야 한다. 안줄고 그대로면 일관성이 없어진것으로 볼 수 있다. (Consistency, 일관성)
• 만약 사용자 트래픽 폭주로 인해 전자 상거래 웹 사이트가 다운 되더라도 그 전에 성공적으로 구입한 아이폰은 사용자가 소유하고 있어야 합니다. (Durability, 지속성)

 

OLTP 시스템은 이런 ACID 특성을 가진 트랜잭션 처리에 대한 요구사항이 있고, 그러한 요구사항을 처리하기 위한 과정인 것이다.

그래서 다음과 같은 경우에 OLTP를 고려 해 볼 수 있다.

• 데이터베이스의 데이터를 조회 작업 보다 삽입, 수정, 삭제하는 작업이 더 빈번하게 일어나는 경우
• ACID 속성이 관리하는 트랜잭션을 처리해야 하는 경우
• 밀리세컨드 단위로 매우 빠른 트랜잭션 처리가 필요한 경우

 

OLAP 란?

Online Analytical Processing

만약 회사 내 여러 서비스에서 생성된 데이터들을 전부 모아서 통계를 내야하는 업무를 맡았다고 해보자.

몇 테라 바이트 혹은 페타 바이트 급이 되는 많은 양의 데이터를 OLTP 데이터베이스에 넣고 직접 쿼리하는 것은 쿼리의 양과 쿼리의 복잡성으로 인해 효율적이지 않은 경우가 많다. 따라서 이 데이터를 많은 양의 데이터 분석을 효과적으로 할 수 있도록 지원해주는 다른 데이터베이스(= 데이터 웨어하우스)에 저장 한 후 데이터 통계를 내는 것이다. 이러한 프로세스를 OLAP라고 한다.

 

 

 

OLAP를 위한 데이터 웨어하우스는 설계부터 대용량의 데이터 조회에 특화된 구조로 설계 되어있다.

 

얼마전 회사에서 PoC를 진행했던 Snowflake 데이터 웨어하우스의 경우를 예로 들어보면 

Snowflake는 쿼리 성능을 위해서 마이크로 파티셔닝 기술과 데이터 클러스터링 기술이 융합되어 적용한다고 했다.

마이크로 파티셔닝 기술과 데이터 클러스터링에 대해서는 아직 자세하게 모르기 때문에 지금은 OLAP의 관점에서 이야기 해보면, Snowflake는 대용량의 데이터에서도 빠른 쿼리 속도를 보장하기 위해 테이블에 데이터를 추가하는 시점에 자동으로 실제 데이터를 파티셔닝하고 날짜 와 같은 정보로 미리 정렬을 한다고 한다. 그림을 보면 row가 여러개의 파티션으로 쪼개져있고, 컬럼 기반으로 데이터가 적재되어 있으며, 비슷한 날짜의 데이터들끼리 정렬되어 저장 되는 것을 확인 할 수 있다.

Snowflake 의 마이크로 파티셔닝, 자동 클러스터링

 

이런 일련의 과정이 데이터 삽입 시 마다 일어나므로 OLAP 서비스는 빈번하게 데이터의 추가 수정 삭제가 일어나는 시스템에는 맞지 않는다는 것을 느낄 수 있었다. RDB의 인덱스를 공부하면서 인덱스란 삽입 수정 성능을 포기하고 검색 성능을 높이는 거라는 말이 떠올랐다.

 

뿐만아니라 Snowflake의 테이블은 NOT NULL 옵션을 제외하고 Unique와 같은 Column Constraint를 설정을 해도 실제로는 테이블에 데이터가 중복으로 들어갈수도 있었다. 그래서 데이터의 일관성을 중요하게 관리해야 하는 시스템에는 맞지 않다는 생각이 들었다.

 

Snowflake supports defining and maintaining constraints, but does not enforce them, except for NOT NULL constraints, which are always enforced.

Overview of Constraints — Snowflake Documentation

 

그래서 OLAP 서비스는 수정 할 일이 거의 없는 데이터를 많이 쌓아두고 소수의 인원이 일마다 데이터를 조회하거나 집계하는 니즈에 특화된 서비스라고 말 할 수 있다.

 

만약 Snowflake가 대용량 데이터도 그렇게 빠르게 조회가 된다며? 그러니까 우리 서비스 DB도 Snowflake로 이전하자! 라고 생각다면, 그 전에 이전 하려는 서비스의 특성이 OLTP 서비스에 가까운지, OLAP 서비스에 가까운지 고려해 봐야 할것이다. 그리고 서비스가 OLTP에 가깝다면 쿼리 최적화 같은 방법을 먼저 생각해 보아야 할것이다.