多主架構:VLDB技術論文《Taurus MM: bringing multi-master to the cloud》解讀

2023-09-14 18:01:03

本文分享自華為雲社群《多主創新,讓雲資料庫效能更卓越》,作者: GaussDB 資料庫。

華為《Taurus MM: bringing multi-master to the cloud》論文被國際資料庫頂會VLDB 2023錄用,這篇論文裡講述了符合雲原生資料庫特點的超燃技術。介紹瞭如何通過各種黑科技減少雲原生資料庫的網路消耗,進而提升雲原生資料庫的效能和穩定性。下面就讓我們抽絲剝繭,細細品味技術的魅力,揭開華為雲資料庫多主技術的面紗。

說明:技術論文中的Taurus在華為雲商用的產品名是GaussDB(for MySQL),是GaussDB(for MySQL)的雲原生架構技術版本。

引言

現下,大型高效能資料庫通常採用一寫(主)多讀(副本)這種標準部署方式來提高業務吞吐量。。然而,單主會導致單點故障,同時限制了寫擴充套件性,也就是說帶來了可用性和效能的雙重挑戰。而效能和可用性是衡量一個企業級資料庫是否優秀最關鍵的兩個方面。由此多主資料庫應運而生。

多主資料庫有Shared-nothing和Shared-storage兩種架構。谷歌Spanner、亞馬遜DynamoDB、CockroachDB、OceanBase及其他一些資料庫採用了Shared-nothing架構。亞馬遜Aurora多主資料庫、Oracle RAC和IBM DB2 pureScale採用了Shared-storage架構。

對於Shared-nothing架構的多主,每個節點對一個小資料子集執行計算和儲存。在高度分割區的工作負載場景下,這類架構可以提供非常高的可延伸性。但在如下不均衡的工作負載場景中,其優勢受限——節點數越多可能意味著節點間資料交換越多:

  • 資料無明顯分割區特徵;
  • 工作負載隨時間變化;
  • 存在熱點資料場景。

同時,Shared-nothing架構使用分散式提交協定,資訊同步多輪交換,降低了多主系統的效能。

對於傳統的Shared-storage架構,計算層與儲存層分離。這類架構由於其高度整合及密集網路通訊的特點,需要高階和專用的網路硬體,更適用於對成本不敏感的線下資料中心部署,不適用於雲原生資料庫。雲的最核心特點是通過多使用者共用基礎設施平攤成本(包括網路硬體)來實現高成本收益。

雲資料庫效能的關鍵是對共用網路的優化。華為雲資料庫多主(Multi-Master)專注於從訊息的數量和大小兩方面減少網路流量,這一目標的達成並不容易,很多公司嘗試過,但目前還沒有看到成功案例。

華為雲資料庫多主黑科技解析

那究竟如何實現多主上雲呢?華為雲資料庫多主有哪些硬核技術突破呢?

通過對網路流量消耗進行分析和歸類後,我們發現主要的網路消耗是由於主節點寫頁面、時鐘同步和鎖資訊互動三個方面。華為雲資料庫在如上三個方面進行了探索和嘗試,並取得了可喜成績。下面詳細討論在每類開銷上,華為雲資料庫是如何盡最大可能減少網路計算開銷的。

減少直接頁面寫入帶來的網路消耗

此問題已有解決方案——2020年SIGMOD會議上我們向會議研究團體介紹了華為雲原生資料庫單主解決方案:「Log As Database」(紀錄檔即資料庫)。

簡單說就是華為雲資料庫計算與儲存分離,計算層包含一寫(主)多讀(副本)。計算層的作用是執行資料庫的修改,主要功能有:接入連線、執行查詢、管理事務以及生成WAL紀錄檔記錄(紀錄檔用於描述對資料庫頁所做的修改)。事務更新時先生成紀錄檔記錄,主節點將這些紀錄檔記錄傳送到儲存層的Log Stores中進行儲存,通過紀錄檔回放生成資料,從而無需通過網路執行整個資料頁面的寫入,節省了所需的網路頻寬。詳細見圖1。

圖1:華為雲資料庫元件及分層架構

cke_114.png

華為雲資料庫多主重用了一主多讀架構中的思想,採用Shared-storage體系結構,所有Master之間共用紀錄檔儲存和頁面儲存,繼續沿用悲觀並行控制,且引入了全域性鎖管理器GLM(Global Lock Manager)。

各Master維護自己的預寫紀錄檔(WAL)。使用者事務在單主上執行——沒有分散式事務。紀錄檔記錄寫入執行事務的主機中。每個Master會定期將帶有位置資訊標識(哪個Master生成的)的新生成紀錄檔提交給所有其他Master。通過位置資訊,各Master讀取其他所有Master上生成的紀錄檔記錄,並更新進自己的緩衝池頁面中。詳細如圖2所示。

圖2:華為雲資料庫多主元件及分層架構

cke_115.png

減少時鐘同步帶來的網路消耗

多主資料庫特有的第二個網路開銷來源是時鐘同步。在單主資料庫上,事務時鐘資訊可以直接使用本地物理時鐘。然而,在分散式系統中,不同節點上的物理時鐘很難精確保持一致。而通過網路連線同步和獲取時間戳,會帶來無法容忍的時間延遲。因此,對於分散式資料庫物理時鐘這種方法不再適用。

這在業界不是一個新近才提出的問題。早在20世紀70年代,萊斯利·蘭伯特就為了解決此問題,提出並行明瞭標量時鐘(常稱為邏輯時鐘,或蘭伯特時鐘)。此標量時鐘由一個數位組成時間戳,僅在訊息交換期間進行不同計算機間的時鐘同步。蘭伯特時鐘的演演算法簡單而優雅,但要通過它建立資料庫的分散式快照基本不可能,而分散式快照對分散式資料庫的效能又是非常重要的。同時,邏輯時鐘無法儲存事務間的因果關係。簡單說,就是假設