雲端資料庫

從單體到解構:雲端資料庫的解構式架構(Disaggregated Systems)深度解析

作者

該內容精準地將複雜的分佈式系統演進邏輯簡化為可理解的層次,其對 Paxos 角色與現代解構架構的類比極具洞察力,展現了高水準的技術整合能力。然而,文章對於『亞穩態故障(Metastable Failures)』的提及僅點到為止,缺乏具體的失效模式分析,在風險評估的深度上仍有保留空間。

從單體到解構:雲端資料庫的解構式架構(Disaggregated Systems)深度解析

在傳統的資料庫設計中,我們習慣將運算(Compute)與儲存(Storage)封裝在同一個伺服器節點中。然而,隨著雲端經濟(Cloud Economics)的推動,這種「緊耦合」的模式已成為效能與成本的瓶頸。本文將深入探討所謂的「解構式架構」(Disaggregated Systems),以及它如何改變現代雲端資料庫的運作邏輯。

什麼是解構式架構?

簡單來說,解構式架構就是將運算資源(CPU、記憶體)與儲存資源(磁碟、狀態)完全分離,使其能夠獨立擴展。

為什麼需要解構?這源於運算與儲存之間天然的「阻抗失配」(Impedance Mismatch): 成本差異:運算資源昂貴,儲存資源相對便宜。 需求波動:運算需求波動劇烈(例如電商大促),但儲存需求通常是穩定且持續增長的。 狀態特性:運算是無狀態的(Stateless),可以隨時啟動或關閉;儲存本質上是有狀態的(Stateful),必須確保持久化。

如果將兩者綁在一起,當你只需要更多儲存空間時,你不得不被迫購買更多不需要的 CPU,這違反了關注點分離(Separation of Concerns)原則,也增加了客戶的成本。

解構式架構的技術演進

資料庫架構經歷了三個主要階段:

第一階段:單體架構(Monolithic) 這是最傳統的模式,一個進程對應一個磁碟,所有 I/O 都在本地完成。例如標準的 MySQL 或 PostgreSQL 安裝。

第二階段:雲端複製架構(Cloud-Replicated) 為了實現高可用性,我們在單體之上加上 Paxos 或 Raft 等共識演算法,形成複製組(Replicated Groups)。雖然解決了可用性,但運算與儲存依然綁在同一個盒子裡,導致儲存冗餘過高(例如 EBS 已有三副本,資料庫層又做三副本,造成極大浪費)。

第三階段:解構式架構(Disaggregated) 將運算層(Ephemeral Compute)與儲存層完全分離。儲存層進一步細分為日誌儲存(Log Store)與頁面儲存(Page Store)。運算層變成了輕量級的彈性服務,透過高速網路與儲存層溝通。

實務案例分析

目前的雲端資料庫如 Amazon Aurora、Alibaba PolarDB、Google AlloyDB 均採取此路徑。其核心邏輯在於「日誌即資料庫」(The Log is the Database):

在 Aurora 的設計中,主節點(Primary)不直接將完整的資料頁寫入儲存,而是僅發送重做日誌(Redo Log)。儲存節點端擁有部分 CPU 能力,負責將日誌物化(Materialize)為資料頁。這樣做極大地減少了網路傳輸量,將網路瓶頸降到最低。

而在 PolarDB 中,則利用 RDMA(遠端直接記憶體存取)等高速網路技術,將狀態頁直接推送到儲存層,並透過平行 Raft(Parallel Raft)提升吞吐量。

解構與 Paxos 的深層聯繫

一個有趣的觀點是,Lamport 在定義 Paxos 演算法時,其實已經預言了解構式架構。Paxos 定義了三個角色: 1 Proposer(提議者):負責排序,對應現代架構中的運算層(Compute)。 2 Acceptor(接受者):負責持久化投票,對應日誌儲存(Log Store)。 3 Learner(學習者):負責物化狀態並回應,對應頁面儲存(Page Store)。

過去我們為了實現「無共享架構」(Shared-nothing),將這三個角色強行擠在同一個節點中(如 Raft 的實作)。現在,我們重新將其拆分,讓每個角色專精於自己的任務,從而大幅提升系統的整體吞吐量。

解構後的挑戰與權衡(Trade-offs)

解構並非沒有代價,最大的挑戰在於「網路變成了新的瓶頸」。

遠端 I/O 的延遲通常比本地 SSD 高出三倍,頻寬則低四倍。為了緩解這個問題,工程師通常採取以下策略: 1 緩衝與預取:在運算層建立大容量緩衝區,並根據存取模式預先抓取資料。 2 快速織網(Faster Fabrics):採用 RDMA 或 CXL(Compute Express Link)。CXL 尤為重要,它讓 CPU 能將遠端記憶體視為本地記憶體,延遲比 RDMA 低六倍。 3 計算下推(Pushdown Computation):不要把所有資料搬到運算層,而是將過濾(Filter)或聚合(Aggregate)的邏輯下推到儲存節點執行,只回傳結果,減少網路流量。

未來趨勢:邁向 Serverless 與自我組裝

解構式架構是實現真正 Serverless 資料庫的基石。因為運算層變成了無狀態的,工作節點(Worker)可以隨時出現或消失,而不會導致資料遺失。

未來的方向將是「織網感知資料庫」(Fabric-aware Databases),系統能根據工作負載(例如 AI Agent 帶來的極端突發流量)自動配置運算、記憶體與儲存資源,實現自我組裝(Self-assembling)。

總結

解構式架構將資料中心視為一台巨大的電腦,網路則是其背板(Backplane)。雖然增加了系統複雜度與潛在的亞穩態故障(Metastable Failures)風險,但它帶來的彈性擴展、成本優化與故障隔離,使其成為現代雲端基礎設施的必然選擇。

來源:infoq.com - Parting the Clouds: The Rise of Disaggregated Systems

本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理,並非原文逐字翻譯。