개요
MVCC는 예전에 회사에서 데이터베이스 관련 교육을 할 때 접했던 개념이었는데, 최근 PostgreSQL 쿼리에서 관련 키워드를 보게 되어 다시 들쳐보게 되었다. PostgreSQL의 주요 동작 방식과 연관이 있으니 잘 정리해 보자.
MVCC
MVCC란 다중 버전 동시서 제어(Multi Version Concurrency Control)의 줄임말로, 과거부터 현재까지의 다양하 버전 데이터에 대한 관리와 제공이 가능하지를 나타내는 DBMS의 필수 기능 중 하나이다. 시시각각 변경되고 있는 데이터 중에서 사용자가 데이터를 조회한 시점의 데이터를 정확하게 제공하는지를 나타내는 것으로, DBMS 마다 다르게 구현하고 있다.
PostgreSQL - MVCC 구현과 XMAX/XMIN
PostgreSQL은 아래와 같은 방식으로 MVCC를 구현했다.
1. 테이블 내부에 변경 이전 버전의 데이터와 현재 버전의 데이터를 모두 위치시킨다.
2. 각 레코드 별로 XID라는 버전 정보를 두어 시점을 식별한다.
3. 수행 시점의 Transaction ID와 레코드의 XID를 비교하여 MVCC를 구현한다.
XID는 XMIN과 XMAX로 구성되어 있다. 실행 작업마다 값이 기록되는 공간이 다른데, INSERT/UPDATE가 실행되면 XMIN에 XID을 기록하고, DELETE/UPDATE가 실행되면 XMAX에 XID을 기록한다. 각 동작 방식은 다음과 같다.
INSERT : 해당 시점의 XID를 XMIN에 기록
DELETE : 해당 시점의 XID를 XMAX에 기록
UPDATE : 해당 시점의 XID를 변경 전 레코드 XMAX에 기록 -> 해당 시점의 XID를 변경 후 레코드의 XMIN에 기록
UPDATE의 경우 DELETE & INSERT처럼 이해하면 될 것 같다. 관점을 달리하면 XMAX가 Null인 데이터는 최신 버전의 데이터라는 것을 알 수 있다.
아래 그림은 MVCC 구현 방식을 그림으로 나타낸 것이다.
데이터 조작 시 버전 정보를 관리하는 목적은 데이터 조회 시점의 Transaction ID와 XMIN/XMAX를 비교하여 특정 시점의 데이터를 추출하기 위함이다.
위 그림을 예로 들어, XID 2000에 데이터 조회 쿼리가 수행을 시작했다고 하자.
- [A, 10]은 조회 시점보다 과거에 입력(XMIN-=999)되어 미래 시점에 삭제될 예정(XMAX-=2001)이므로 조회 대상이다.
- [B, 20]은 조회 시점보다 과거에 입력(XMIN-=1000)되었으므로 조회 대상이다.
- [B, 20]은 조회 시점보다 미래에 입력(XMIN-=2001)되었으므로 조회 대상이 아니다.
문제점
PostgreSQL의 MVCC는 레코드 별 XID를 비교하는 방식으로 비교적 쉽게 MVCC를 구현할 수 있다는 장점을 가진다. 하지만, 몇 가지 문제의 원인이기도 하다.
1. 비효율적인 공간 사용
- 테이블이 이전 버전의 데이터를 포함하고 있기 때문에 데이터 갱신이 빈번한 테이블의 경우 실제 데이터보다 더 많은 공간을 요구한다.
2. XID 부족
- XID는 4 Byte이기 때문에 43억 정도의 Transaction을 표현할 수 있다. 큰 숫자이긴 하지만 중단 없이 동작하고 데이터 변경이 계속 이뤄지는 DBMS에서는 부족한 숫자이다.
- 때문에 XID를 순환식으로 사용하며, 오래된 XID는 주기적으로 특수 값으로 세팅하는 등의 추가 작업을 필요로 한다.
참고 문서