MVCC (다중 버전 읽기 일관성)

MVCC

 

MVCC (Multi-Version Concurrency Control)는 쿼리 수행 시점의 데이터를 제공하는 기법이다.

▪ 이를 위해서는 변경 후의 현재 데이터 (Current Data) 뿐 아니라, 변경 전의 이전 데이터

(Before Data)를 읽을 수 있어야 한다.

 

PostgreSQL MVCC의 특징

▪ 특징-1. 이전 버전의 데이터를 테이블 블록 내에 저장한다.

1) 이 특징은 MVCC를 매우 단순하게 구현할 수 있다는 장점이 있다.

2) 하지만 ‘이전 데이터’를 블록 내에 저장함으로써 테이블의 공간 사용 효율이 떨어진다는 단점이 있다.

3) 이 단점을 해결하기 위해서 Vacuum이 필요하다.

4) Vacuum을 수행하면 불필요한 데이터가 삭제된다.

5) Vacuum Full을 수행하면 테이블이 재생성 된다.

 

▪ 특징-2. 레코드 별로 트랜잭션 ID (XID)를 관리한다.

1) 테이블 블록 내에 ‘이전 데이터’를 저장하므로 레코드마다 트랜잭션 ID가 필요하다.

2) 이때, 레코드마다 트랜잭션 ID(XID)를 저장하므로 XID의 크기를 최소화할 필요가 있다.

3) PostgreSQL은 XID를 4바이트로 관리한다.

4) 이때문에 Vacuum이 필요하다.

정리하면, Vacuum은 PostgreSQL의 MVCC의 특징때문에 필요한 오퍼레이션이다.

 

트랜잭션 ID (XID)를 4바이트로 관리함에 따른 문제점

▪ 43억을 모두 소진한 후에는 다시 1부터 시작할 수밖에 없다.

▪ 1,000 TPS가 발생하는 시스템이라면, 50일 후에 43억을 모두 소진하게 된다.

(49.7일 = 43억 / (86,400초 * 1,000 TPS))

 

Wraparound

▪ Wraparound 이전 시점: XID 43 억 > XID 42억

▪ Wraparound 이후 시점: XID 3 > XID 43억

PostgreSQL은 XID 비교를 위해 Modulo 연산을 사용한다.

24와 5를 비교해보자. 어떤 값이 더 큰 값인가?

• 공식을 적용하면 24가 더 큰 값이다.

Diff = (int32) (id1 – id2) = (int32) id1 – (int32) id2 = -16 – 5 = -21

-21은 -20~20 범위를 벗어나므로 1로 변환된다. 즉, diff 결과가 0보다 크므로 id1이 더 큰 값이다.

 

• 즉, 현재 XID 기준으로 절반은 OLD 데이터, 절반은 NEW 데이터이다.

• 한바퀴가 돌기 전에, NEW 데이터들은 FROZEN 돼야한다.

• Frozen된 데이터들은 항상 Visible 하다.

• Frozen을 위해, 9.3까지는 XMIN을 2로 변경했고, 9.4부터는 t_infomask 10번째 비트를 1로 변경한다.