以下文章來源於 InfoQ，作者曹偉（鳴嵩）

眾所周知，在資料庫的歷史上，每次儲存介質的變化都會引發軟體的變革。從 SAN 儲存到 SSD 到大記憶體到 NVM，都觸發了資料庫核心從理論到工程的演進。

資料庫一直是推動企業數字化和創新的最重要基礎設施之一。從關係型資料庫到 NoSQL 資料庫、分析型資料庫、多模資料庫，這個領域正在持續地進化與變革，湧現了大量的新型資料庫產品，滿足不同企業的應用場景和細分市場需求。

然而，關係型資料庫（Relational Database Service，簡稱 RDS）依然佔據了資料庫整體市場的大半壁江山，根據 IDC 近期釋出的《2023 年上半年中國關係型資料庫軟體市場跟蹤報告》，2023 年上半年中國關係型資料庫軟體市場規模為 17.5 億美元，其中公有云關係型資料庫的市場份額約為 59%。而根據 Garnter 《Forecast Analysis: Database Management Systems, Worldwide》報告中的預測，2023 年全球關係型資料庫總市場達到 838 億美元，在資料庫總盤子裡公有云部分佔比也約為 59%。

RDS 通常以雲盤（即塊儲存）作為其核心儲存基礎設施。AWS 的 RDS 服務便是一個例子，其所有例項規格均採用了 Elastic Block Store（EBS）雲盤。對於廣泛使用 RDS 的使用者，以及在公共雲上購買虛擬機器來自建資料庫服務的使用者，雲盤是否就代表了儲存的最終選項呢？答案是“No”。在技術革新缺席的前提下，雲盤在價效比和計費策略方面失去了其競爭優勢，我們判斷其會從雲廠商的主導產品降級為邊緣選項。

公共雲的關係型資料庫將會從依賴雲盤向利用好物件儲存，向採用更加雲原生的架構的新時代邁進。為了適應物件儲存，充分發揮其優勢，資料庫的架構也勢必需要進行大刀闊斧的改造，水平擴縮容、容災技術以及儲存引擎的資料格式都將隨之變化。

一、雲盤存在的問題

雲盤的 第一個痛點是定價比較高。例如，一塊 1TB 的標準型雲盤（含 5 萬 IOPS 及 350MB 頻寬），雲服務商會收取約 1000 元每月的基礎費用。為了服務海量的客戶基數，雲盤的 IOPS（輸入 / 輸出操作每秒）和頻寬通常會在軟體上透過流控進行限制，免費的 IOPS 額度通常在 1000 至 3000 之間，而頻寬限額大約在 150MB/s。超出這些限額，使用者則需要向雲廠商購買額外的 IOPS 和頻寬，若要將 IOPS 提高至 10 萬（這一效能水平對於企業級 NVMe SSD 來說並不算特別高），使用者需要額外支付 1500 元每月的預配置效能費用。然而，1TB 的企業級 NVMe SSD 的一次性購買成本還不到千元。

第二個限制是雲盤的彈性尚未完全向使用者開放。主流雲廠商的雲盤僅支援擴容，不支援縮容。這一限制導致業務在進行縮容時必須採取曲線救國的策略，即透過邏輯複製的方式，先將資料遷移到一塊容量更小的新雲盤上，然後才能釋放原有的較大雲盤。另外，部分雲廠商，例如 AWS 的 EBS 對控制面還存在限流保護，限制每兩次擴容操作之間必須間隔六小時。這樣的措施雖然保證了服務的穩定性，但也在一定程度上限制了使用者對儲存資源的即時調整能力。這些都限制了上層軟體基於雲盤實現按儲存使用量付費的能力。

雲盤的 第三個侷限性在於其災難恢復能力侷限於單個可用區（AZ）。雲廠商建議，為了實現業務連續性，客戶應該採取跨可用區的災難恢復策略。這意味著，如果客戶想要為他們的資料庫實現跨 AZ 的災難恢復，他們不得不購買多個雲盤。然而，這種額外投資並非最經濟的選擇，因為雲盤定價已經包含了單 AZ 多副本資料的成本。當使用者為了實現跨 AZ 的冗餘而購買更多雲盤時，儲存層面的多副本與資料庫層面的多副本機制疊加在一起，便產生了資源上的重複配置。

最後，在面對高效能資料庫需求時，雲盤的效能也會成為限制整體系統效能的 薄弱環節。雲盤使用分散式架構，透過 Erasure coding 機制將資料分割成多個小片段，並將其冗餘儲存在多個伺服器上。進一步的，還可以對資料進行壓縮。這些技術以犧牲一定的效能為代價，換來了顯著的可擴充套件性和成本效益。由於所有 I/O 操作都需要跨越網路，因此雲盤的延遲通常比本地盤高一個數量級。

旗艦資料庫產品如 Aurora 和 PolarDB 採納了更新的設計理念，構建了定製化的分散式儲存叢集，來解決雲盤的效能問題。Aurora 採用了日誌即資料庫的理念來減少資料庫節點與儲存節點之間的資料傳輸量，PolarDB 則使用 RDMA 和 NVM 來最佳化 I/O 延遲，兩者都支援多個資料庫節點併發訪問儲存節點的共享資料架構。然而，這些儲存系統與資料庫之間的通訊是透過私有介面實現的，並不對外部使用者開放。另外這些專用儲存的定價比雲盤更高。

二、其他的雲端儲存選項

和雲盤相比，雲上的本地盤例項儲存價效比要高很多。例項儲存採用了類似於 SR-IOV 和 SPDK 的高效虛擬化技術。因此例項儲存的延遲和頻寬都接近於物理 SSD 的效能。例項儲存的價格也經濟很多，折算下來 1TB 例項儲存每月的單價在 300 元以下。然而，例項儲存在資料永續性方面存在侷限。由於其設計為單副本儲存，如果宿主機發生故障，儲存在其中的資料可能會丟失。此外，當虛擬機器遷移至另一臺宿主機時，例項儲存中的資料也將被清除。因此，例項儲存不適合在需要高可靠性和資料永續性的應用場景中作為主要儲存介質。

物件儲存的價格是最低的，1TB 一個月的儲存成本約為 120 元。低定價得益於其軟硬體的協同最佳化。在軟體層面，採用更激進的 EC 和壓縮演算法來提高儲存密度；而在硬體方面，透過使用高密度盤和專用伺服器，進而降低伺服器、機架及電力的均攤成本。物件儲存系統還利用定製的 FPGA 硬體來減輕 CPU 處理網路和資料的壓力。在資源排程上，物件儲存一般會採用大叢集的部署方案，這有利於降低碎片率，提高系統的整體水位線。得益於其分散式大資源池的設計，物件儲存能夠支援 10Gb 乃至 100Gb 的訪問頻寬。此外，物件儲存通常還具備跨可用區域（AZ）的災難恢復能力。

物件儲存的缺陷是其延遲比較高，首位元組訪問延遲可能高達數十毫秒。這一問題部分源於早期物件儲存解決方案通常使用 HDD 作為儲存媒介，並且在軟體層面，I/O 請求的排隊處理也會造成一定延遲。然而，高延遲並非物件儲存的本質缺陷，而是由於成本考慮和產品定位所做的權衡。

實際上，在技術層面，構建低延遲的物件儲存系統是完全可行的。例如最近在 AWS Reinvent 大會上亮相的 "S3 Express One Zone" 服務，將延遲減少至原先的十分之一，實現了毫秒級的響應速度，接近傳統檔案儲存 NAS 系統的水平。剛才說了，S3 的高延遲是產品定位和技術的權衡，有得必有失，"S3 Express One Zone" 不再支援跨 AZ 容災，所有資料都在單 AZ 內，資料的永續性下降。此外 "S3 Express One Zone" 是更強了，也更貴了，其價格不僅是 S3 標準版的 7 倍，也超過了自家雲盤，達到 EBS gp3 的 2 倍。

三、解法：永續性與延遲的解耦

用一張圖可以總結下幾個雲端儲存產品各自的特點和不足：

可以看到，當前市場上尚未出現一種雲端儲存產品，可以同時在低成本、低延遲、高永續性幾個維度上都達到令人滿意的程度。

隨著雲端計算的漸進普及，降低成本逐漸成為使用者的首要訴求，一些公司，比如 37signals 和 X，已經基於成本效益的考量決定下雲，從公共雲平臺轉回到傳統的 IT 基礎設施。在這種趨勢下，雲資料庫服務供應商面臨的緊迫挑戰是如何在現有的儲存 IaaS 產品基礎上，構建更有成本競爭力的資料庫服務。

一個方案是基於例項儲存搭建多副本的資料庫系統。前文說過，例項儲存是單副本儲存，它存在一個風險：一旦託管它的宿主機發生故障或者相應的虛擬機器遷移，就可能導致資料丟失。這一方案的理論基礎建立在一個假設之上：多個例項儲存丟失資料的機率是相互獨立的。基於這個假設，增加副本數量，會降低多個例項儲存同時丟失資料的機率。

然而，這個假設並不總是成立，在現實裡，因為工程的限制，多個例項儲存可能會因為共同的原因導致同時資料丟失。例如，可能所有儲存都使用了同一批次存在韌體缺陷的 SSD，導致多臺主機同時下線；或者，雲服務提供商的控制系統發生故障，引起大規模的虛擬機器遷移。因此，對於那些對資料永續性有極高要求的生產環境來說，這種方案並不適用。

另一個方案是將儲存的永續性和延遲兩個特性進行分離，透過物件儲存實現高永續性，透過例項儲存 / 雲盤來實現低延遲。儘管物件儲存可以提供低成本、高頻寬和跨可用區的資料永續性，但在作為關係型資料庫主儲存時，它的讀寫延遲成為了一個顯著的挑戰。為了解決這一問題，我們採用一種分層儲存策略，將儲存解耦為三個元件：持久化、寫快取和讀快取，分而治之。

在這種設計中，物件儲存僅負責資料的持久化，為系統提供災難恢復保證。寫操作會透過快取層降低寫延遲，技術上可以利用如 Raft 這類同步協議，快取到低延遲的儲存介質，例如本地磁碟或雲盤，甚至可以考慮追加寫入到訊息佇列服務。讀操作也是，透過快取層降低讀延遲，可能是基於本地磁碟、NAS，或者是專為降低延遲而最佳化的物件儲存加速器，將負責實現快速的資料載入。

我在 2021 年 SIGMOD 發表的 "LogStore: A Cloud-Native and Multi-Tenant Log Database" 論文中就使用了這一方案。LogStore 是一個內部使用的雲原生日誌資料庫，底層採用物件儲存，為了降低寫入延遲，寫入的日誌先透過 raft 協議刷到 3 副本的本地 SSD 中即提交，再由 Leader 節點將資料寫入到物件儲存中。

矽谷初創公司 Neon 也採用了這一方案。Neon 宣稱是開源版本的 Aurora Postgresql，採用計算與儲存分離架構對開源的 PostgreSQL 資料庫進行改造。其儲存層由 Safekeeper 和 PageServer 兩個元件構成。Safekeeper 負責持久化和複製 WAL 記錄，使用 Paxos 協議實現分散式一致性，將 WAL 記錄儲存在 EBS 上，並將提交的 WAL 記錄傳遞給 PageServer。PageServer 負責將 WAL 記錄應用到 Page 上，生成 Page 的快照，並將 Page 儲存在物件儲存中，快取 Page 在例項儲存上，以提高讀取效能。在 Neon 的實現中，資料庫的主儲存是物件儲存，寫快取是 EBS，讀快取是例項儲存。

四、新的商業模式契合物件儲存

近年來，公共雲資料庫服務正日益傾向於提供 Serverless 執行模式，以迎合現代開發者對彈性的需求。早在 18 年，AWS 就推出了 Aurora Serverless，22 年，AWS 又推出了 Aurora Serverless V2。在今年的 AWS Reinvent 大會上，AWS 一口氣釋出了三款 Serverless 資料庫產品：Aurora Limitless Database、ElastiCache Serverless 和 Redshift Serverless，已經隱約擺出了全系產品 Serverless 化的架勢。

Serverless 資料庫之所以深受青睞，一方面是因為其低門檻的使用成本，另一方面則是因為其能夠在面臨突如其來的機會時提供快速且靈活的擴充套件能力。因此，Serverless 資料庫成為了初創公司和那些流量增長高度不可預測的創新產品的理想選擇。

本質上 Serverless 資料庫採用了一種”按實際使用付費 (pay as you go)“的新商業模式。在 Serverless 資料庫模式下，雲的 dbPaaS 軟體會實時追蹤使用者的活動，從而精確計算其資源使用情況。無論是執行 SQL 命令所消耗的 CPU 時間，還是讀寫操作產生的 IO 次數，亦或是資料儲存的總量，所有這些都被量化為資源單位（例如計算單元 CU、請求單元 RU），並據此計費。技術如何支撐這種新的商業模式，比如資料庫如何根據工作負載的變化智慧的擴縮容取決於 dbPaaS 和核心的實現。

在業界實現 Serverless 架構的常見方法之一是透過給基於計算與儲存分離的架構增加自動伸縮（Auto-Scale）功能。因此雲原生資料庫如 Aurora 和 PolarDB 都能比較快的推出其 Serverless 版本。在這樣的架構下，儲存層通常設計為多租戶模式，以實現資源共享和成本效率；而計算層則通常是單租戶的，確保了效能和隔離性。隨著資料庫負載的增加，這種模式允許計算節點透過彈性擴容迅速提升處理能力。相對地，當負載減少時，計算節點可以彈性縮容，甚至完全停止，以最佳化資源使用並減少成本。

CockroachDB 也採納了這種 Serverless 架構。為適應這種模式，他們對底層的 KV 儲存層進行了重構，轉變為支援多租戶的架構，並且 SQL 節點和 KV 節點不再執行在同一臺服務上，走向計存分離架構。

由此可見，儲存池化是 Serverless 資料庫架構中的核心設計原則。只有透過儲存池化，才能做到按儲存的使用量計費。雲廠商的產品 Aurora 和 PolarDB 實現這一機制的策略是構建他們自己的分散式儲存叢集。然而，這種做法要求雲廠商在產品推出前進行大規模的一次性投資，並且在產品初期推廣階段承受由於儲存使用未達預期而產生的潛在虧損。

然而，對於那些希望利用開源軟體自行搭建 Serverless 資料庫服務的大型企業使用者、以及提供 Serverless 資料庫服務的小型的第三方資料庫廠商來說，卻存在一個潛在的陷阱。如果構建 Serverless 服務之前需要首先投資搭建一個儲存池，他們就陷入了傳統模式——即預購硬體並在其基礎上構建資料庫服務，這種做法與 Serverless 的理念相悖。最理想的技術方案是做到不囤貨，實際使用多少儲存，就向雲廠商付多少儲存費用。

此外，Serverless 資料庫的設計理念自然包含了 Region 級別的容災功能，這是其另一項核心能力。使用者選擇 Serverless 服務，意味著他們已經不再關注執行資料庫的具體伺服器或所在的可用區（AZ）。在這種服務模式下，使用者不太願意去單獨從三個不同的 AZ 購買一套 Serverless 資料庫，再手動設定資料同步——這種方式與 Serverless 的易用性相悖。因此，Serverless 資料庫必須確保其計算節點池和儲存池都在跨 AZ 環境中提供無縫的容災能力。

儲存池化、按使用量計費，以及 AZ 級的災難恢復，Serverless 資料庫對儲存的需求正是物件儲存產品的關鍵特性。而傳統雲資料庫使用的雲盤在成本、彈效能力、容災能力上均弱於物件儲存產品。基於這些考量，我們預見在按使用量計費這種新的公共雲商業模式被廣泛接受後，未來的 Serverless 資料庫都會把物件儲存做為優先選擇。

五、展望：以物件儲存為中心的新架構

隨著資料庫儲存基礎設施向物件儲存的逐步遷移，我們還可以預期新架構裡會出現以下幾個方面的變化：

1. 行列混合儲存格式

資料庫儲存引擎的資料格式將從純行存向行列混合格式變化。基於 B+ 樹的儲存引擎可以採用調高資料頁大小，並採用頁內列式儲存的技術來實現。而基於 LSM 的儲存引擎在這塊具有更大優勢。

將行存資料轉換為 Pax 格式（行列混合儲存格式）存入物件儲存有多重好處：

首先，它顯著降低了儲存成本並減少了資料載入所需的時間。例如，以行列混合儲存格式進行資料轉換，可以將 1TB 的資料壓縮到僅為原始體積的 20% 至 40% 儲存在物件儲存中。藉助 25Gb 的內網頻寬，載入並預熱這些壓縮資料到快取的過程大約只需要 100 秒。

其次，採用 Pax 格式還能減少資料庫記憶體快取的消耗，比如說原來計算節點需要 32GB 的記憶體，現在只需要 12GB 記憶體就能達到同樣效能了，進一步的降低計算節點成本。

最後，資料庫引擎可以藉助 Pax 格式實現混合事務 / 分析處理（HTAP），Google 的 Spanner 資料庫就是一個例證，它採用了基於 Pax 的 Ressi 儲存格式，支援 HTAP 操作。

2. OLTP 與資料湖的深度融合

傳統上，將線上事務處理（OLTP）資料遷移到線上分析處理（OLAP）系統的常規方法依賴於 ETL（提取、轉換、載入）流程。然而，ETL 的過程不僅管理負擔重，而且增加了一個容易發生錯誤的環節。鑑於這些挑戰，近年來業界出現了向"NoETL"解決方案的轉變，將 ETL 過程內建在資料庫中，以提高使用者進行資料管理和分析的易用性。例如去年 AWS 推出了從其 Aurora 服務直接到 Redshift 資料倉儲的 NoETL 整合。

而在 OLTP 資料庫核心中，原生支援將全量資料以行列混合儲存格式持久化並寫入物件儲存，會更近一步，促進 OLTP 資料庫與現代資料湖技術的協同工作。利用技術如 Iceberg、Hudi 和 Delta Lake，OLTP 資料庫可以無縫地將線上資料直接寫入資料湖環境，幫助企業能夠更簡單、實時地管理和分析其資料資產。

3. 使用 K8s 管理資料庫變得普及

自從 K8s 問世以來，管理有狀態服務，尤其是資料庫，一直是個充滿挑戰的領域。一方面，隨著 KubeBlocks 以及各種資料庫 Operator 等開源的資料庫控制面管理軟體的發展，我們擁有越來越多的工具支援在 K8s 上對資料庫進行高效管理。此外，當資料庫的永續性是透過 K8s 外部的物件儲存來保證時，對 K8s 中的資料庫 Pod 進行高可用切換、節點遷移、資料遷移、備份等各種管理任務的複雜性會得到進一步減輕，執行效率也會更高。兩個方向的發展相輔相成，會推動在 K8s 上管理資料庫的普及。

公共雲中的關係型資料庫正處在一個轉型的臨界點，即從依賴雲盤向利用物件儲存的新時代邁進。過去的 RDS 模式是雲託管，客戶需要預先選擇硬體配置（雲伺服器、雲盤、VPC 和負載均衡器），然後在這些硬體上部署資料庫核心。而在物件儲存時代，沒有預置 IaaS 的限制，資料庫核心進一步雲原生化更有彈性更加強大，這會是資料庫領域近期最大的技術變革。

關於作者

曹偉（鳴嵩），雲猿生資料創始人 & CEO，發起了開源雲原生資料庫管控平臺 KubeBlocks 專案。前阿里雲資料庫總經理 / 研究員，雲原生資料庫 PolarDB 創始人。中國計算機學會資料庫專委會執行專委，中國計算機學會開源專委會執行專委，獲得 2020 年中國電子學會科技進步一等獎，在 SIGMOD、VLDB、ICDE、FAST 等資料庫與儲存國際學術會議發表論文 20 餘篇。

資料庫的下一場革命：S3 延遲已降至原先的 10%，雲資料庫架構該進化了