百度智能雲團隊在今年 11-12 月特別推出了四期《百度智能雲資料庫》系列雲智公開課，為大家全面地介紹了以雲原生資料庫 GaiaDB 和分布式資料庫 GaiaDB-X 為代表的百度智能雲資料庫系列產品。
在《百度智能雲資料庫》系列雲智公開課的第二期內容中，百度智能雲資料庫高級架構師邱學達為我們介紹了雲原生資料庫的不同技術路線及能力對比，並對比傳統單體資料庫介紹了雲原生資料庫的技術差異和挑戰，同時深入淺出地解析了 GaiaDB 在高性能和多級高可用方向上的技術架構。
下文為他的演講內容整理：
雲原生資料庫和 GaiaDB
目前，雲原生資料庫已經被各行各業大規模投入到實際生產中，最終的目標都是「單機 + 分布式一體化」。但在演進路線上，當前主要有兩個略有不同的路徑。
一種是各大公有雲廠商選擇的優先保證上雲兼容性的路線。它基於存算分離架構，對傳統資料庫進行改造，典型產品有 AWS Aurora、阿里雲 PolarDB、騰訊雲 TDSQL-C、百度智能雲 GaiaDB。
資料庫作為公有雲上的核心基礎設施，第一要務是實現用戶上雲的平滑性。目前像雲網絡、雲主機，雲盤都實現了完全透明兼容。雲原生資料庫也必須實現從語法、使用習慣、再到生態上的全面兼容。因此，基於現有生態做分布式化改造成為了一條首選的演進路線。使用存算分離路線的雲原生資料庫可以完美兼容傳統的使用習慣，為交易類場景提供低延遲的寫事務能力，同時讀擴展性與存儲擴展性藉助了分布式存儲的池化能力，也得到了很大增強。
另外一種路徑是先搭建一套分布式框架，然後在其中填充資料庫邏輯。OceanBase 和 TiDB 就是其中兩個比較典型的產品。它們將事務的子系統和鎖的子系統拆分為單獨的模塊。計算層通過與這些模塊交互，可讓多個節點均支持寫請求。然後由統一的新事務 + 鎖中心節點來進行仲裁。這樣，對需要較多計算資源的寫負載場景會有較好的提升。由於事務和鎖都需要跨網絡進行交互，因此事務延遲相對較高，在鎖負載較重的情況下會成為一定的瓶頸。
目前這兩個路線並不是涇渭分明，獨立發展的，大家都在向著統一的目標演進。因此我們可以看到，存算分離路線在逐漸增強 SQL 的多級並行能力，同時也在探索和支持多個寫節點的庫表級 / 行級的多寫能力。同時分布式事務路線也在積極探索在小數據規模下的單機部署架構。
所以在未來，這兩個路線會不斷融合。業務的數據規模不管多大，都可以平穩快速地運行在資料庫系統上，而不需要用戶去過分關注分區、索引、事務模型等信息。就像十年前如何在機器之間存儲海量小文件還是一個後端研發工程師的必修課，而隨著 S3 存儲的出現，用戶再也不需要考慮如何通過哈希等方式來保證單個文件夾不會保存太多文件一樣。
GaiaDB 是從百度智能雲多年資料庫研發經驗積累中逐漸疊代而來。GaiaDB 於 2020 年發布首個版本，首次實現了基於存算分離的大容量存儲和快速彈性能力，解決了百度內部的歷史庫、歸檔庫等大容量存儲需求。
緊接著，為了滿足集團內大部分核心業務的跨地域熱活准入門檻和就近讀性能需求，GaiaDB 於 2021 年發布了地域級熱活功能。跨地域熱活仍然使用存儲層同步的方案，同步延遲與吞吐都相較邏輯同步有很大提升，從地域可以實現與主地域接近相同的同步能力，不會成為拖慢整體系統的短板，也不會像邏輯同步那樣在大事務等場景下出現延遲飆升的問題。
所以 2.0 版本上線後，GaiaDB 逐漸接入了手百、貼吧、文庫等多個核心產品線，解決了業務在跨地域場景下的延遲與性能痛點。
隨著業務的逐漸上雲，多可用區高可用的需求慢慢凸顯，如何實現單機房故障不影響服務成為了很多業務上雲的關注點。為此 GaiaDB 打造了可支持跨可用區熱活的 3.0 版本，每個可用區都可以實時提供服務並且不增加額外的存儲成本。而在今年， GaiaDB 推出了更加智能化的 4.0 架構，性能進一步提升，功能完整度也在持續完成覆蓋。
接下來整體介紹一下 GaiaDB。目前 GaiaDB 已經實現了線上全行業場景覆蓋，最大實例達到了數百 TB，不僅兼容開源生態，還實現了 RPO=0 的高可靠能力。在成本方面，由於在架構設計上採用了融合的技術理念，GaiaDB 不依賴特殊硬體和網絡環境也可以保證性能，實現雲上雲下一套架構。
GaiaDB 的高性能 & 多級高可用設計
接下來我來分享一下 GaiaDB 的性能核心設計理念——通過融合和裁剪，將資料庫和分布式存儲進行深度融合，為全鏈路的同步轉異步化提供條件，從而實現極致的性能與通用性。
我們可以看到，如果資料庫簡單使用通用分布式協議和單機存儲引擎，如左圖所示，那麼資料庫需要處理主從同步，需要有 CrashSafe 所需要的物理日誌。同時，一致性協議也要有主從同步，要寫自己的 WAL 以及持久化快照。而單機引擎同樣需要 CrashSafe 以及一套日誌系統和數據存儲邏輯。
我們發現，多層日誌的嵌套帶來了層層延遲與寫放大。更複雜的是，數據流中嵌套多層邏輯後，也給系統整體數據安全帶來了一定挑戰。同時由於多層之間需要串行等待，所以在加入了網絡延遲後會給資料庫帶來很大的性能下降。雖然可以使用定製化硬體與網絡來縮短網絡和磁碟落盤的延遲以降低鏈路耗時，但這又引入了新的不確定性並導致了更高的成本。
GaiaDB 的解決思路是將事務和主從同步邏輯、日誌邏輯、快照和存儲持久化邏輯重新組合和排布。
首先是將分布式協議的主從同步邏輯融合進資料庫計算節點中。由於計算層本身就需要處理主從同步、事務和一致性問題，相關的工作量增加並不大。這樣一來，最直接的收益就是將兩跳網絡和 I/O 精簡為一跳，直接降低了鏈路延遲。
其次 GaiaDB 將多層增量日誌統一改為使用資料庫 Redo 物理日誌，由 LogService 日誌服務統一負責其可用性與可靠性。
除此之外，GaiaDB 也將持久化、快照和資料庫回放功能融合入存儲節點。由於存儲層支持了資料庫回放能力，可以很輕鬆實現數據頁級別的 MVCC。這樣全鏈路只剩下了資料庫語義，數據流簡單可靠，邏輯大大簡化。
下面我們一起來看下共識模型上的改變。
像 Raft 協議是需要兩跳網絡才能實現一次提交確認的，右上角就是 Raft 的數據流架構：CN 節點將寫發送給 Leader 後，需要等待 Leader 發送給 Follower 並至少收到一個返回後才能成功。
這裡就帶來了兩跳網絡和 I/O 的同步等待問題。而 GaiaDB 則是計算節點直接發送給多個 Log 服務並等待多數派返回，這樣不依賴任何特殊硬體與網絡就降低了延遲。這樣系統里不管是事務的一致性還是多副本一致性，統一由計算節點統籌維護，所有的增量日誌也統一為資料庫物理日誌，整體數據流簡單可控。
對於數據風險最高的 Crash Recovery 場景，由於統一使用了資料庫語義，整體流程更加健壯，數據可靠性更高，降低了數據在多種日誌邏輯之間轉換和同步帶來的複雜度風險。而在性能方面，由於存儲層自身具備回放能力，可以充分利用 LogService 層的日誌緩存能力。對於寫操作來說，不需要每次更改都刷盤，可以批次回放刷盤，大大節省了磁碟吞吐與 I/O。
經過以上改造，線上吞吐性能可以提升 40% 。同時由於鏈路簡化，也大大優化了長尾延遲。像之前計算節點與分布式主節點之間發生網絡抖動的場景，就會被多數派的返回特性來優化。
分享完一致性協議層優化，接下來我們來探討一下鏈路層優化。
我們知道，總吞吐與並發度成正比，與延遲成反比。一致性協議層改造並縮短了數據鏈路，可以通過降低延遲來增加吞吐。那麼有沒有辦法通過提升數據流的並發度來提升吞吐呢？答案是可以。由於資料庫的物理日誌自帶版本號與數據長度，所以不需要像通用存儲一樣實現塊級別串行提交。之所以使用通用存儲需要串行提交，是因為存儲端只能根據請求到達的先後確定數據版本，如果亂序到達，最後生效的版本是不可知的。
而對於 GaiaDB 來說，由於 LogService 具備資料庫語義的識別功能，所以計算節點只需要異步進行寫入，日誌服務就會自動根據數據版本選取最新數據，然後根據寫入情況批量返回成功，這樣鏈路就可以實現延遲與吞吐的解耦。
當然計算層依然會等待日誌層批量返回的最新落盤版本後再返回事務提交成功，所以依然可以滿足提交成功的事務一致性、持久化的要求。
另外針對高負載下 I/O 請求與資料庫業務請求爭搶 CPU 的問題，我們使用了 I/O 線程隔離技術，通過資源隔離的方式，將 I/O 線程與資料庫業務線程進行隔離。這樣即使在複雜負載場景下，I/O 延遲仍可以保持在較低水平。
在分析完前面兩部分之後，可能會有同學有疑問：既然日誌層到存儲層不是同步寫，是不是最終系統的一致性降低了？有沒有可能發生數據丟失或不一致的問題呢？答案是不會。因為 GaiaDB 的存儲是一套支持 MVCC 的多版本系統。所以即使回放實現上是異步，但是由於請求方會提供所需要的數據版本，存儲層可以提供對應版本的強一致數據視圖。
GaiaDB 的存儲節點支持數據頁的回放功能，可以動態回放至任意目標版本後再返回，在之前的版本里，假如由於異步的因素還沒有獲取到這部分增量日誌，存儲節點也會啟用優先拉取的策略實時拉取一次日誌後再回放，以此來提供較好的時效性。而在最新的 GaiaDB 版本中，我們也在計算層添加了同樣的回放能力，存儲節點盡力回放後仍不滿足需求的，由計算節點進行剩餘任務。
這樣對於存儲慢節點的兼容能力就大大增強了，同時由於存儲節點會盡力回放，所以也可以最大化利用存儲層的算力資源。對於刷髒邏輯目前也完全下沉到了存儲層，存儲節點可以自主控制刷盤策略和時機，儘量合併多次寫後再進行落盤，大大節省了磁碟 I/O 負載，平均 I/O 延遲降低了 50%。
下圖中我們可以看到，在綜合了多項優化後，讀寫性能實現了最高 89% 的提升，其中寫鏈路線路提升尤其明顯。這些都是在使用普通存儲介質和網絡環境的情況下測試得出的，主要得益於數據鏈路的縮短與同步轉異步的自適應高吞吐能力。
在討論完性能後，再分享一下 GaiaDB 在高可用方面的思考和設計理念。
資料庫作為底層數據存儲環節，其可用性與可靠性直接影響系統整體。而線上情況是複雜多變的，機房裡時時刻刻都可能有異常情況發生，小到單路電源故障，大到機房級網絡異常，無時無刻不在給數據造成可用性隱患。
作為商業資料庫，具備多級高可用能力是最核心的必備能力。這樣才能抵禦不同級別的異常情況，有力保障客戶業務的平穩運行。GaiaDB 支持多副本、跨可用區、跨地域三級別高可用，創新性地實現了多可用區熱活高可用、單個實例支持跨可用區部署。在不增加成本的情況下，每個可用區均可提供在線服務，任何可用區故障都不會打破存儲一致性。下面我們來分別看一下每個級別高可用能力的實現。
首先是實例的多副本高可用能力。
GaiaDB 對整體的分布式架構進行了重新設計，系統共分為三層，即計算層、日誌層、存儲層。其中計算層本身無狀態，僅負責事務處理與一致性維護，所以獲得了很強的彈性能力，實現了秒級切換、多節點容災，同時擴縮容只需要內存啟動即可。
日誌層負責系統增量日誌部分的持久化，實現了多數派高可用。同時由於一致性協調角色上移到了計算層，所以該層全對稱，任意節點故障不需要進行等待選主，也不會有重新選主帶來的風暴和業務中斷問題。
再往下是存儲層，負責數據頁本身持久化與更新。由於上層保留了增量日誌，所以存儲層可以容忍 n-1 副本故障。簡單來說就是只要有一個副本完好，加上上層提供的增量日誌，即可回放出所有版本的完整數據，實現了相比傳統多數派協議更高的可靠性能力。
其次是跨可用區與跨地域的高可用能力。
GaiaDB 的多級高可用都是基於存儲層物理日誌的直接複製。相比邏輯複製，數據鏈路大大縮短，同步延遲也不再受上層大事務或者 DDL 等操作影響，在主從同步延遲上具有很大優勢。
對於跨可用區高可用來說，由於 GaiaDB 具有對稱部署架構，所以可以很方便地進行跨可用區部署。這樣可以在不增加存儲成本的情況下實現多可用區熱活，任一可用區故障都不影響數據可靠性。
寫數據流可以自適應只跨一跳最短的機房間網絡，不需要擔心分布式主節點不在同機房帶來的兩跳跨機房網絡和跨遠端機房問題，而讀依然是就近讀取，提供與單機房部署接近的延遲體驗。由於跨機房傳輸的網絡環境更為複雜，GaiaDB 添加了數據流的鏈式自校驗機制，使數據錯誤可以主動被發現，保障了複雜網絡環境下的數據可靠性。
對於跨地域高可用來說，由於同樣使用了異步並行加速的物理同步，及時在長距離傳輸上，吞吐依然可以追齊主集群，不會成為吞吐瓶頸，在計入網絡延遲的情況下，國內可以實現數十毫秒的同步延遲，這是因為跨地域同樣可以使用異步並行寫加速，自動適應延遲和吞吐之間的關係。同時地域之間還可以實現主動快速切換和默認就近讀取。
所以在使用了 GaiaDB 的情況下，業務可以不做複雜的數據同步邏輯就可以實現低成本的跨可用區與跨地域高可用。
介紹完高性能和高可用兩部分的設計理念後，接下來再介紹一下我們正在內部灰度中的新功能：
- 並行查詢：並行查詢從並發度上進行加速的並行查詢能力，這對大數據規模下的多行查詢有非常好的加速作用，可以充分利用計算節點的 CPU 和內存資源和分布式存儲層的並行 I/O 能力。
- 分析型從庫（HTAP）：分析型從庫具備多種行列加速能力，既有支持百 TB 級別數據計算的分析型節點解決方案，也有支持百萬行以上檢索加速的列式索引引擎。其中列式索引引擎同樣採用物理日誌同步，不需要業務維護數據一致性，可以和當前交易類負載的事務隔離級別兼容。
- Serverless：我們也在探索充分利用內部潮汐算力的資源優化調度方案，在白天業務高峰期，將資源向實時性更強的交易類業務傾斜，在低峰期自動縮容，將資源復用投入到離線計算類業務中，不但客戶節省了運維成本與資源成本，也避免了資源閒置和浪費，實現了更高的資源利用率。
以上功能預計都會在近期開放灰度試用。
寫在最後
自 11 月 15 日起，百度智能雲團隊每周三都會上線一節《百度智能雲資料庫》系列雲智公開課。在前 4 期的課程中，專家們圍繞「從網際網路到雲計算再到 AI 原生，百度智能雲資料庫的演進」、「高性能和多級高可用，雲原生資料庫 GaiaDB 架構設計解析」、「面向金融場景的 GaiaDB-X 分布式資料庫應用實踐」、「一站式資料庫上雲遷移、同步與集成平台 DTS 的設計和實踐」四個主題展開了分享。
每節直播課的視頻我們都進行了錄製留存，都整理進了課程專題頁中，課程持續更新中，大家立即點擊【閱讀原文】進行觀看吧~