📒

지난 시간에 lock과 lock-based concurrency control에 대해서 알아보았습니다.

lock을 기반으로 concurrency control을 구현하고자 하였는데 lock을 사용하기만 해서는 deadlock현상이 발생하였습니다.

그래서 최초의 unlock operation 전까지는 locking operation만 사용하는 2PL protocol을 적용한 lock-based concurrency control을 구현하게 됩니다.

2PL protocol에는 conservative 2PL, strict 2PL, strong strict 2PL이 있었습니다.

하지만 2PL protocol을 적용한 lock-based concurrency control은 서로 다른 트랜잭션이 같은 데이터에 접근할 때 read-read 작업만 허용하기 때문에

전체 DB 처리량이 낮아져서 이를 해결하기 위해 MVCC를 개발하게 되었다고 지난 포스팅에서 알아보았습니다.

오늘은 MVCC에 대해서 알아보겠습니다.

✔️MVCC

MVCC도 lock을 사용합니다.

하지만 2PL protocol에서 read-lock과 write-lock의 관계는 다음과 같았습니다.

	read-lock	write-lock
read-lock	O	X
write-lock	X	X

MVCC에서 read-lock과 write-lock의 관계는 다음과 같습니다.

	read-lock	write-lock
read-lock	O	O
write-lock	O	X

같은 데이터에 대해서 서로 다른 트랜잭션이 write-write 하는 경우에만 block되고 나머지 경우에는 허용됩니다. 따라서 동시에 처리할 수 있는 트랜잭션이 2PL lock-based concurrency control보다 높습니다.

예제를 들어 MVCC를 설명해 보겠습니다.

x=10

tx1. x를 읽는다.

A. read(x)

tx2. x를 50으로 바꾼다.

A. write-lock(x)
B. write(x=50)

다음과 같은 schedule이 있습니다.

write-lock(tx2,x) - write(tx2,x=50) - read(tx1,x) - commit2 - unlock(x)

tx2가 x에 대한 쓰기 작업을 하기 위해 write-lock을 취득합니다. 그리고 x=50 쓰기 작업을 합니다.

MVCC는 snapshot으로 데이터 변경 이력을 관리합니다.

tx2가 작업한 x=50은 바로 디스크에 저장하는 것이 아닌, 이 변화를 snapshot으로 가지고 있습니다.

그리고 tx1이 x데이터를 읽습니다. 여기서 중요한 특징이 있는데 MVCC는 commit된 데이터만 읽는다는 것입니다.

MVCC가 적용되면 read할 때는 기본적으로 락 없이 동작합니다.

tx2가 쓰기 작업을 한 것이 디스크에 적용된 것이 아닙니다. 그래서 x=10은 commit된 데이터이기 때문에 x=10을 읽은 것입니다.

그 후에 tx2가 commit을 하게 되면서 tx2에서 작업한 x=50이 디스크에 저장됩니다. 그리고 x에 대한 lock을 반환합니다.

lock을 취득하고 반환하는 작업은 RDBMS가 해주는 것입니다. 그리고 앞으로의 예제에서 lock을 취득하거나 반환하는 operation은 schedule상에 적지 않도록 하겠습니다.

그리고 commit한 후에 lock을 반환하는 이유는 recoverability를 위해서 입니다.

---

recoverability 포스팅에도 소개되어 있지만,

recoverable schedule은 commit되지 않은 txA가 write한 데이터에 대해 txB가 read를 했다면 txA가 종료되기 전까지 txB도 종료하지 않는 schedule입니다.

recoverable schedule 중 더 엄격한 schedule이 있습니다.

cascadeless schedule은 그 어떤 tx도 commit되지 않은 tx가 write한 데이터는 read하지 않는 schedule입니다.
commit한 데이터만 읽습니다.

더 엄격한 strict schedule도 있습니다.

strict schedule은 그 어떤 tx도 commit되지 않은 tx가 write한 데이터는 read하지도 write하지도 않는 schedule입니다.
commit한 데이터에 대해서만 읽기, 쓰기 작업을 합니다.

이걸 보면 lock을 commit한 후에만 lock을 반환하는 이유를 알 수 있습니다.

---

📌isolation level에 따른 MVCC 동작

다시 돌아와서,

이렇게 두 트랜잭션이 종료되었습니다. 그런데 만약이 이 시점에서 tx1이 x를 한번 더 읽는 read작업이 있다고 가정해봅시다.

그러니까 tx1이 x를 두 번 읽는다고 가정하는 것입니다.

그러면 마지막 read(tx1, x)는 어떤 값을 가져오게 될까요?

이건 트랜잭션 isolation level에 따라 결과가 달라집니다.

👉read uncommitted

MVCC는 commit된 데이터를 읽습니다. read uncommitted level에서는 보통 MVCC가 적용되지 않습니다.

MySQL에서는 MVCC가 적용되는 isolation level은 read committed와 repeatable read입니다.
PostgreSQL에서는 read uncommitted level이어도 read committed level처럼 동작합니다.

👉read committed

만약 tx1의 isolation level이 read commited라면 read하는 시간을 기준으로 가장 최근에 commit된 데이터를 읽어오기 때문에 commit된 x=50을 읽어올 것입니다.

MySQL, PostgreSQL 둘 다 이렇게 read commited에서 이렇게 동작합니다.

👉repeatable read

만약 tx1의 isolatio level이 repeatable read라면 트랜잭션 시작 시간 기준으로 가장 최근에 commit된 데이터를 읽기 때문에 tx1 시작 전에 commit된 x=10을 그대로 다시 읽어올 것입니다.

MySQL, PostgreSQL 둘 다 이렇게 repeatable read에서 이렇게 동작합니다.

repeatable read가 동작하는 방식은 RDBMS마다 다를 수도 있습니다. 설명은 트랜잭션 시작 시간 기준으로 설명하였지만,

어떤 RDBMS는 트랜잭션에서 최초의 read가 발생한 시점을 기준으로 할 수도 있고, 그 트랜잭션에서 read든 write든 최초의 operation이 발생한 시점을 기준으로 할 수도 있습니다.

따라서 사용하는 RDBMS의 매뉴얼을 확인해보셔야 합니다.

📌정리

MVCC는 트랜잭션에서 데이터를 읽을 때 특정 시점을 기준으로 가장 최근에 commit된 데이터를 읽습니다.

특정 시점은 isolation level에 따라 결정됩니다.

서로 다른 트랜잭션의 같은 데이터에 대한 read-write 작업은 서로 block하지 않습니다.

또한 데이터 변화 이력을 관리하기 때문에 추가적인 저장공간을 사용합니다. 데이터가 변화됐다고 바로 디스크에 쓰는 것이 아닌 변화된 이력으로 가지고 있다가 commit하면 그 변화된 내용을 디스크에 씁니다.

요즘 RDBMS는 대부분 MVCC를 사용해서 RDBMS를 구현합니다.

추가로 MySQL에서는 특정 시점 기준으로 가장 최근에 commit된 데이터를 읽는 것을 consistent read라고 합니다.

다음 포스팅에서는 발생할 수 있는 이상 현상에 대해서 MVCC를 적용한 RDBMS마다 어떻게 해결하는지, serializable level에서는 어떻게 동작하는 지에 대해서 알아보겠습니다.