吳林、黃偉
近日，華為雲自研關系型資料庫 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 相關的中繼資料資訊。
- SQL Nodes
- 管理用戶端連接配接、解析 SQL 請求,、分析執行計劃并執行和管理事務隔離級别
- 一主多讀
- 主庫和隻讀松耦合
- 主庫和隻讀通信少
- 快速 Failover
-
引入核心中的一些特性
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 恢複更快。
- 性能更強
備份恢複更快
- 強大的資料快照處理能力。AppendOnly vs. WriteInPlace，資料天然按多時間點多副本存儲，快照秒級生成，支援海量快照。
- 任意時間點快速復原。基于底層存儲系統的多時間點特性，不需增量日志回放，可直接實作按時間點復原。
- 并行高速備份、恢複。備份及恢複邏輯下沉到各存儲節點，本地通路資料并直接與第三方存儲系統互動，高并發高性能。
- 快速執行個體恢複。通過異步資料拷貝 + 按需實時資料加載機制， Taurus 執行個體可在數分鐘内達到完整功能可用。
總結