MVCC (Multi-Version Concurrency Control) 이해하기

데이터베이스를 공부하다 보면 동시성 제어에서 비관적락과 낙관적 락 말고도 MVCC (Multi-Version Concurrency Control) 라는 개념을 접하게 됩니다. PostgreSQL, MySQL, Oracle 같은 대부분의 현대적인 RDBMS는 MVCC 기반 동시성 제어를 사용하고 있습니다.

오늘은 MVCC가 정확히 뭔지, Lock 방식과 무엇이 다른지, 내부 동작 원리에 대해서도 학습해 보았습니다. 대신 기준은 PostgreSQL 로 학습하였습니다. 각 DB  마다 MVCC 기술의 방식이 제 예시를 보시고 MYSQL도 저렇게 동작하구나 생각하시면 안 됩니다. 큰 틀에서 목표와 개념은 같지만 그걸 구현한 방식은 DB 마다 각각 다릅니다.

 

 

 

1. MVCC란 무엇인가

MVCC (Multi-Version Concurrency Control) 는 여러 트랜잭션이 동시에 데이터를 읽고 수정할 수 있도록 하기 위한 동시성 제어 방식입니다.

핵심 아이디어는 매우 단순합니다.

 

데이터를 수정할 때 기존 데이터를 덮어쓰지 않고 새로운 버전을 생성한다.

 

전통적인 방식에서는 하나의 데이터는 하나의 값만 존재합니다.

row(id=1)
value = 10

 

하지만 MVCC에서는 하나의 데이터가 여러 버전을 가질 수 있습니다.

row(id=1)

version1 → value = 10
version2 → value = 20
version3 → value = 30

 

각 트랜잭션은 자신이 볼 수 있는 버전만 읽게 됩니다.

이 구조 덕분에 여러 트랜잭션이 동시에 데이터를 읽고 수정하더라도 서로 충돌하지 않고 동작할 수 있습니다.

 

 

 

2. 왜 MVCC가 필요할까

데이터베이스에서 가장 흔하게 발생하는 문제는 읽기와 쓰기의 충돌입니다.

예를 들어 다음 상황을 생각해보겠습니다.

Transaction A

SELECT balance FROM account WHERE id = 1; // Shared Lock 잡음

 

Transaction B

UPDATE account SET balance = 200 WHERE id = 1; //Exclusive Lock 잡음

 

Transaction A는 id 가 1인  row 의 balance 를 읽으려고 하고 있고, Transaction B 는  id 가 1인  row 의 balance 값을 200으로 수정하려고 합니다. 

 

전통적인 Lock 기반 DB에서는 이런 문제가 발생합니다.

Transaction A가 데이터를 읽으면 Shared Lock을 잡습니다.
Transaction B는 데이터를 수정하려면 Exclusive Lock이 필요합니다.

 

하지만 Shared Lock과 Exclusive Lock은 서로 충돌합니다. 그래서 Transaction B는 대기 상태에 들어갑니다.

"읽기 → 쓰기 대기 발생"

 

이 구조에서는 트랜잭션이 많아질수록 Lock 대기와 성능 저하가 발생하게 됩니다.

MVCC는 이 문제를 버전 관리 방식으로 해결합니다.
예를 들어 다음 상황을 보겠습니다.

초기 상태

balance = 100

 

각각의 트랜잭션 시작

Transaction A 시작
balance = 100 읽음

Transaction B
balance = 200 업데이트

 

DB 내부

version1 balance = 100
version2 balance = 200

 

이렇게 되면 Transaction A는 version1을 읽습니다. 그리고 독립되게 Transaction B는 version2를 사용합니다.

 

결과적으로

Transaction A → 100
Transaction B → 200

읽기와 쓰기가 서로 막지 않게 됩니다.

 

 

 

 

3. MVCC 내부 동작 구조

대부분의 MVCC 데이터베이스는 각 row에 트랜잭션 메타데이터를 저장합니다.
PostgreSQL을 예로 들면 다음과 같은 구조를 가집니다.

row
 ├ xmin (생성 트랜잭션 ID)
 ├ xmax (삭제 트랜잭션 ID)
 └ data

xmin 은 이 row를 생성한 트랜잭션 그리고 xmax = 이 row를 삭제한 트랜잭션을 의미합니다.

 

예를 들어 아래 같은 이미지처럼 타임라인 순으로 연산을 진행한다고 하겠습니다.

 

 

1️⃣ 첫 번째 트랜잭션 — 데이터 생성

왼쪽에서 첫 번째 트랜잭션이 시작됩니다.

BEGIN
INSERT INTO numbers (1)
INSERT INTO numbers (2)
COMMIT

이 시점에서 데이터베이스에는 두 개의 row가 생성됩니다.

 

MVCC에서는 row에 다음과 같은 메타데이터가 기록됩니다.

row(value=1)
xmin = cur_tx1
xmax = null

row(value=2)
xmin = cur_tx1
xmax = null

cur_tx1 이 각각의 row를 생성했으므로 각각의 데이터의 xmin 값은 cur_ tx1입니다.

 

 

 

2️⃣ 두 번째 트랜잭션 — Snapshot 생성

오른쪽에서 새로운 트랜잭션이 시작됩니다.

BEGIN

 

이 순간 데이터베이스는 snapshot을 생성합니다.

Snapshot은 간단히 말하면 "트랜잭션이 시작된 시점의 데이터 상태" 입니다.
이 snapshot에는 다음 정보가 포함됩니다.

• 현재 트랜잭션 ID
• 활성 트랜잭션 목록
• commit 된 트랜잭션

이 snapshot 기준으로 어떤 row를 볼 수 있는지가 결정됩니다.

 

cur_trx2 가 BEGIN 되는 시점에는 cur_trx1이 커밋되지 않은 상태입니다. 따라서 cur_trx2 가 BEGIN 됐을 때 스냅샷은 value가 1인 row가 아무것도 없는 스냅샷이게 됩니다. 따라서 COMMIT 했을 때도 조회 결과가 0이 나오게 됩니다.

 

 

3️⃣ 세 번째 트랜잭션  SELECT 실행

cur_trx3 트랜잭션이 다음 쿼리를 실행합니다.

BEGIN
-- 다른 쿼리
SELECT * FROM numbers WHERE value = 1

 

cur_trx3 트랜잭션이 BEGIN 했을 시점에 스냅샷을 남기므로 cur_trx2 와 cur_trx1이 커밋된 시점입니다.

스냅샷의 row는 value가 1인 row 와 value가 2 인 row 2개가 존재하게 됩니다. 스냅샷의 cur_trx4의 내용은 반영되어 있지 않습니다.

따라서 이 시점에서는 삭제가 발생하지 않았기 때문에 value가 1인 row가 보입니다. 

 

trx3 트랜잭션의 snapshot에서는 DELETE 트랜잭션(tx4) 이 아직 존재하지 않는 것으로 보이기 때문입니다.
MVCC에서는 트랜잭션마다 서로 다른 "데이터 세계"를 보고 있습니다.(버저닝)

 

 

 

4️⃣ 네 번째 트랜잭션에서 DELETE 발생

왼쪽에서 새로운 트랜잭션이 시작됩니다.

BEGIN
DELETE FROM numbers WHERE value = 1
COMMIT

MVCC에서는 DELETE가 실제로 row를 지우지 않습니다.

대신 row에 xmax를 기록합니다.

즉 내부적으로 다음과 같이 됩니다.

row(value=1)
xmin = tx1
xmax = tx4

 

이 의미는 "tx4 이후에는 이 row가 보이지 않는다" 입니다.
하지만 중요한 점이 있습니다. 물리적으로는 row가 아직 존재합니다.

 

 

5️⃣ 다섯 번째 트랜잭션  SELECT 실행

이제 마지막 오른쪽 cur_trx5 트랜잭션을 보겠습니다. 새로운 트랜잭션은 새로운 snapshot을 생성합니다.
이 snapshot에서는 이미 DELETE가 반영되어 있습니다.

그래서 결과는 0 rows가 됩니다.

 

 

 

 

4. MVCC에서 SELECT는 어떻게 동작할까 (Snapshot Read)

MVCC에서는 트랜잭션이 시작될 때 snapshot이 생성됩니다.

예를 들어 Transaction A가 다음 시점에 시작했다고 가정해보겠습니다.

Transaction A 시작 (txid = 150)

 

이 트랜잭션은 다음 조건을 만족하는 row만 볼 수 있습니다.

xmin <= 150
xmax > 150 OR xmax = null

 

즉 Transaction A는 자신이 시작된 시점의 데이터 상태만 보게 됩니다.
그래서 같은 데이터라도 트랜잭션마다 다른 값을 볼 수 있습니다.

 

 

 

5. MVCC에서 UPDATE

MVCC에서 UPDATE 는 조금 특이하게 동작합니다. UPDATE가 발생하면 기존 row의 xmax가 설정되고, 새로운 row가 생성되면서 그 row의 xmin이 설정됩니다.
즉, UPDATE는 실제로는 “DELETE + INSERT”처럼 동작하게 됩니다.

 

 

1️⃣ UPDATE 전 상태

예를 들어 다음 row가 있다고 하다고 가정하겠습니다.

value = 10

 

내부 tuple 메타데이터는 이렇게 됩니다.

row version1
xmin = 100
xmax = null
value = 10

• xmin = 100 → 트랜잭션 100이 이 row를 생성
• xmax = null → 아직 삭제되지 않음

 

2️⃣ UPDATE 발생

이제 트랜잭션 200이 해당 ROW에 UPDATE를 실행하게 됩니다.

UPDATE numbers SET value = 20 WHERE value = 10;

 

이렇게 되면 기존 row의 값을 직접 수정하지 않고, 대신 내부적으로 이렇게 변하게 됩니다.

 

• 기존 row

row version1
xmin = 100
xmax = 200
value = 10

 

• 새로운 ROW 생성

row version2
xmin = 200
xmax = null
value = 20

 

즉, "old row → 삭제 표시", "new row → 새 버전" 을 갖게 됩니다.

 

만약 트랜잭션 100 과 트랜잭션 200 사이의 트랜잭션 150에서 다음과 같은 쿼리를 실행한다면,

xmin=100 → 보임
xmax=200 → 아직 미래

 

value 는 10이 되게 됩니다.

 

트랜잭션 300은 xmin=200 → 보이므로 value=20 을 보게 됩니다.

 

 

마무리

그림을 통해 살펴본 MVCC의 핵심은 다음 두 가지입니다.

1️⃣ 트랜잭션마다 서로 다른 Snapshot을 본다

Transaction A → 보임
Transaction B → 안 보임

 

2️⃣ DELETE는 실제 삭제가 아니다

MVCC에서 DELETE, UPDATE 는 실제로 row를 지우지 않습니다. 대신 같은 row라도 다른 버전을 보고 있습니다.

 

 

이를 통해 쓰기락이 걸린 ROW에서도 읽기가 가능해지고, 여러 트랜잭션이 한 ROW 에 경합하는 상황에서도 보다 조금더 성능 좋게 데이터를 질의할 수 있게 됩니다.