1    云原生數據庫和 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 不依賴特殊硬件和網絡環境也可以保證性能，實現云上云下一套架構。

圖片

2  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：我們也在探索充分利用內部潮汐算力的資源優化調度方案，在白天業務高峰期，將資源向實時性更強的交易類業務傾斜，在低峰期自動縮容，將資源復用投入到離線計算類業務中，不但客戶節省了運維成本與資源成本，也避免了資源閑置和浪費，實現了更高的資源利用率。

以上功能預計都會在近期開放灰度試用。

圖片

以上是今天分享的全部內容。