熟悉Greenplum資料庫的朋友應該都知道，GP底層是使用PostgreSQL資料庫來實行MPP架構的，而對於事務控制這一塊，也是使用PostgreSQL的多版本控制MVCC，實現了讀寫分離，顯然就會提高資料庫每秒查詢的效能。

在Read Commit事務隔離級別時，查詢請求只讀取查詢請求之前已經提交的事務的資料更改，對當前版本的資料並不影響；

而DML語句，會操作當前版本。因此做到了讀寫分離的目的，提高資料庫併發能力。

我們先來回顧一下PostgreSQL裡面的MVCC多版本控制。

在PostgreSQL中，每一個事務都會得到一個被稱作為 XID 的事務ID。這裡說的事務不僅僅是被 BEGIN - COMMIT 包裹的一組語句，還包括單條的insert、update或者delete語句。當一個事務開始時，PostgreSQL遞增XID，然後把它賦給這個事務。PostgreSQL還在系統裡的每一行記錄上都儲存了事務相關的資訊，這被用來判斷某一行記錄對於當前事務是否可見。舉個例子，當你插入一行記錄時，PostgreSQL會把當前事務的XID儲存在這一行中並稱之為 xmin。只有那些已提交的而且xmin比當前事務的XID小的記錄對當前事務才是可見的。這意味著，你可以開始一個新事務然後插入一行記錄，直到你提交（ COMMIT ）之前，你插入的這行記錄對其他事務永遠都是不可見的。等到提交以後，其他後建立的新事務就可以看到這行新記錄了，因為他們滿足了 xmin < XID 條件，而且建立那一行記錄的事務也已經完成。

對於 DELETE 和 UPDATE 來說，機制也是類似的，但不同的是對於它們PostgreSQL使用叫做 xmax 的值來判斷資料的可見性。這幅圖展示了在兩個併發的插入/讀取資料的事務中，MVCC在事務隔離方面是怎麼起作用的。

PostgreSQL使用xmin,xmax,cmin,cmax等標記來實現多版本，他們的含義為：

xmin：在建立記錄(tuple)時，記錄此時的事務id，後面每次update也會更新。

xmax: 在更新或刪除tuple或者lock時，記錄此時的事務id；如果記錄沒有被刪除，那麼此時為0。

cmin:插入該元組的命令在插入事務中的命令標識（從0開始累加）

cmax:刪除該元組的命令在插入事務中的命令標識（從0

但是對於Greenplum資料庫來說，它畢竟是基於多個postgres例項來實現MPP架構的資料庫，所以上面的標記的值可能與單個postgres有區別。下面我們示例中會說明。

#裝載資料，非並行，如果並行載入資料的話，可以考慮使用gpfdist或gpload等方式

zhangyun_db=# COPY test_mvcc from '/home/gpadmin/mvcc.txt' with delimiter as '|' null as '';

COPY 4

zhangyun_db=# select * from test_mvcc ;

id |   name   

----+-----------

4 | Hadoop

3 | Greenplum

2 | Hive

1 | Spark

(4 rows)

zhangyun_db=# select t.*, t.xmin, t.xmax, t.cmin, t.cmax from test_mvcc t;

id |    name    |  xmin  | xmax | cmin | cmax

----+------------+--------+------+------+------

8 | Flink      | 449908 |    0 |    0 |    0

4 | Hadoop     | 449906 |    0 |    0 |    0

5 | HBase      | 449775 |    0 |    0 |    0

7 | PostgreSQL | 457913 |    0 |    0 |    0

2 | Hive       | 449910 |    0 |    0 |    0

3 | Greenplum  | 449909 |    0 |    0 |    0

6 | HAWQ       | 449899 |    0 |    0 |    0

1 | Spark      | 449905 |    0 |    0 |    0

(8 rows)

從上圖可以看出，8條記錄的xmin是不一樣的(如果是PostgreSQL資料庫的話，這裡應該是一樣的，因為這些資料是通過同一個事務copy建立的)。

另外xmax都為0，說明資料自從匯入後就沒有被刪除。

下面我們來演示在Greenplum資料中執行update的情況：

請開啟兩個linux終端A和B，方便資料比對和檢視。

首先在終端A執行，但不提交：

zhangyun_db=# begin;

BEGIN

zhangyun_db=# update test_mvcc set name = 'Hive On Spark' where id = 2;

UPDATE 1

終端B檢視：

zhangyun_db=# select t.*, t.xmin, t.xmax, t.cmin, t.cmax from test_mvcc t;

id |    name    |  xmin  |  xmax  | cmin | cmax

----+------------+--------+--------+------+------

4 | Hadoop     | 449906 |      0 |    0 |    0

7 | PostgreSQL | 457913 |      0 |    0 |    0

6 | HAWQ       | 449899 |      0 |    0 |    0

2 | Hive       | 449910 | 450412 |    0 |    0

1 | Spark      | 449905 |      0 |    0 |    0

8 | Flink      | 449908 |      0 |    0 |    0

5 | HBase      | 449775 |      0 |    0 |    0

3 | Greenplum  | 449909 |      0 |    0 |    0

(8 rows)

可以看到，對於id為2的資料行的xmax發生了變化，但是資料本身是沒有變化的，因為終端A的事務還沒有提交。

接著，我們在終端A執行提交動作，如下：

zhangyun_db=# commit;

COMMIT

同時在終端B再檢視：

zhangyun_db=# select t.*, t.xmin, t.xmax, t.cmin, t.cmax from test_mvcc t;

id |     name      |  xmin  | xmax | cmin | cmax

----+---------------+--------+------+------+------

2 | Hive On Spark | 450412 |    0 |    0 |    0

6 | HAWQ          | 449899 |    0 |    0 |    0

5 | HBase         | 449775 |    0 |    0 |    0

7 | PostgreSQL    | 457913 |    0 |    0 |    0

4 | Hadoop        | 449906 |    0 |    0 |    0

3 | Greenplum     | 449909 |    0 |    0 |    0

8 | Flink         | 449908 |    0 |    0 |    0

1 | Spark         | 449905 |    0 |    0 |    0

(8 rows)

可以看到id為2的記錄，其xmin已經變化了。

根據上面的結果，不知道大家有沒有發現，對於Greenplum來說，更新或者刪除都沒有修改cmin和cmax的值。

在PostgreSQL中，cmin和cmax用於判斷同一個事務內的其他命令導致的行版本變更是否可見。如果一個事務內的所有命令嚴格順序執行，那麼每個命令總能看到之前該事務內的所有變更，不需要使用命令標識。然而一個事務記憶體在命令交替執行的情況，比如使用遊標進行查詢。Fetch遊標時看到的是宣告遊標時的資料快照而不是Fetch執行時，即宣告遊標後對資料的變更對該遊標不可見。

這一塊的內容，後續抽時間分析原始碼再寫一篇文章進行分析。