百度智能云團隊在今年 11-12 月特別推出了四期《百度智能云數(shù)據(jù)庫》系列云智公開課，為大家全面地介紹了以云原生數(shù)據(jù)庫 GaiaDB 和分布式數(shù)據(jù)庫 GaiaDB-X 為代表的百度智能云數(shù)據(jù)庫系列產(chǎn)品。

在《百度智能云數(shù)據(jù)庫》系列云智公開課的第二期內(nèi)容中，百度智能云數(shù)據(jù)庫高級架構師邱學達為我們介紹了云原生數(shù)據(jù)庫的不同技術路線及能力對比，并對比傳統(tǒng)單體數(shù)據(jù)庫介紹了云原生數(shù)據(jù)庫的技術差異和挑戰(zhàn)，同時深入淺出地解析了 GaiaDB 在高性能和多級高可用方向上的技術架構。

下文為他的演講內(nèi)容整理：? ?? ?

云原生數(shù)據(jù)庫和 GaiaDB

目前，云原生數(shù)據(jù)庫已經(jīng)被各行各業(yè)大規(guī)模投入到實際生產(chǎn)中，最終的目標都是「單機 + 分布式一體化」。但在演進路線上，當前主要有兩個略有不同的路徑。

一種是各大公有云廠商選擇的優(yōu)先保證上云兼容性的路線。它基于存算分離架構，對傳統(tǒng)數(shù)據(jù)庫進行改造，典型產(chǎn)品有 AWS Aurora、阿里云 PolarDB、騰訊云 TDSQL-C、百度智能云 GaiaDB。

數(shù)據(jù)庫作為公有云上的核心基礎設施，第一要務是實現(xiàn)用戶上云的平滑性。目前像云網(wǎng)絡、云主機，云盤都實現(xiàn)了完全透明兼容。云原生數(shù)據(jù)庫也必須實現(xiàn)從語法、使用習慣、再到生態(tài)上的全面兼容。因此，基于現(xiàn)有生態(tài)做分布式化改造成為了一條首選的演進路線。使用存算分離路線的云原生數(shù)據(jù)庫可以完美兼容傳統(tǒng)的使用習慣，為交易類場景提供低延遲的寫事務能力，同時讀擴展性與存儲擴展性借助了分布式存儲的池化能力，也得到了很大增強。

另外一種路徑是先搭建一套分布式框架，然后在其中填充數(shù)據(jù)庫邏輯。OceanBase 和 TiDB 就是其中兩個比較典型的產(chǎn)品。它們將事務的子系統(tǒng)和鎖的子系統(tǒng)拆分為單獨的模塊。計算層通過與這些模塊交互，可讓多個節(jié)點均支持寫請求。然后由統(tǒng)一的新事務 + 鎖中心節(jié)點來進行仲裁。這樣，對需要較多計算資源的寫負載場景會有較好的提升。由于事務和鎖都需要跨網(wǎng)絡進行交互，因此事務延遲相對較高，在鎖負載較重的情況下會成為一定的瓶頸。

目前這兩個路線并不是涇渭分明，獨立發(fā)展的，大家都在向著統(tǒng)一的目標演進。因此我們可以看到，存算分離路線在逐漸增強 SQL 的多級并行能力，同時也在探索和支持多個寫節(jié)點的庫表級 / 行級的多寫能力。同時分布式事務路線也在積極探索在小數(shù)據(jù)規(guī)模下的單機部署架構。

所以在未來，這兩個路線會不斷融合。業(yè)務的數(shù)據(jù)規(guī)模不管多大，都可以平穩(wěn)快速地運行在數(shù)據(jù)庫系統(tǒng)上，而不需要用戶去過分關注分區(qū)、索引、事務模型等信息。就像十年前如何在機器之間存儲海量小文件還是一個后端研發(fā)工程師的必修課，而隨著 S3 存儲的出現(xiàn)，用戶再也不需要考慮如何通過哈希等方式來保證單個文件夾不會保存太多文件一樣。

GaiaDB 是從百度智能云多年數(shù)據(jù)庫研發(fā)經(jīng)驗積累中逐漸迭代而來。GaiaDB 于 2020 年發(fā)布首個版本，首次實現(xiàn)了基于存算分離的大容量存儲和快速彈性能力，解決了百度內(nèi)部的歷史庫、歸檔庫等大容量存儲需求。

緊接著，為了滿足集團內(nèi)大部分核心業(yè)務的跨地域熱活準入門檻和就近讀性能需求，GaiaDB 于 2021 年發(fā)布了地域級熱活功能。跨地域熱活仍然使用存儲層同步的方案，同步延遲與吞吐都相較邏輯同步有很大提升，從地域可以實現(xiàn)與主地域接近相同的同步能力，不會成為拖慢整體系統(tǒng)的短板，也不會像邏輯同步那樣在大事務等場景下出現(xiàn)延遲飆升的問題。

所以 2.0 版本上線后，GaiaDB 逐漸接入了手百、貼吧、文庫等多個核心產(chǎn)品線，解決了業(yè)務在跨地域場景下的延遲與性能痛點。

隨著業(yè)務的逐漸上云，多可用區(qū)高可用的需求慢慢凸顯，如何實現(xiàn)單機房故障不影響服務成為了很多業(yè)務上云的關注點。為此 GaiaDB 打造了可支持跨可用區(qū)熱活的 3.0 版本，每個可用區(qū)都可以實時提供服務并且不增加額外的存儲成本。而在今年， GaiaDB 推出了更加智能化的 4.0 架構，性能進一步提升，功能完整度也在持續(xù)完成覆蓋。

接下來整體介紹一下 GaiaDB。目前 GaiaDB 已經(jīng)實現(xiàn)了線上全行業(yè)場景覆蓋，最大實例達到了數(shù)百 TB，不僅兼容開源生態(tài)，還實現(xiàn)了 RPO=0 的高可靠能力。在成本方面，由于在架構設計上采用了融合的技術理念，GaiaDB 不依賴特殊硬件和網(wǎng)絡環(huán)境也可以保證性能，實現(xiàn)云上云下一套架構。

GaiaDB 的高性能 & 多級高可用設計

接下來我來分享一下 GaiaDB 的性能核心設計理念——通過融合和裁剪，將數(shù)據(jù)庫和分布式存儲進行深度融合，為全鏈路的同步轉(zhuǎn)異步化提供條件，從而實現(xiàn)極致的性能與通用性。

我們可以看到，如果數(shù)據(jù)庫簡單使用通用分布式協(xié)議和單機存儲引擎，如左圖所示，那么數(shù)據(jù)庫需要處理主從同步，需要有 CrashSafe 所需要的物理日志。同時，一致性協(xié)議也要有主從同步，要寫自己的 WAL 以及持久化快照。而單機引擎同樣需要 CrashSafe 以及一套日志系統(tǒng)和數(shù)據(jù)存儲邏輯。

我們發(fā)現(xiàn)，多層日志的嵌套帶來了層層延遲與寫放大。更復雜的是，數(shù)據(jù)流中嵌套多層邏輯后，也給系統(tǒng)整體數(shù)據(jù)安全帶來了一定挑戰(zhàn)。同時由于多層之間需要串行等待，所以在加入了網(wǎng)絡延遲后會給數(shù)據(jù)庫帶來很大的性能下降。雖然可以使用定制化硬件與網(wǎng)絡來縮短網(wǎng)絡和磁盤落盤的延遲以降低鏈路耗時，但這又引入了新的不確定性并導致了更高的成本。

GaiaDB 的解決思路是將事務和主從同步邏輯、日志邏輯、快照和存儲持久化邏輯重新組合和排布。

首先是將分布式協(xié)議的主從同步邏輯融合進數(shù)據(jù)庫計算節(jié)點中。由于計算層本身就需要處理主從同步、事務和一致性問題，相關的工作量增加并不大。這樣一來，最直接的收益就是將兩跳網(wǎng)絡和 I/O 精簡為一跳，直接降低了鏈路延遲。

其次 GaiaDB 將多層增量日志統(tǒng)一改為使用數(shù)據(jù)庫 Redo 物理日志，由 ?LogService 日志服務統(tǒng)一負責其可用性與可靠性。

除此之外，GaiaDB 也將持久化、快照和數(shù)據(jù)庫回放功能融合入存儲節(jié)點。由于存儲層支持了數(shù)據(jù)庫回放能力，可以很輕松實現(xiàn)數(shù)據(jù)頁級別的 MVCC。這樣全鏈路只剩下了數(shù)據(jù)庫語義，數(shù)據(jù)流簡單可靠，邏輯大大簡化。

下面我們一起來看下共識模型上的改變。

像 Raft 協(xié)議是需要兩跳網(wǎng)絡才能實現(xiàn)一次提交確認的，右上角就是 Raft 的數(shù)據(jù)流架構：CN 節(jié)點將寫發(fā)送給 Leader 后，需要等待 Leader 發(fā)送給 Follower 并至少收到一個返回后才能成功。

這里就帶來了兩跳網(wǎng)絡和 I/O 的同步等待問題。而 GaiaDB 則是計算節(jié)點直接發(fā)送給多個 Log 服務并等待多數(shù)派返回，這樣不依賴任何特殊硬件與網(wǎng)絡就降低了延遲。這樣系統(tǒng)里不管是事務的一致性還是多副本一致性，統(tǒng)一由計算節(jié)點統(tǒng)籌維護，所有的增量日志也統(tǒng)一為數(shù)據(jù)庫物理日志，整體數(shù)據(jù)流簡單可控。

對于數(shù)據(jù)風險最高的 Crash Recovery 場景，由于統(tǒng)一使用了數(shù)據(jù)庫語義，整體流程更加健壯，數(shù)據(jù)可靠性更高，降低了數(shù)據(jù)在多種日志邏輯之間轉(zhuǎn)換和同步帶來的復雜度風險。而在性能方面，由于存儲層自身具備回放能力，可以充分利用 LogService 層的日志緩存能力。對于寫操作來說，不需要每次更改都刷盤，可以批次回放刷盤，大大節(jié)省了磁盤吞吐與 I/O。

經(jīng)過以上改造，線上吞吐性能可以提升 40% 。同時由于鏈路簡化，也大大優(yōu)化了長尾延遲。像之前計算節(jié)點與分布式主節(jié)點之間發(fā)生網(wǎng)絡抖動的場景，就會被多數(shù)派的返回特性來優(yōu)化。

分享完一致性協(xié)議層優(yōu)化，接下來我們來探討一下鏈路層優(yōu)化。

我們知道，總吞吐與并發(fā)度成正比，與延遲成反比。一致性協(xié)議層改造并縮短了數(shù)據(jù)鏈路，可以通過降低延遲來增加吞吐。那么有沒有辦法通過提升數(shù)據(jù)流的并發(fā)度來提升吞吐呢？答案是可以。由于數(shù)據(jù)庫的物理日志自帶版本號與數(shù)據(jù)長度，所以不需要像通用存儲一樣實現(xiàn)塊級別串行提交。之所以使用通用存儲需要串行提交，是因為存儲端只能根據(jù)請求到達的先后確定數(shù)據(jù)版本，如果亂序到達，最后生效的版本是不可知的。

而對于 GaiaDB 來說，由于 LogService 具備數(shù)據(jù)庫語義的識別功能，所以計算節(jié)點只需要異步進行寫入，日志服務就會自動根據(jù)數(shù)據(jù)版本選取最新數(shù)據(jù)，然后根據(jù)寫入情況批量返回成功，這樣鏈路就可以實現(xiàn)延遲與吞吐的解耦。

當然計算層依然會等待日志層批量返回的最新落盤版本后再返回事務提交成功，所以依然可以滿足提交成功的事務一致性、持久化的要求。

另外針對高負載下 I/O 請求與數(shù)據(jù)庫業(yè)務請求爭搶 CPU 的問題，我們使用了 I/O 線程隔離技術，通過資源隔離的方式，將 I/O 線程與數(shù)據(jù)庫業(yè)務線程進行隔離。這樣即使在復雜負載場景下，I/O 延遲仍可以保持在較低水平。

在分析完前面兩部分之后，可能會有同學有疑問：既然日志層到存儲層不是同步寫，是不是最終系統(tǒng)的一致性降低了？有沒有可能發(fā)生數(shù)據(jù)丟失或不一致的問題呢？答案是不會。因為 GaiaDB 的存儲是一套支持 MVCC 的多版本系統(tǒng)。所以即使回放實現(xiàn)上是異步，但是由于請求方會提供所需要的數(shù)據(jù)版本，存儲層可以提供對應版本的強一致數(shù)據(jù)視圖。

GaiaDB 的存儲節(jié)點支持數(shù)據(jù)頁的回放功能，可以動態(tài)回放至任意目標版本后再返回，在之前的版本里，假如由于異步的因素還沒有獲取到這部分增量日志，存儲節(jié)點也會啟用優(yōu)先拉取的策略實時拉取一次日志后再回放，以此來提供較好的時效性。而在最新的 GaiaDB 版本中，我們也在計算層添加了同樣的回放能力，存儲節(jié)點盡力回放后仍不滿足需求的，由計算節(jié)點進行剩余任務。

這樣對于存儲慢節(jié)點的兼容能力就大大增強了，同時由于存儲節(jié)點會盡力回放，所以也可以最大化利用存儲層的算力資源。對于刷臟邏輯目前也完全下沉到了存儲層，存儲節(jié)點可以自主控制刷盤策略和時機，盡量合并多次寫后再進行落盤，大大節(jié)省了磁盤 I/O 負載，平均 I/O 延遲降低了 50%。

下圖中我們可以看到，在綜合了多項優(yōu)化后，讀寫性能實現(xiàn)了最高 89% 的提升，其中寫鏈路線路提升尤其明顯。這些都是在使用普通存儲介質(zhì)和網(wǎng)絡環(huán)境的情況下測試得出的，主要得益于數(shù)據(jù)鏈路的縮短與同步轉(zhuǎn)異步的自適應高吞吐能力。

在討論完性能后，再分享一下 GaiaDB 在高可用方面的思考和設計理念。

數(shù)據(jù)庫作為底層數(shù)據(jù)存儲環(huán)節(jié)，其可用性與可靠性直接影響系統(tǒng)整體。而線上情況是復雜多變的，機房里時時刻刻都可能有異常情況發(fā)生，小到單路電源故障，大到機房級網(wǎng)絡異常，無時無刻不在給數(shù)據(jù)造成可用性隱患。

作為商業(yè)數(shù)據(jù)庫，具備多級高可用能力是最核心的必備能力。這樣才能抵御不同級別的異常情況，有力保障客戶業(yè)務的平穩(wěn)運行。GaiaDB 支持多副本、跨可用區(qū)、跨地域三級別高可用，創(chuàng)新性地實現(xiàn)了多可用區(qū)熱活高可用、單個實例支持跨可用區(qū)部署。在不增加成本的情況下，每個可用區(qū)均可提供在線服務，任何可用區(qū)故障都不會打破存儲一致性。下面我們來分別看一下每個級別高可用能力的實現(xiàn)。

首先是實例的多副本高可用能力。

GaiaDB 對整體的分布式架構進行了重新設計，系統(tǒng)共分為三層，即計算層、日志層、存儲層。其中計算層本身無狀態(tài)，僅負責事務處理與一致性維護，所以獲得了很強的彈性能力，實現(xiàn)了秒級切換、多節(jié)點容災，同時擴縮容只需要內(nèi)存啟動即可。

日志層負責系統(tǒng)增量日志部分的持久化，實現(xiàn)了多數(shù)派高可用。同時由于一致性協(xié)調(diào)角色上移到了計算層，所以該層全對稱，任意節(jié)點故障不需要進行等待選主，也不會有重新選主帶來的風暴和業(yè)務中斷問題。

再往下是存儲層，負責數(shù)據(jù)頁本身持久化與更新。由于上層保留了增量日志，所以存儲層可以容忍 n-1 副本故障。簡單來說就是只要有一個副本完好，加上上層提供的增量日志，即可回放出所有版本的完整數(shù)據(jù)，實現(xiàn)了相比傳統(tǒng)多數(shù)派協(xié)議更高的可靠性能力。

其次是跨可用區(qū)與跨地域的高可用能力。

GaiaDB 的多級高可用都是基于存儲層物理日志的直接復制。相比邏輯復制，數(shù)據(jù)鏈路大大縮短，同步延遲也不再受上層大事務或者 DDL 等操作影響，在主從同步延遲上具有很大優(yōu)勢。

對于跨可用區(qū)高可用來說，由于 GaiaDB 具有對稱部署架構，所以可以很方便地進行跨可用區(qū)部署。這樣可以在不增加存儲成本的情況下實現(xiàn)多可用區(qū)熱活，任一可用區(qū)故障都不影響數(shù)據(jù)可靠性。

寫數(shù)據(jù)流可以自適應只跨一跳最短的機房間網(wǎng)絡，不需要擔心分布式主節(jié)點不在同機房帶來的兩跳跨機房網(wǎng)絡和跨遠端機房問題，而讀依然是就近讀取，提供與單機房部署接近的延遲體驗。由于跨機房傳輸?shù)木W(wǎng)絡環(huán)境更為復雜，GaiaDB 添加了數(shù)據(jù)流的鏈式自校驗機制，使數(shù)據(jù)錯誤可以主動被發(fā)現(xiàn)，保障了復雜網(wǎng)絡環(huán)境下的數(shù)據(jù)可靠性。

對于跨地域高可用來說，由于同樣使用了異步并行加速的物理同步，及時在長距離傳輸上，吞吐依然可以追齊主集群，不會成為吞吐瓶頸，在計入網(wǎng)絡延遲的情況下，國內(nèi)可以實現(xiàn)數(shù)十毫秒的同步延遲，這是因為跨地域同樣可以使用異步并行寫加速，自動適應延遲和吞吐之間的關系。同時地域之間還可以實現(xiàn)主動快速切換和默認就近讀取。

所以在使用了 GaiaDB 的情況下，業(yè)務可以不做復雜的數(shù)據(jù)同步邏輯就可以實現(xiàn)低成本的跨可用區(qū)與跨地域高可用。

介紹完高性能和高可用兩部分的設計理念后，接下來再介紹一下我們正在內(nèi)部灰度中的新功能：

并行查詢：并行查詢從并發(fā)度上進行加速的并行查詢能力，這對大數(shù)據(jù)規(guī)模下的多行查詢有非常好的加速作用，可以充分利用計算節(jié)點的 CPU 和內(nèi)存資源和分布式存儲層的并行 I/O 能力。

分析型從庫（HTAP）：分析型從庫具備多種行列加速能力，既有支持百 TB 級別數(shù)據(jù)計算的分析型節(jié)點解決方案，也有支持百萬行以上檢索加速的列式索引引擎。其中列式索引引擎同樣采用物理日志同步，不需要業(yè)務維護數(shù)據(jù)一致性，可以和當前交易類負載的事務隔離級別兼容。

Serverless：我們也在探索充分利用內(nèi)部潮汐算力的資源優(yōu)化調(diào)度方案，在白天業(yè)務高峰期，將資源向?qū)崟r性更強的交易類業(yè)務傾斜，在低峰期自動縮容，將資源復用投入到離線計算類業(yè)務中，不但客戶節(jié)省了運維成本與資源成本，也避免了資源閑置和浪費，實現(xiàn)了更高的資源利用率。

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

寫在最后

自 11 月 15 日起，百度智能云團隊每周三都會上線一節(jié)《百度智能云數(shù)據(jù)庫》系列云智公開課。在前 4 期的課程中，專家們圍繞“從互聯(lián)網(wǎng)到云計算再到 AI 原生，百度智能云數(shù)據(jù)庫的演進”、“高性能和多級高可用，云原生數(shù)據(jù)庫 GaiaDB 架構設計解析”、“面向金融場景的 GaiaDB-X 分布式數(shù)據(jù)庫應用實踐”、“一站式數(shù)據(jù)庫上云遷移、同步與集成平臺 DTS 的設計和實踐”四個主題展開了分享。

審核編輯：黃飛