PostgreSQL 的 MVCC 機(jī)制解析
導(dǎo)語
PostgreSQL是通過MVCC(Multi-Version Concurrency Control)來保證事務(wù)的原子性和隔離性，具體MVCC機(jī)制是怎樣實(shí)現(xiàn)的，下面舉些示例來做個(gè)簡單解析以加深理解。
前提
表中隱藏的系統(tǒng)字段
PostgreSQL的每個(gè)表中都有些系統(tǒng)隱藏字段，包括：
- oid: 對(duì)象標(biāo)識(shí)符，生成的值是全局唯一的，表、索引、視圖都帶有oid，如果需要在用戶創(chuàng)建的表中使用oid字段，需要顯示指定“with oids”選項(xiàng)。
- ctid: 每條記錄(稱為一個(gè)tuple)在表中的物理位置標(biāo)識(shí)。
- xmin: 創(chuàng)建一條記錄(tuple)時(shí)，記錄此值為當(dāng)前事務(wù)ID。
- xmax: 創(chuàng)建tuple時(shí)，默認(rèn)為0，刪除tuple時(shí)，記錄此值為當(dāng)前事務(wù)ID。
- cmin/cmax: 標(biāo)識(shí)在同一個(gè)事務(wù)中多個(gè)語句命令的序列值，從0開始，用于同一個(gè)事務(wù)中實(shí)現(xiàn)版本可見性判斷
MVCC機(jī)制
MVCC機(jī)制通過這些隱藏的標(biāo)記字段來協(xié)同實(shí)現(xiàn)，下面舉幾個(gè)示例來解釋MVCC是如何實(shí)現(xiàn)的
- //seesion1:
- 創(chuàng)建表，顯示指定oid字段：
- testdb=# create table t1(id int) with oids;
- CREATE TABLE
- 插入幾條記錄
- testdb=# insert into t1 values(1);
- INSERT 17569 1
- testdb=# insert into t1 values(2);
- INSERT 17570 1
- testdb=# insert into t1 values(3);
- INSERT 17571 1
查詢當(dāng)前表中的tuple信息，xmin為創(chuàng)建tuple時(shí)的事務(wù)ID，xmax默認(rèn)為0
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+------+------+------+-------+----
- (0,1) | 80853357 | 0 | 0 | 0 | 17569 | 1
- (0,2) | 80853358 | 0 | 0 | 0 | 17570 | 2
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (3 rows)
接下來，我們更新某個(gè)tuple的字段，將tuple中id值為1更新為4，看看會(huì)發(fā)生什么
- testdb=# begin;
- BEGIN
- testdb=# select txid_current();
- txid_current
- --------------
- 80853360
- (1 row)
- testdb=# update t1 set id = 4 where id = 1;
- UPDATE 1
查看tuple詳細(xì)信息
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+------+------+------+-------+----
- (0,2) | 80853358 | 0 | 0 | 0 | 17570 | 2
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (0,4) | 80853360 | 0 | 0 | 0 | 17569 | 4
- (3 rows)
可以看到id為1的tuple(oid=17569)已經(jīng)被修改了，id值被更新為4，另外ctid、xmin字段也被更新了，ctid值代表了該tuple的物理位置，xmin值是創(chuàng)建tuple時(shí)都已經(jīng)寫入，這兩個(gè)字段都不應(yīng)該被更改才對(duì)，另起一個(gè)seesion來看下(當(dāng)前事務(wù)還未提交)
- //seesion2:
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+----------+------+------+-------+----
- (0,1) | 80853357 | 80853360 | 0 | 0 | 17569 | 1
- (0,2) | 80853358 | 0 | 0 | 0 | 17570 | 2
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (3 rows)
可以看到id為1的tuple(oid=17569)還存在，只是xmax值被標(biāo)記為當(dāng)前事務(wù)Id。 原來更新某個(gè)tuple時(shí)，會(huì)新增一個(gè)tuple，填入更新后的字段值，將原來的tuple標(biāo)記為刪除(設(shè)置xmax為當(dāng)前事務(wù)Id)。同理，可以看下刪除一個(gè)tuple的結(jié)果
- //seesion1:
- testdb=# delete from t1 where id = 2;
- DELETE 1
- //seesion2:
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+----------+------+------+-------+----
- (0,1) | 80853357 | 80853360 | 0 | 0 | 17569 | 1
- (0,2) | 80853358 | 80853360 | 1 | 1 | 17570 | 2
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (3 rows)
刪除某個(gè)tuple時(shí)也是將xmax標(biāo)記為當(dāng)前事務(wù)Id，并不做實(shí)際的物理記錄清除操作。另外cmin和cmax值遞增為1，表明了同一事務(wù)中操作的順序性。在該事務(wù)(seesion1)未提交前，其他事務(wù)(seesion2)可以看到之前的版本信息，不同的事務(wù)擁有各自的數(shù)據(jù)空間，其操作不會(huì)對(duì)對(duì)方產(chǎn)生干擾，保證了事務(wù)的隔離性。
提交事務(wù)，查看最終結(jié)果如下：
- //seesion1:
- testdb=# commit;
- COMMIT
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+------+------+------+-------+----
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (0,4) | 80853360 | 0 | 0 | 0 | 17569 | 4
- (2 rows)
但是，如果我們不提交事務(wù)而是回滾，結(jié)果又是如何?
- testdb=# begin ;
- BEGIN
- testdb=# update t1 set id = 5 where id = 4;
- UPDATE 1
- testdb=# rollback;
- ROLLBACK
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+----------+------+------+-------+----
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (0,4) | 80853360 | 80853361 | 0 | 0 | 17569 | 4
- (2 rows)
- xmax標(biāo)記并未清除，繼續(xù)新增一條記錄：
- testdb=# insert into t1 values(5);
- INSERT 17572 1
- testdb=# select ctid, xmin, xmax, cmin, cmax, oid, id from t1;
- ctid | xmin | xmax | cmin | cmax | oid | id
- -------+----------+----------+------+------+-------+----
- (0,3) | 80853359 | 0 | 0 | 0 | 17571 | 3
- (0,4) | 80853360 | 80853361 | 0 | 0 | 17569 | 4
- (0,6) | 80853362 | 0 | 0 | 0 | 17572 | 5
- (3 rows)
發(fā)現(xiàn)沒有清理掉新增的tuple，消除原有tuple上的xmax標(biāo)記，這是為何?處于效率的原因，如果事務(wù)回滾時(shí)也進(jìn)行清除標(biāo)記，可能會(huì)導(dǎo)致磁盤IO，降低性能。那如何判斷該tuple的是否有效呢?答案是PostgreSQL會(huì)把事務(wù)狀態(tài)記錄到clog(commit log)位圖文件中，每讀到一行時(shí)，會(huì)到該文件中查詢事務(wù)狀態(tài)，事務(wù)的狀態(tài)通過以下四種來表示：
- #define TRANSACTION_STATUS_IN_PROGRESS=0x00 正在進(jìn)行中
- #define TRANSACTION_STATUS_COMMITTED=0x01 已提交
- #define TRANSACTION_STATUS_COMMITTED=0x02 已回滾
- #define TRANSACTION_STATUS_SUB_COMMITTED=0x03 子事務(wù)已提交
MVCC保證原子性和隔離性
原子性
事務(wù)的原子性(Atomicity)要求在同一事務(wù)中的所有操作要么都做，要么都不做。根據(jù)PostgreSQL的MVCC規(guī)則，插入數(shù)據(jù)時(shí)，會(huì)將當(dāng)前事務(wù)ID寫入到xmin中，刪除數(shù)據(jù)時(shí)，會(huì)將事務(wù)ID寫入xmax中，更新數(shù)據(jù)相當(dāng)于先刪除原來的tuple再新增一個(gè)tuple，增刪改操作都保留了事務(wù)ID，根據(jù)事務(wù)ID提交或撤銷該事務(wù)中的所有操作，從而保證了事務(wù)的原子性。
隔離性
事務(wù)的隔離性(Isolation)要求各個(gè)并行事務(wù)之間不能相互干擾，事務(wù)之間是隔離的。PostgreSQL可讀取的數(shù)據(jù)是xmin小于當(dāng)前的事務(wù)ID且已經(jīng)提交。對(duì)某個(gè)tuple進(jìn)行更新或刪除時(shí)，其他事務(wù)讀取的就是這個(gè)tuple之前的版本。
MVCC的優(yōu)勢
讀寫不會(huì)相互阻塞，寫操作并沒有堵塞其他事務(wù)的讀，在寫事務(wù)未提交前，讀取的都是之前的版本，提高了并發(fā)的訪問效率。
事務(wù)可以快速回滾，操作后的tuple都帶有當(dāng)前事務(wù)ID，直接標(biāo)記clog文件中對(duì)應(yīng)事務(wù)的狀態(tài)就可達(dá)到回滾的目的。
MVCC帶來的問題
事務(wù)ID回卷問題
PostgreSQL也需要事務(wù)ID來確定事務(wù)的先后順序，PostgreSQL中，事務(wù)被稱為XID，獲取當(dāng)前XID:
- testdb=# select txid_current();
- txid_current
- --------------
- 80853335
- (1 row)
事務(wù)ID由32bit數(shù)字表示，當(dāng)事務(wù)ID用完時(shí)，就會(huì)出現(xiàn)新的事務(wù)ID會(huì)比老ID小，導(dǎo)致事務(wù)ID回卷問題(Transaction
ID Wraparound)。 PostgreSQL的事務(wù)ID規(guī)則：
- 0: InvalidXID，無效事務(wù)ID
- 1: BootstrapXID，表示系統(tǒng)表初使化時(shí)的事務(wù)
- 2: FrozenXID，凍結(jié)的事務(wù)ID，比任務(wù)普通的事務(wù)ID都舊。
– 大于2的事務(wù)ID都是普通的事務(wù)ID。
當(dāng)***和最舊事務(wù)之差達(dá)到2^31時(shí)，就把舊事務(wù)換成FrozenXID，然后通過公式((int32)(id1 - id2)) < 0比較大小即可
垃圾數(shù)據(jù)問題
根據(jù)MVCC機(jī)制，更新和刪除的記錄都不會(huì)被實(shí)際刪除，操作頻繁的表會(huì)積累大量的過期數(shù)據(jù)，占用磁盤空間，當(dāng)掃描查詢數(shù)據(jù)時(shí)，需要更多的IO，降低查詢效率。PostgreSQL的解決方法是提供vacuum命令操作來清理過期的數(shù)據(jù)。
原文鏈接：https://www.qcloud.com/community/article/528634，作者：黃輝
【本文是51CTO專欄作者“騰訊云技術(shù)社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過51CTO聯(lián)系原作者獲取授權(quán)】
