Multi-Version Concurrency Control

스냅샷 격리(Snapshot Isolation)의 구현

1. Rollback Segment 기반 (Undo Log)

가장 대표적인 MVCC 구현 방식으로 Oracle과 MySQL(InnoDB)이 이 방식을 채택하고 있다.

동작 원리: 데이터 수정 시 기존 데이터를 별도의 Undo Log(또는 Rollback Segment) 영역에 복사해 둔다.
조회 방식: 다른 트랜잭션이 데이터를 조회할 때, 자신의 트랜잭션 ID보다 낮은 버전의 데이터를 Undo Log에서 찾아 시스템 상의 일관된 시점(Snapshot)을 재구성한다.
장점: 데이터 파일의 크기가 상대적으로 일정하게 유지된다.

주로 PostgreSQL이나 SQLite(WAL 모드)에서 사용하는 방식이다.

동작 원리: 기존 데이터를 직접 수정하지 않고, 새로운 버전의 행(Row)을 추가하거나 페이지 자체를 복사하여 수정본을 만든다.
특징: 한 레코드에 대해 여러 버전이 데이터 페이지 내에 공존한다.
문제점: 업데이트가 빈번할 경우 쓸모없게 된 옛 버전 데이터(Dead Tuples)가 쌓여 DB 크기가 비대해진다. 이를 해결하기 위해 VACUUM 작업이 필수적이다.

MVCC와 결합하여 사용되는 낙관적 동시성 제어 메커니즘이다.

동작 원리: 데이터를 읽을 때 락을 걸지 않고, 트랜잭션 종료 시점에 데이터가 변경되었는지 확인(Validation)하여 충돌이 없으면 커밋한다.
비교: MVCC는 ‘여러 버전’을 관리하는 것에 초점이 있고, OCC는 ‘충돌 확인 시점’을 뒤로 미루는 전략이다. Hekaton(SQL Server In-Memory OLTP) 엔진이 이 두 개념을 고도로 결합하여 사용한다.

단순한 로그 기록을 넘어 읽기/쓰기 성능을 분리하기 위해 사용된다.

동작 원리: 모든 변경 사항을 먼저 WAL 파일에 순차적으로 기록한다. 조회 쿼리는 데이터 파일과 WAL 파일을 동시에 참조하여 최신 스냅샷을 구성한다.
효과: 읽기 작업이 쓰기 작업을 차단하지 않고, 쓰기 작업 또한 읽기 작업을 차단하지 않는 비차단(Non-blocking) 읽기를 가능하게 한다.

트랜잭션이 시작되는 시점에 데이터베이스의 전체적인 ‘스냅샷’을 찍은 것처럼 동작

Non-Blocking Read: 읽기 작업이 쓰기 작업에 의해 차단되지 않고, 쓰기 작업 또한 읽기 작업에 의해 방해받지 않는다. 이는 동시성 성능을 비약적으로 높인다.
현상 방지:
- Dirty Read 방지: 커밋된 데이터만 스냅샷에 포함된다.
- Non-Repeatable Read 방지: 트랜잭션 내내 시작 시점의 동일한 스냅샷을 참조한다.
- Phantom Read 방지: (대부분의 구현에서) 스냅샷 시점 이후에 추가된 레코드는 보이지 않으므로 범위 조회 시에도 일관성을 유지한다.