吳林、黃偉

近日，華為雲自研關係型資料庫 Taurus 公開亮相。作為華為雲自研的最新一代雲原生分散式資料庫，Taurus 完全相容 MySQL 8.0，採用計算與儲存分離、日誌即資料的架構設計，支援 1 寫 15 讀，效能達到原生 MySQL 的 7 倍。

過去多年，資料庫技術本質上並沒有出現顛覆式發展。作為核心基礎設施，資料庫是一款使用者粘性非常高的產品，一旦核心業務資料落定，企業輕易不會嘗試更換，因此很長一段時間內，大眾習慣於老牌 IT 廠商壟斷資料庫市場的狀況。然而，雲廠商涉足資料庫領域的訊息近年層出不窮，比如 AWS Aurora、阿里雲 PolarDB 以及華為雲 Taurus。

在網際網路、移動和物聯網等新場景之下，圖片、音訊、影片等非結構化資料開始出現爆炸性增長，傳統資料庫不堪重負，企業客戶急切需要新的資料庫產品。在雲端計算技術不斷成熟的背景之下，雲資料庫開始崛起，並因為按需擴充套件、按需付費等特性獲得大量中小企業及網際網路客戶的擁護。

從雲廠商的入局也不難看出，現在做資料庫的門檻並不像從前那麼高，並不只有傳統的資料庫廠商可以做，單就這一領域的創業者也不少。在這種情況下，核心競爭力只可能從差異性發展而來，人人都在做且會做的東西很難形成核心競爭力。據此，華為雲近日公開亮相的自研關係型資料庫 Taurus 有什麼不同？核心競爭力是什麼？為什麼效能足以達到原生 MySQL 的 7 倍？與雲上 MySQL 相比，後者的不足之處有哪些？華為雲進行了哪些修補？

雲原生資料庫技術趨勢

傳統的資料庫體系結構已有 30 多年的歷史，專為本地部署，本地儲存和單機資料庫例項而設計和優化，此後很長一段時間內，該體系結構未針對公有云環境進行優化。在公有云環境下，計算和儲存通過網路分離以支援多租戶資料庫例項並 scale out 向兩端擴充套件；並不要求單個節點的高可靠性。

舉例來說，假設一個本地資料庫的每個資料庫例項都有本地儲存，為了支援高可用性，通常部署一個備例項並使用資料庫內部複製機制將資料庫日誌（MySQL binlog）傳送到備例項重建資料庫副本。目前，大多數雲廠商都採用類似機制來支援雲資料庫高可用性。但是，這種內部複製機制並沒有利用雲端儲存已經通過儲存層複製提供的可靠性，這導致大量儲存和頻寬浪費。實際上，備資料庫例項可以通過雲端儲存與主例項共享資料，不僅可以節省磁碟空間和頻寬，還可以為雲資料庫服務提供快速 RTO。

很明顯，在將傳統資料庫遷移上雲時，需要重新設計和優化資料庫系統。過去幾年，主要雲供應商，比如 AWS 和阿里雲，已經做了部分工作。預計未來幾年，更多雲和資料庫供應商將遵循這一趨勢，構建某種形式的雲原生資料庫技術。此外，Gartner 預測，到 2019 年，90％的雲資料庫架構將支援計算和儲存分離。

值得注意的是，除了基於雲環境的資料庫架構重新設計之外，這一領域還存在兩大趨勢：

• 在雲原生資料庫中利用新硬體：如新硬體和RDMA。這些都是活躍的研究領域，然而除了充當快取和計算機與儲存之間的快速連結之外，到目前為止，我們還沒有看到任何其他的突破性。

• 基於即時和歷史收集的資料，使用ML（機器學習）和統計技術來幫助管理和自我調整雲資料庫，包括但不限於資料庫例項自動伸縮和引數設定和自動調整，異常檢測等。

雲上 MySQL 的不足

當前，對於 RDS for MySQL，各大雲廠商基本都採用主備高可用模式、主備間使用 Binlog 複製，該架構下每新增一個從庫都需要全棧式資源，這導致了一些問題：

1、資源浪費

備庫往往不承擔流量；複製執行緒會消耗主庫 / 從庫計算資源，造成計算資源浪費；EVS 的 3 副本冗餘機制下，N 個備庫最大需要 3*(N+1) 個副本，造成儲存資源浪費以及多種資料需要走儲存網路進行刷盤，造成網路資源浪費等。

2、擴充套件性不佳

新增只讀時需要拷貝資料，重放 binlog，對於大資料量情況下速度很慢，尤其是採用本地盤方案。主從複製延遲問題會讓主備倒換受影響，難以保證 RTO。此外，採用物理備份、邏輯備份時備份恢復速度很慢， 1T 以上資料量都以小時計，使得資料庫擴充套件性受限。

華為雲 RDS 架構演進

華為雲 Taurus 與 Amazon Aurora 資料庫進化的方向是一致的，然而進化路徑各有不同，這是由各自的資料庫雲服務實現方式不同所決定的。華為雲 RDS MySQL 有如下幾個版本，這些產品形態滿足不同的使用者業務場景，具有不同的特點，可以進行優勢互補。

MySQL 單機版

MySQL 單機版採用資料庫計算節點和儲存節點分離的方式，利用雲盤資料本身的可靠性和多副本的特性，同時也利用 ECS 雲伺服器虛擬化來提升標準化部署、版本和運維管理效率，能夠滿足低端使用者不太注重高可用服務的業務場景。

MySQL 主備版

MySQL 高可用版則是針對企業級使用者提供的高可用資料庫版本，提供 99.95% 的 SLA 保障。採用 Active-Standby 高可用架構，主節點和備節點之間通過 MySQL Binlog 進行資料 Replication。當主節點發生故障，備節點接管服務。同時還支援最多 5 個只讀節點，支援負載均衡的資料讀寫分離的訪問方式。

MySQL 金融版

MySQL 金融版是針對金融行業等高階使用者設計的高可用、高可靠雲服務產品。一主兩備三節點架構，可跨 AZ 部署，任意一臺伺服器宕機不影響業務可用性；基於 Paxos 協議，實現了分散式下資料的強一致性，擁有更加優異的故障恢復時間，滿足資料容災備份等業務場景的需求。

Taurus 的進化

Taurus 採用計算與儲存解耦的技術架構，同時可以最多支援 15 個只讀節點。主節點和只讀節點之間是 Active-Active 的 Failover 方式，計算節點資源得到充分利用，由於使用共享儲存，進一步降低了使用者使用成本。

Taurus 的設計思想有幾個大的革新：

• 將部分計算能力解除安裝到儲存節點
• 軟硬體深度優化，充分利用 RDMA 網路、NVME SSD 等硬體優勢
• 日誌即資料，與傳統 RDS for MySQL 相比，不再需要刷 page，所有更新操作都記錄日誌，不再需要 double
  write，減少了網路通訊。

另外在 DB Server 設計上，完全擁抱開源生態，完全相容 MySQL 8.0。

華為雲 Taurus 和 Amazon Aurora 的一個共同設計哲學就是，先推出一寫多讀的版本，根據市場需求，適時推出多寫版本，滿足絕大多數 OLTP 應用場景和效能要求。

Taurus 架構設計原則：

採用華為下一代雲端儲存（DFV）作為快速，可擴充套件，可靠和共享資料庫儲存。不復制儲存層中的已有功能，例如，資料複製，跨 AZ 可靠性，資料清理。

• 單個數據庫叢集應該只需要一份足夠可靠的資料庫副本集。所有隻讀副本共享儲存在雲端儲存中，甚至跨
  AZ，資料庫層中沒有邏輯複製。一寫多讀，沒有獨立的備用例項。主節點發生故障轉移時，只讀副本可以切換到接管主伺服器。
• 記錄為資料庫。僅順序寫入以最小化 SSD 磨損（避免寫入放大）
• 只有資料庫日誌通過網路從資料庫計算機節點寫入 DFV 儲存層。沒有頁面檢查點和重新整理跨網路，沒有雙重寫入。基於 DFV
  儲存層內的資料庫日誌重建資料面，以避免繁重的網路流量。
• 基於跨 DFV 儲存節點的切片策略對資料庫進行分割槽，以支援大型資料庫卷。單個 DFV
  儲存節點管理來自不同資料庫叢集例項的多個分片，實現儲存容量和處理能力的無限擴充套件。

Taurus 資料庫關鍵技術點剖析

Taurus 架構

如圖所示，Taurus 是一個分散式叢集架構設計，採用計算與儲存分離的設計理念，滿足公有云計算環境下使用者業務彈性擴充套件的剛性需求。資料庫計算節點和儲存節點之間採用高速網路互聯，並通過 RDMA 協議進行資料傳輸，使得 I/O 效能不再成為瓶頸。

資料庫節點採用和 MySQL 完全相容的設計。主節點和只讀節點之間採用 Active-Active 的 Failover 方式，提供 DB 的高可用服務。同時 ，DB Server 之間僅需同步 Redo log 相關的元資料資訊。

1. SQL Nodes
2. 管理客戶端連線、解析 SQL 請求,、分析執行計劃並執行和管理事務隔離級別
3. 一主多讀
4. 主庫和只讀松耦合
5. 主庫和只讀通訊少
6. 快速 Failover
7. 引入核心中的一些特性
   Query result cache
   Query plan cache
   Online DDL

SQL Replication

只讀節點在本地 buffer pool 中維護資料頁的多個版本

• 減少從儲存的遠端讀取資料頁

主庫互動

• MVCC: 同步主庫當前活躍事務列表
• 頁失效: 接收主庫頁失效列表

高速網路下的 RDMA 協議

部署 RoCE RDMA 以減少網路延遲並增加頻寬。在單個 AZ 中，Taurus 可以利用高速網路（RDMA）來獲得更新和讀取的低延遲儲存 I/O，這對於低客戶端連線方案非常有用。

儲存抽象層 (SAL)

儲存抽象層 (SAL) 是邏輯層，將資料儲存和 SQL 前端、事務、查詢執行等進行隔離。由一組容量和處理能力按需擴充套件的分片節點組成，SAL 將所有 SQL 節點需要的資料頁按分片管理和橫向擴充套件。隨著資料庫規模的增長，可用資源（儲存、記憶體）隨著分片建立按比例增長。資料處理本地化，資料密集型操作是在儲存節點上按分片服務執行。

Taurus Storage

Taurus 儲存基於華為雲儲存 DFV 持久層。DFV 持久層叢集包括多個儲存節點。每個儲存節點包含多個 SSD 裝置和適應 SSD 介質的 append 儲存服務程序。 DFV 持久層為 SQL 節點提供儲存介面。

Taurus 採用日誌化方式處理 SQL 節點資料，即通常表述的“日誌即資料”。資料組織採用面向 SSD 重新設計的 Append 模式，顯著減少系統寫放大，減少儲存時延。同時，在 Append 模式下，資料回滾和回檔變得非常快速。

Taurus 核心競爭力

成本更低

與傳統 RDS for MySQL 相比，只有一份儲存。新增只讀節點時，只需新增計算節點，無需額外購買儲存。只讀節點越多，節省的儲存成本越多。

擴充套件性、可靠性更高

• 橫向擴充套件更快。Taurus 採用共享儲存，只需新增計算節點，無論多大資料量，只需 5 分鐘左右，並且支援 15 個只讀.
• 縱向擴充套件更快。容器化部署，規格變更更快。
• 主從倒換時間更快。 消除了複製延遲，RTO 有保證。
• 資料庫 Crash 恢復更快。
• 效能更強

軟硬結合，基於硬體：Hi1822 解除安裝，NVMe SSD，RDMA，同時核心進行優化：去掉 double write，Query Cache/Plan Cache 優化，Innodb Lock Management 優化，Audit Plugin 效率優化，效能達到原生 MySQL 的 7 倍。

備份恢復更快

專為 Taurus 引擎定製的分散式儲存系統，極大提升資料備份、恢復效能

• 強大的資料快照處理能力。AppendOnly vs. WriteInPlace，資料天然按多時間點多副本儲存，快照秒級生成，支援海量快照。
• 任意時間點快速回滾。基於底層儲存系統的多時間點特性，不需增量日誌回放，可直接實現按時間點回滾。
• 並行高速備份、恢復。備份及恢復邏輯下沉到各儲存節點，本地訪問資料並直接與第三方儲存系統互動，高併發高效能。
• 快速例項恢復。通過非同步資料拷貝 + 按需實時資料載入機制， Taurus 例項可在數分鐘內達到完整功能可用。

總結

通過以上介紹不難發現，Taurus 的共享儲存架構將資料持久化放入新一代儲存中，充分保障資料強一致性和 0 丟失；採用軟硬體結合，充分利用 RDMA 網路、NVME SSD 等硬體優勢，正是這些關鍵技術的整合創新，才使得 Taurus 的效能有了質的飛躍。