MCC (Multiversion Concurrency Control)

이번 포스팅에서는 MVCC라는 단어에 대한 개념을 정리해보려고 한다.

MCC는 Multiversion Concurrency Control로 MVCC라고도 한다. 단어에서도 어림짐작 할 수 있듯이 여러 버전을 동시에 제어하는 것이다.

예시에 보았듯이, MCC 또는 MVCC는 DBMS에서 동시에 들어오는 요청을 제어 할 수 있도록 사용하는 일반적인 방식이다. 사실 동시 제어를 가장 간단하게 하는 방법은 쓰기 작업이 끝날때까지 대기하고 이후 읽는 것인데 이 방법은 사용자를 오랫동안 기다리게 할 수 있다.

때문에 MCC는 각 요청 마다 동일한 데이터지만 버전이 다른 스냅샷(해당 시점의 데이터)를 가진 뒤, 스냅샷의 데이터가 수정되면 또 다른 버전을 만들고 이전 버전은 주기적으로 삭제*한다. 때문에 읽고 있는 스냅샷이 동시에 다른 요청에 의해 수정되더라도 같은 값을 유지 할 수 있다.

*오래된 버전은 내부 프로세스가 주기적으로 삭제한다.

(참고로 MCC는 Lock이 불필요하다. 그렇지만 Oracle과 같은 DBMS의 MCC는 Lock을 사용하여 구현한다.)

간단한 예시를 확인하면 다음과 같다.

Time	Object 1	Object 2
0	"Foo" by T0	"Bar" by T0
1	"Hello" by T1

현재 Time이 1이라고 했을 때 가정하자. Time 1인 시점에서 위의 테이블을 보면 Time이 0일 때 Obj 1과 Obj 2에 값이 쓰이고 Time이 1일 때 Obj1만 쓰인다.

시간 순으로 진행된다면 Obj 1은 Time 1에서 Obj 1에 쓴 값(Hello)로 변경될 것이다.

그렇다면 다음 상황을 확인해보자.

Time	Object 1	Object 2	Object 3
0	"Foo" by T0	"Bar" by T0
1	"Hello" by T1
2		(deleted) by T3	"Foo-Bar" by T3

Time 2에서 Obj 2를 오랫동안 읽고 있을 때, Time 3 시점에서 Obj 2를 지우고 Obj 3을 추가한다고 가정해보자. Time 3이 동작할 때 Time 2와는 시간 때는 다르지만 읽고 있는 스냅샷은 같다. 그런데 Time 3에서 Time 2에서 읽고 있는 Obj 2와 Obj 3에 영향을 줄 때 MCC에 의해서 Time 3에 의해 수정된 버전이 최신으로 되면서 Time 2에서 읽고 있던 이전 버전의 스냅샷이 최신으로 변경된다. 때문에 위의 테이블처럼 된다.

그림 1. MCC Update

그러면 실제 데이터베이스에서는 어떻게 MCC를 구현하는지 알아보도록 하자. 위의 그림 1은 PostgreSQL의 업데이트 할 때의 과정이다. 각 사용자(Alice, Bob)의 동작 순서를 보면 알 수 있듯이 트랜젝션이 완료가 이루어지지 않은 상태에서는 요청은 Isolation 되기 때문에 서로의 요청에게 영향을 주지 않는다. 그런데 업데이트 작업을 수행한 Bob의 트랜젝션이 완료된 이후에는 Alice와 Bob의 값이 동일하다는 것을 확인 할 수 있다.