데이터베이스는 다양한 격리 수준 설정을 제공합니다. 격리수준이란 데이터베이스가 데이터에 대한 연산을 수행할 때 따르는 룰입니다. 

Read Committed, Dirty Read와 같은 어려운 단어가 나오니 보다 쉬운 예시로 이해를 시도(?)해 봅시다. 

편의점에서 물품을 계산하는 대기열을 생각해 봅시다. 바쁜 시간대에 많은 손님이 계산을 시도한다면 매니져는 2대의 포스기로 계산을 동시 작업을 할 겁니다. 2대의 포스기에서 계산하는 내역들 사이에 의존성이 없다면 아무런 문제가 되지 않습니다. 2대의 포스기에서 2명의 매니져가 동시에 각각의 계산을 처리하면 됩니다. 

다만 이런 경우가 있을 수 있습니다. 2대의 포스기에서 계산을 하고 있는 2명의 손님이 같은 담배를 주문하는 경우를 생각해 봅시다. 각각의 포스기를 P0, P1 손님을 각각 G0, G1이라고 alias를 통해 지칭 하겠습니다. 또한 하나의 주문을 하나의 트랜잭션으로 생각해 봅시다.

P0에서 1초 먼저 G0의 계산을 시작하였고 G0은 맨솔 담배 5갑을 주문하였습니다. 그리고 G1은 1초 늦게 맨솔 담배 3갑을 주문하였습니다. 만약 편의점에서 충분한 맨솔담배를 보유하고 있다면 아무런 문제가 되지 않습니다. 그러나 시스템은 이러한 일말의 오류 가능성이 있다면 그 가능성은 반드시 현실화 됩니다. 따라서 데이터베이스는 이러한 경우를 처리하는 여러가지 시나리오를 가지고 있습니다. 그리고 그 시나리오는 여러가지 유형의 격리수준으로 구분됩니다.

1. P0, P1에서 주문을 동시에 진행하고 G0과 G1의 계산을 진행한다. G0의 주문이 조금 더 빨랐으므로 G0이 맨솔 5갑을 주문한 즉시(주문은 이루어 졌으나 아직 결제가 완료되지 않음.) G1에게 현재 재고 수량을 보여준다. G1은 재고가 없으니 구매를 하지 못하고 트랜잭션이 종료된다. 이 경우 크게 문제 될 것은 없으나 G1의 주문이 종료된 후, G0이 갑자기 마음이 바뀌어 주문을 취소하고 결제를 완료하지 않는 경우에는 G0과 G1의 주문을 모두 놓치게 되므로 편의점 점주는 상당히 unhappy 할 수 있다.

2. G1에게 G0의 트랜잭션이 종료되기 전 까지는 G0의 주문을 감안하지 않은 현재 재고 수량을 보여준다. 이 경우 G0이 주문을 완료했다면 G1은 구매를 하지 못하게 되고 결제가 완료된 상태라면 결제를 취소한 후 G1의 구매 수량을 반영하지 않아야 한다 (ROLLBACK). 이런 경우 G1의 입장이 상당히 sad해 질 수 있다.

3. 만약 G0이 맨솔 담배를 주문하기 시작하면 맨솔 담배를 구입하는 다른 모든 주문을 일시정지 한 후 G0의 주문이 완료되면 재개한다. 이런 경우 동시성이 떨어지며 편의점의 회전율을 저해하기 때문에 편의점 전체 시스템의 성능 부분에서 약간의 아쉬움이 있을 수 있다.


위와 같이 주문을 처리하는 여러가지 시나리오를 생각해 볼 수 있습니다. 데이터베이스는 이러한 장애 유발 케이스에 대한 여러가지 시나리오를 고려하여 설계 되었습니다. 
높은 동시성을 보장하면서 완벽한 무결성을 보장하는 방법은 현재까지는 없습니다. (양자컴퓨터가 상용화 된다면 가능할 지도 모르겠다는 희망을 가져 봅니다... ^^;)


가상화폐 거래소 시스템과 사진기반의 SNS 서비스 간에는 데이터의 양적인 부분에서는 별반 차이가 없을 수 있습니다. 그러나 데이터의 특성에는 어마어마한 차이가 있습니다. 전자는 데이터의 정합성, 무결성을 최우선적으로 고려하여야 하고 후자는 데이터 동시 처리량을 높이는 것을 우선으로 고려할 수도 있을 것입니다. 좋아요 수가 실제로는 99개 인데 잠시동안 98개로 보여지는 것은 용인 가능하다라고 판단할 수도 있기 때문이죠. 

격리 수준은 데이터베이스의 성능과 맞닿아 있습니다. 다루는 데이터의 성격에 맞는 알맞은 격리수준을 설정해야 합니다.


위의 예시로 드린 설명은 100% 맞는 설명은 아닙니다. 해당 포스트는 개발자가 아닌 분들에게 데이터 처리와 관련된 개념을 이해하는데 도움을 드리고자 작성한 글입니다. 글과 관련된 오류에 대한 피드백은 언제든지 환영합니다. 감사합니다.


데이터 개발은 헬로월드!