PolarDB：提交時間戳記技術CTS

背景資訊

目前主流的開源關係型資料庫如MySQL或者PostgreSQL，其事務狀態更新以及MVCC機制均是採用了基於活躍事務列表的方案。這種方案在高並發情境下會帶來嚴重的效能瓶頸，無法充分利用CPU多核並發處理事務的邏輯；其次，基於活躍事務列表方案在叢集一致性讀、叢集多點寫入以及Share-Nothing架構中的XA交易管理上存在天然的缺陷。

在PolarTrans中，事務狀態更新無需維護活躍事務列表，傳統的事務狀態的拷貝過程通過擷取當前叢集的最大提交時間戳記來替代。事務狀態的迭代、擷取、查詢（可見度判斷）等邏輯更加輕量化，同時PolarTrans將大部分的事務邏輯進行無鎖最佳化，對於讀寫混合情境、純寫情境都有較大效能提升。

全記憶體設計的CTS log由一段ring buffer組成，事務通過trx_id模數映射到其對應的slot，每個slot包含trx指標和csn（事務提交序號）。

技術優勢

• 寫事務啟動

  原生事務系統在寫事務啟動時，需要通過trx sys mutex保護來分配事務ID，寫入活躍事務ID數組（rw_trx_ids），維護活躍事務ID到trx映射的集合（rw_trx_set），以及讀寫事務鏈表（rw_trx_list）等資料結構。在PolarTrans事務系統中，事務啟動時會註冊到CTS log，根據trx_id模數分配相應的slot，並將事務狀態設定為特殊的active標記即可，並且該過程可以做到無鎖化處理。

• 寫事務提交

  原生事務系統寫事務提交時，需要在trx sys mutex保護下, 尋找rw_trx_ids並移除對應的trx_id，維護rw_trx_set、rw_trx_list等。在PolarTrans事務系統中，事務提交時分配提交時間戳記並更新CTS log中對應的csn欄位即可。

• read view

  InnoDB的MVCC機制核心需要通過read view來控制資料的可見度，原生事務系統擷取read view的過程同樣需要在trx sys mutex保護下，拷貝活躍事務ID數組、當前最小活躍ID和最大事務ID。在進行可見度判斷時, 可能需要尋找活躍事務ID數組來確定可見度。在讀寫衝突較為嚴重的情境下，讀寫事務和唯讀事務都需要在mutex保護下更新和拷貝當前事務狀態，維護代價極高，並且可見度判斷效率較低。在PolarTrans事務系統中，通過擷取事務系統的最大提交時間戳記來代替原生read view，同樣可以做到無鎖處理。在可見度判斷過程中, 您只需要對比唯讀事務csn和行記錄的trx csn即可。

開啟PolarTrans

全域一致性（高效能模式）功能開啟後，PolarTrans功能會預設開啟。關於如何開啟全域一致性（高效能模式）功能，請參見如何開啟全域一致性（高效能模式）。

效能對比

在相同情境下，分別測試原生事務系統（關閉PolarTrans）和PolarTrans事務系統（開啟PolarTrans）的QPS。

• 測試環境

  一個規格為88核710 GB的PolarDB MySQL版8.0版本叢集版。

• 測試載入器

  Sysbench

• 測試資料量

  88張表，每張表1200萬條記錄。

• 測試案例

  使用以下Sysbench內建用例進行測試。

  • oltp_read_write

  • oltp_insert

  • oltp_update_index

  • oltp_update_no_index

  • oltp_read_only

• 測試結果及說明

  從以下測試中可以看出，在讀寫或唯寫情境下，PolarTrans事務系統對於資料庫整體效能有非常大的提升。在唯讀情境下，整個資料庫的效能並沒有發生變化，唯讀事務可以通過ReadView緩衝來降低事務狀態拷貝過程中的加鎖開銷，所以PolarTrans事務系統相比原生事務系統並不會帶來明顯的效能提升。