PolarDB：Lizard事務系統

使用限制

引擎版本需要選擇相容MySQL 8.0。

工作原理

關係型資料庫的MVCC機制，依賴資料的提交版本來決定其可見度，所以，Lizard單機事務系統，引入了SCN （System Commit Number）來表達事務的提交順序，並設計了事務槽（Transaction Slot）來持久化事務的提交版本號碼即SCN，其架構圖如下：

寫事務：

• 事務啟動時，申請事務槽Transaction Slot，地址記為UBA。

• 事務過程中，對修改的記錄填入 (SCN=NULL, UBA) 兩個欄位。

• 事務提交時，擷取提交號SCN，並回填到事務槽上，並完結事務狀態，返回客戶提交完成。

讀事務：

• 查詢啟動時，啟動事務視圖Vision，即從SCN產生器上擷取當前SCN，作為查詢的Vision。

• 查詢進行時，根據行記錄的UBA地址找到對應的事務槽，獲知事務的狀態以及提交號。

• 根據記錄SCN和視圖SCN進行數字大小比較，就可以判斷可見度。

SCN事務效能最佳化

相比於MySQL開源的InnoDB事務系統，Lizard SCN事務系統帶來了巨大的優勢：

• 解除綁定對全域結構的訪問依賴，讀寫衝突得到大幅緩解。

• 視圖升級為Vision，只有一個SCN數字，不再有活躍事務ID 數組，易於傳播。

• 支援自訂的FlashBack查詢。

但同時也引入了一些代價，因為事務提交只修改了事務槽，行記錄上的 SCN 一直為 NULL 值，所以，每次的可見度比較，都需要根據 UBA 地址訪問事務槽來確定真實的提交版本號碼 SCN。為了減輕事務槽的多次重複訪問，我們在Lizard SCN 事務系統上引入了Cleanout，一共分為兩類，Commit Cleanout和Delayed Cleanout。

Commit Cleanout

事務在修改過程中，收集部分記錄，在事務提交後，根據提交的SCN，回填部分收集的記錄，因為需要盡量保證提交的速度不受影響，僅僅根據目前記錄數和系統的負載能力，回填少量的記錄，並快速提交返回客戶。

Delayed Cleanout

查詢過程中，再根據UBA地址回查事務槽SCN，判斷其事務狀態以及提交版本號碼之後，如果事務已經提交，就嘗試協助進行行記錄的Cleanout，我們稱之為Delayed Cleanout，以便下次查詢的時候，直接存取行記錄SCN進行可見度判斷，減輕事務槽的訪問。

Transaction Slot複用

由於事務槽不能無限擴充，為了避免空間膨脹，採用Reusing方案。事務槽會持續地儲存到一個free_list鏈表上，在分配的時候，優先從free list中擷取進行複用。

頻繁地訪問free_list鏈表以及從free_list鏈表上摘取，需要訪問多個資料頁，這帶來了巨大的開銷。為了避免訪問多個資料頁，事務槽page會被先放入cache快表中，下次擷取時直接從cache快表上擷取，這大大降低了讀多個資料頁帶來的開銷。

SCN事務系統效能表現

雖然Cleanout帶來了部分的代價，但由於分擔到了查詢過程中，並且沒有集中的熱點爭搶存在，在測試結果上，相比於MySQL開源的InnoDB事務系統，Lizard SCN事務系統整體的吞吐能力大幅提升。

相比於MySQL-8032，Lizard SCN事務系統效能提升30%，延時降低53%。