PostgreSQL的MVCC vs InnoDB的MVCC

任何一個數據庫最主要功能之一是可擴展。如果不刪除彼此，則盡可能較少鎖競爭從而達到這個目的。由于read、write、update、delete是數據庫中最主要且頻繁進行的操作，所以并發執行這些操作時不被阻塞則顯得非常重要。為了達到這種目的，大部分數據庫使用多版本并發控制（Multi-Version Concurrency Control）這種并發模型。這種模型能夠將競爭減少到最低限度。

MVCC是什么

Multi Version Concurrency Control ( MVCC)是這樣的一種算法：通過對同一個對象維護多個版本，提供一種很好的并發控制技術，這種技術能夠使READ和WRITE操作不發生沖突。這里的WRITE指的是UPDATE和DELETE，不包含Insert是因為新插入的記錄可以通過各自的隔離級別進行保護。每個WRITE操作使對象產生一個新版本，每個并發讀操作依賴于隔離級別讀取對象不同的版本。由于READ和WRITE操作同一個對象的不同版本，所以這些操作不需要將對象完全鎖住，因此這些操作能夠并發執行。當然當兩個并發事務WRITE同一個記錄時，這些鎖競爭還是會存在的。

當前大部分數據庫系統都支持MVCC。這個算法的核心是對相同對象維護不同版本，因此不同數據庫創建并維護多版本的方式不同，其實現方式也不同。相應地，數據庫操作和數據存儲也發生變化。

實現MVCC最常見的方法：PostgreSQL使用的方法、InnoDB和Oracle的使用方法。下面我們會詳細討論PG和InnoDB的實現方式。

PostgreSQL中的MVCC

為了支持多版本，PG對每個對象（PG術語：Tuple）增加了額外的字段：

1、xmin：進行插入或更新操作事務的事務ID。UPDATE中，對tuple的新版本分配該事務ID。

2、xmax：進行刪除或更新操作事務的事務ID。UPDATE中，對當前存在的tuple分配該事務ID。新創建的tuple，該字段默認為null。

PostgreSQL將所有數據存儲在HEAP中（每頁默認8KB）。新記錄的xmin為創建該記錄的事務的事務ID；老版本（進行update或delete）其xmax為進行操作的事務的ID。會有一個鏈表將老版本和新版本連接起來。在回滾的過程中，老版本記錄可以被重用；依賴于隔離級別，READ語句讀取一個老版本記錄進行返回。

例如下面兩條記錄：T1（值為1）、T2（值為2），通過下面3步對記錄的創建進行演示：

從圖中可以看出，數據庫中初始時存在兩個記錄：1和2。

第二步，將2更新為3。此時創建一個新值，并存放到同一個存儲區域的下一個位置。老版本2為其xmax分配該事務的ID，并且指向最新的版本記錄。

同理，第三步，當T1被刪除時，對記錄進行虛擬刪除（為其xmax分配當前事務ID），該操作不存在創建新記錄版本。

下面，通過實例講解每個操作如何創建多版本，不用加鎖如何實現事務的隔離級別。下面例子中使用默認隔離級別“READ COMMITTED”。

INSERT

每次insert一個記錄，都會新創建一個tuple并將其存儲到表文件的頁中。

可以看到：

1、Session-A開啟一個事務，其事務ID為495

2、Session-B開啟一個事務，其事務ID為496

3、Session-A插入一個tuple，存儲到HEAP

4、新tuple的xmin為495，而xmax為null

5、由于Session-A的事務沒有提交，session-B看不到第3步插入的值

6、Session-A提交

7、都可以看到新插入的tuple

UPDATE

PostgreSQL的UPDATE不是“IN-PLACE”更新，不會將現有對象更新替換為新值，而是新創建一個新對象。因此UPDATE涉及以下幾步：

1、將當前對象標記為deleted

2、插入對象的一個新版本

3、將對象的老版本指向新版本

因此，即使許多記錄保持不變，HEAP也會占用空間，就像新插入另一個記錄一樣。

如上所示：

1、Session-A開啟一個事務，其事務ID為497

2、Session-B開啟一個事務，其事務ID為498

3、Session-A更新一個現有記錄

4、Session-A可以看到tuple的最新版本而Session-B看到另一個老版本。Session-A看到新記錄的xmin為497,xmax為null；Session-B看到老版本xmin是495，xmax為497即Session-A的事務ID。這兩個tuple版本都存在HEAP中，如果空間允許甚至存在同一頁中。

5、Session-A提交事務，老版本消失

6、現在所有會話都可以看到記錄的同一個版本。

DELETE

DELETE操作和UPDATE類似，只是不會添加一個新版本。如UPDATE，只是將當前對象標記為已刪除。

1、Session-A開啟一個事務，事務ID為499

2、Session-B開啟一個事務，事務ID為500

3、Session-A刪除現有記錄

4、Session-A看不到當前事務已刪除的記錄；Session-B看到老版本，其xmax為499，499的事務刪除的該記錄

5、Session-A提交事務，老版本記錄消失

6、所有會話都看不到之前的老版本

可以看到，這些操作都不會直接刪除現有記錄，如果需要會添加一個附加版本。

我們來看看SELECT在多版本中怎么執行：依賴于隔離級別，SELECT需要讀取tuple的所有版本直到找到合適的tuple。假設有一個tuple T1，被更新為新版本T1’，然后再被更新為T1’’：

1、SELECT操作進入這個表的heap中，首先檢查T1，如果T1的xmax事務已提交，查找該tuple的下一個版本

2、T1’也被提交，查找下一個版本

3、]最后找到T1’’看到xmax未提交或者為null，然后T1’’的xmin可見，最后讀取T1’’這個tuple。

可以看到需要遍歷該tuple的3個版本才能找到合適的可見版本，直到VACUUM進程回收了打上delete標簽的記錄。

InnoDB中的MVCC

為了支持多版本，InnoDB對行記錄又額外維護了幾個字段：

1、DB_TRX_ID：插入或更新航記錄的事務的事務ID

2、DB_ROLL_PTR：即回滾指針，指向回滾段中的undo log record

與PostgreSQL相比，InnoDB也會創建行記錄的多版本，但是存儲老版本的方式不同。

InnoDB將行記錄的老版本存放到獨立的表空間/存儲空間（回滾段）。和PostgreSQL不同，InnoDB僅將行記錄最新版本存儲到表的表空間中，而將老版本存放到回滾段。回滾段中的undo log作用：用來進行回滾操作；依賴于隔離級別，進行多版本讀，讀取老版本。

例如，兩行記錄：T1（值為1），T2（值為2），可以通過下面3步說明新記錄的創建過程：

從上圖可以看到，初始時，表中有兩條記錄1和2。

第二階段，行記錄T2值2被更新為3。此時記錄創建一個新版本并替代老版本。老版本存儲到回滾段（注意，回滾段中的數據僅包含更改值，即delta value），同時新版本行記錄中的回滾指針指向回滾段中的老版本。和PostgreSQL不同，InnoDB更新是“IN-PLACE”。

同理，第三步，刪除T1然后將其標記為虛擬刪除（僅在行記錄指定的一個bit位上打上delete標簽）并在回滾段中插入一個對應的新版本。同樣回滾指針指向回滾段中undo log。

從表面上看，所有操作表象與PostgreSQL相同，只是多版本在內部存儲方式不同。

MVCC：PostgreSQL vs InnoDB

下面分析PostgreSQL和InnoDB的MVCC主要不同在哪幾方面：

1、老版本的大小

PostgreSQL僅更新tuple老版本的xmax，因此老版本的大小和相應插入的記錄大小相同。這意味著，如果一個older tuple有3個版本，那么他們大小都相同（如果更新的值大小不同，每次更新時實際大小就不同）。

InnoDB的老版本存儲到回滾段，且比對應的插入記錄小，因為InnoDB僅將變化的值寫到undo log。

2、INSERT操作

INSERT時，InnoDB會向回滾段寫入額外的記錄，而PostgreSQL僅在UPDATE中創建新版本。

3、回滾時恢復老版本

回滾時，PostgreSQL不用任何特定內容，需注意老版本的xmax等于update該記錄的事務ID。因此在并發快照中該記錄認為是alive的直到該事務ID的事務提交。

而InnoDB，一旦回滾，需要重新構造對象的老版本。

4、]回收老版本占用的空間

PG中，老版本占用的空間僅在沒有并發快照使用時才可以被回收，此時被認為dead。然后VACCUM可以回收空間。VACCUM可以手動觸發也可以依賴于配置在后臺任務中觸發。

InnoDB的undo log分為INSERT UNDO和UPDATE UNDO。事務提交后，就會立即釋放INSERT UNDO。當沒有其他并發快照使用時，才可以釋放UPDATE UNDO。InnoDB沒有顯示VACUUM操作但是有類似的PURGE回收undo log。

5、延遲vacuum的影響

如前所示，PostgreSQL延遲vacuum存在很大影響。即使頻繁執行delete，它將會引起表膨脹造成占用的存儲空間暴增。這還會造成到達一個點后，需要執行一個高額代價的操作VACUUM FULL。

6、表膨脹時的順序掃描

即使所有記錄都是dead狀態，PostgreSQL的順序掃描也會掃描對象所有的老版本，直到執行vacuum將dead的記錄刪除。這是PG中常見且經常討論的問題。主要PG將一個tuple的所有老版本都存儲到同一個存儲區域。

而InnoDB，除非需要，否則不需要讀取undo log。如果所有undo記錄都已失效，那么只需要讀取所有對象的最新版本既可。

7、索引

PostgreSQL獨立存儲索引，并將索引連接到HEAP中的真實數據。因此即使沒有更改索引，有時也需要更新索引。隨后這個問題被HOT（Heap Only Tuple）解決，但是仍有限制，如果相同頁空間不足，則退回到正常UPDATE操作。

InnoDB由于使用聚集索引，不會有這樣的問題。

結論

PostgreSQL的MVCC有一些缺點，尤其是具有頻繁UPDATE/DELETE負載時，會引起表膨脹。因此決定選擇PG時，需要慎重配置VACUUM。

PG社區已經意識到這個問題，已經開始涉及基于undo的MVCC（暫命名為ZHEAP），我們在未來版本可以看到這個特性。

原文

https://severalnines.com/blog/comparing-data-stores-postgresql-mvcc-vs-innodb