다중 버전 동시성 제어

3. 작동 방식

MVCC는 동시성 제어가 없을 때 발생할 수 있는 문제, 즉 다른 사람이 데이터베이스에 쓰는 동안 누군가 읽고 있다면, 읽는 사람이 반쯤 쓰여진 데이터 또는 일관성 없는 데이터를 볼 수 있는 문제를 해결한다. 예를 들어, 두 개의 은행 계좌 간에 송금을 할 때, 읽는 사람이 원래 계좌에서 돈이 인출된 시점과 대상 계좌에 입금되기 전 시점에 은행의 잔액을 읽으면, 은행에서 돈이 사라진 것처럼 보일 수 있다.

격리성은 데이터에 대한 동시 접근을 보장하는 속성으로, 동시성 제어 프로토콜을 통해 구현된다. 가장 간단한 방법은 모든 읽기 작업을 쓰기 작업이 완료될 때까지 기다리게 하는 읽기-쓰기 잠금 방식이지만, 잠금은 특히 긴 읽기 트랜잭션과 업데이트 트랜잭션 간에 자원 경합을 일으킨다.

MVCC는 각 데이터 항목의 여러 복사본을 유지함으로써 이 문제를 해결한다. 데이터베이스에 연결된 각 사용자는 특정 시점의 데이터베이스 ''스냅샷''을 보게 되며, 작성자가 변경한 내용은 트랜잭션이 커밋될 때까지 다른 사용자에게 표시되지 않는다.

MVCC 데이터베이스는 데이터를 업데이트할 때, 이전 데이터를 덮어쓰는 대신 새 버전을 생성한다. 따라서 여러 버전이 저장되며, 각 트랜잭션이 보는 버전은 구현된 격리 수준에 따라 다르다. MVCC에서 가장 일반적인 격리 수준은 스냅샷 격리이며, 트랜잭션 시작 시점의 데이터 상태를 관찰한다.

MVCC는 시점 일관성을 제공한다. 읽기 트랜잭션은 일반적으로 타임스탬프나 트랜잭션 ID를 사용하여 읽을 데이터베이스 상태를 결정하고, 해당 버전의 데이터를 읽는다. 따라서 읽기와 쓰기 트랜잭션은 잠금 없이 서로 격리된다. (일부 MVCC 데이터베이스(예: 오라클)에서는 잠금이 사용되기도 한다.) 쓰기는 새 버전을 만들고, 동시 읽기는 이전 버전에 접근한다.

MVCC는 사용되지 않고 더 이상 읽히지 않을 버전을 제거해야 하는 과제를 안고 있다. PostgreSQL은 [https://www.postgresql.org/docs/9.4/sql-vacuum.html VACUUM FREEZE] 프로세스를 통해 이 문제를 해결할 수 있다. 다른 데이터베이스는 저장 블록을 데이터 부분과 실행 취소 로그로 나누어 관리하기도 한다.

MVCC는 타임스탬프('''TS''')와 ''증가하는 트랜잭션 ID''를 사용하여 ''트랜잭션 일관성''을 달성한다. 객체의 각 버전에는 ''읽기 타임스탬프'' ('''RTS''')와 ''쓰기 타임스탬프'' ('''WTS''')가 있어, 트랜잭션('''T''')이 데이터베이스 객체('''P''')를 ''읽기'' 위해 대기할 필요가 없다. 특정 트랜잭션 '''T_i'''는 '''RTS'''('''T_i''')보다 먼저 나오는 객체의 가장 최근 버전을 읽을 수 있다.^[2]

트랜잭션 '''T_i'''가 객체 '''P'''에 ''쓰기''를 할 때, 다른 트랜잭션 '''T_k'''가 같은 객체에 대해 발생하면, '''RTS'''('''T_i''') < '''RTS'''('''T_k''')여야 ''쓰기 작업'' ('''WTS''')이 성공한다. 즉, 읽기 타임스탬프 ('''RTS''')가 더 이른 다른 진행 중인 트랜잭션이 있으면 ''쓰기''를 완료할 수 없다.^[2]

객체 ('''P''')에 ''쓰기''를 할 때, 트랜잭션의 ''타임스탬프'' ('''TS''')가 객체의 현재 읽기 타임스탬프보다 이르면 ('''TS'''('''T_i''') < '''RTS'''('''P''')), 트랜잭션은 중단되고 다시 시작된다. 그렇지 않으면, '''T_i'''는 객체 '''P'''의 새 버전을 생성하고 새 버전의 읽기/쓰기 타임스탬프 '''TS'''를 '''TS'''('''T_i''')로 설정한다.^[2]

MVCC는 쓰기 처리(트랜잭션)가 진행되는 동안 다른 사용자가 읽기 접근을 시도했을 때, 쓰기 직전의 상태(스냅샷)를 반환한다. 즉, 쓰기 중에도 읽기가 가능하며, 읽기 중에도 쓰기가 가능하다.

MVCC에서 가용성을 확보하려면 모든 처리 순서를 확실하게 기록해야 하며, 이를 위해 타임스탬프나 트랜잭션 ID 등을 사용하여 모든 갱신 처리가 관리된다.

MVCC는 SQL 규격(SQL92)에서 정해진 4가지 종류의 트랜잭션 격리 수준 중 '''Read Committed''' (커밋된 데이터는 항상 읽음)에 해당한다.

3. 1. 트랜잭션 관리

3. 2. 트랜잭션 격리 수준

4. 구현

MVCC는 동시성 제어가 없을 때 발생할 수 있는 문제, 즉 다른 사람이 데이터베이스에 쓰는 동안 읽는 사람이 불완전하거나 일관성 없는 데이터를 보는 문제를 해결한다. 예를 들어, 두 은행 계좌 간 송금 시 읽는 사람이 특정 시점에 잔액을 조회하면 돈이 사라진 것처럼 보일 수 있다. 격리성은 데이터에 대한 동시 접근을 보장하는 속성이며, 동시성 제어 프로토콜을 통해 구현된다.

가장 간단한 구현 방법은 모든 읽기 작업을 쓰기 작업이 완료될 때까지 기다리게 하는 것이다. 이는 읽기-쓰기 잠금으로 알려져 있다. 그러나 잠금은 특히 긴 읽기 트랜잭션과 업데이트 트랜잭션 간에 자원 경합을 발생시키는 것으로 알려져 있다.

MVCC는 각 데이터 항목의 여러 버전을 유지함으로써 이 문제를 해결한다. 각 사용자는 특정 시점의 데이터베이스 ''스냅샷''을 보게 되며, 작성자가 변경한 내용은 변경이 완료될 때까지(트랜잭션이 커밋될 때까지) 다른 사용자에게 표시되지 않는다.

데이터를 업데이트할 때, MVCC 데이터베이스는 원래의 데이터 항목을 새 데이터로 덮어쓰는 대신, 데이터 항목의 새 버전을 생성한다. 따라서 여러 버전이 저장되며, 각 트랜잭션이 보는 버전은 구현된 격리 수준에 따라 달라진다. MVCC로 구현되는 가장 일반적인 격리 수준은 스냅샷 격리이다. 스냅샷 격리를 사용하면 트랜잭션은 트랜잭션이 시작될 때의 데이터 상태를 관찰한다.

MVCC는 시점 일관성 보기를 제공한다. 읽기 트랜잭션은 일반적으로 타임스탬프 또는 트랜잭션 ID를 사용하여 읽을 DB의 상태를 결정하고, 해당 버전의 데이터를 읽는다. 따라서 읽기 및 쓰기 트랜잭션은 잠금 없이 서로 격리된다. 그러나 잠금이 불필요함에도 불구하고, 일부 MVCC 데이터베이스(예: 오라클)에서는 사용되기도 한다. 쓰기는 새 버전을 만들고, 동시 읽기는 이전 버전에 접근한다.

MVCC는 사용되지 않고 더 이상 읽히지 않을 버전을 제거해야 하는 과제를 제시한다. 어떤 경우에는 쓸모없는 버전을 주기적으로 스캔하여 삭제하는 프로세스가 구현된다. PostgreSQL은 이 접근 방식을 [https://www.postgresql.org/docs/9.4/sql-vacuum.html VACUUM FREEZE] 프로세스와 함께 사용할 수 있다. 다른 데이터베이스는 저장 블록을 데이터 부분과 실행 취소 로그로 나눈다. 데이터 부분은 항상 마지막으로 커밋된 버전을 유지하며, 실행 취소 로그는 데이터의 이전 버전을 재구성할 수 있도록 한다.

MVCC는 타임스탬프와 증가하는 트랜잭션 ID를 사용하여 ''트랜잭션 일관성''을 달성한다. 객체의 여러 버전을 유지하여 트랜잭션이 데이터베이스 객체를 읽기 위해 대기할 필요가 없도록 한다. 객체의 각 버전에는 ''읽기 타임스탬프''와 ''쓰기 타임스탬프''가 있어, 특정 트랜잭션이 읽기 타임스탬프보다 먼저 나오는 가장 최근 버전을 읽을 수 있다.

Rust^영어에서 MVCC를 사용하는 데이터베이스의 행을 보관하는 구조는 다음과 같다.

```rust

struct Record {

/// 삽입 트랜잭션 식별자 스탬프.

insert_transaction_id: u32,

/// 삭제 트랜잭션 식별자 스탬프.

delete_transaction_id: u32,

/// 데이터의 길이.

data_length: u16,

/// 레코드의 내용.

data: Vec,

}

4. 1. 쓰기 작업 규칙

• '''RTS'''('''T<sub>i</sub>''') < '''RTS'''('''T<sub>k</sub>'''): '''T<sub>i</sub>'''의 읽기 타임스탬프가 '''T<sub>k</sub>'''의 읽기 타임스탬프보다 빨라야 한다. 이는 마치 가게에서 줄을 서는 것과 비슷하여, 앞에 있는 사람들이 계산을 완료해야만 현재 트랜잭션의 계산(쓰기)을 완료할 수 있다.
• '''TS'''('''T<sub>i</sub>''') < '''RTS'''('''P'''): 만약 트랜잭션의 타임스탬프가 객체의 현재 읽기 타임스탬프보다 이르다면, 트랜잭션은 중단되고 다시 시작된다. 이는 나중의 트랜잭션이 이미 이전 값에 의존하기 때문이다.<sup>[2]</sup>

4. 2. 장점 및 단점

5. 예시

다중 버전 동시성 제어(MVCC)의 작동 방식을 예시를 통해 살펴보자.

시간 = 1일 때 데이터베이스의 상태는 다음과 같다.

T0은 객체 1 = "Foo"와 객체 2 = "Bar"를 썼다. 그 후 T1은 객체 1 = "Hello"를 썼고 객체 2는 원래 값을 유지했다.

T1이 커밋된 후, T2와 T3 트랜잭션이 동시에 실행된다고 가정하자. T2는 객체 1과 객체 2를 읽는 장기 실행 트랜잭션이고, T3는 객체 2를 삭제하고 객체 3 = "Foo-Bar"를 추가하는 트랜잭션이다. 시간 2에서 데이터베이스 상태는 다음과 같다.

T2는 T3가 쓰기를 커밋하기 전의 데이터베이스 버전을 보게 되므로, T2는 객체 2 = "Bar"와 객체 1 = "Hello"를 읽는다. 이것이 MVCC가 잠금 없이 스냅샷 격리 읽기를 허용하는 방식이다.

5. 1. 동시 읽기-쓰기

T0은 객체 1 = "Foo"와 객체 2 = "Bar"를 썼다. 그 후 T1은 객체 1 = "Hello"를 썼고 객체 2는 원래 값을 유지했다. 객체 1의 새 값은 T1이 커밋된 후 시작되는 모든 트랜잭션에 대해 시간 0의 값을 대체하며, 이 시점에서 객체 1의 버전 0은 가비지 수집될 수 있다.

T1이 커밋된 후 객체 2와 객체 1에 대한 읽기 작업을 시작하는 장기 실행 트랜잭션 T2와 객체 2를 삭제하고 객체 3 = "Foo-Bar"를 추가하는 동시 업데이트 트랜잭션 T3이 있는 경우, 시간 2에서 데이터베이스 상태는 다음과 같다.

시간 2 시점에 삭제로 표시된 객체 2의 새 버전과 새로운 객체 3이 있다. T2와 T3이 동시에 실행되므로 T2는 2 이전, 즉 T3이 쓰기를 커밋하기 전의 데이터베이스 버전을 보게 되므로 T2는 객체 2 = "Bar"와 객체 1 = "Hello"를 읽는다. 이것이 다중 버전 동시성 제어가 록 없이 스냅샷 격리 읽기를 허용하는 방식이다.

MVCC에서 가용성을 달성하기 위해서는 최소한 모든 처리의 "어떤 순서"로 수행되었는지를 확실하게 기록해야 한다. 이를 위해 타임스탬프나 트랜잭션 ID 등을 사용하여 모든 갱신 처리가 관리된다.

SQL 규격(SQL92)에서 정해진 4가지 종류의 트랜잭션 격리 수준 중에서는, '''Read Committed''' (커밋된 데이터는 항상 읽음)에 해당하는 처리이다.

6. MVCC를 채택한 데이터베이스 및 소프트웨어

MVCC는 클로저(Clojure)의 소프트웨어 트랜잭션 메모리, 버전 관리 시스템 등 다양한 소프트웨어에서 사용된다.

6. 1. 데이터베이스

6. 2. 기타 소프트웨어

• 클로저(Clojure)의 소프트웨어 트랜잭션 메모리
• 버전 관리 시스템 전반

7. 추가 문헌

• Gerhard Weikum, Gottfried Vossen, ''Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery'', Morgan Kaufmann, 2002, ISBN 1-55860-508-8

참조

<sub>[1]</sub> 웹사이트 Clojure - Refs and Transactions https://clojure.org/[...] 2019-04-12
<sub>[2]</sub> 서적 Database management systems Osborne/McGraw-Hill
<sub>[3]</sub> 논문 Concurrency Control in Distributed Database Systems http://portal.acm.or[...]
<sub>[4]</sub> Thesis Naming and Synchronization in a Decentralized Computer System http://hdl.handle.ne[...] 2022-11-12
<sub>[5]</sub> 뉴스 RDB Gets Mixed Greeting https://books.google[...] 1984-04-09
<sub>[6]</sub> 웹사이트 Re: [Firebird-devel] isc_dpb_dbkey_scope | Firebird https://sourceforge.[...]
<sub>[7]</sub> 웹사이트 A not-so-very technical discussion of Multi Version Concurrency Control https://firebirdsql.[...] 2020-11-12
<sub>[8]</sub> 웹사이트 refs http://clojure.org/r[...] 2013-09-18
<sub>[9]</sub> 웹인용 Concurrency Control in Distributed Database Systems http://portal.acm.or[...]
<sub>[10]</sub> 웹인용 Naming and Synchronization in a Decentralized Computer System https://web.archive.[...] 1978-09-21