Lakebase 將儲存與運算分離。 執行你查詢的 Postgres 引擎是無狀態的，你的資料則存在於一個獨立存在的持久儲存層中。 這種分離讓自動擴展、縮放至零、即時分支、讀取副本和快速備援成為可能。
為了展示 Lakebase 的改變，本頁從傳統的單機資料庫設計開始，說明 Lakebase 如何將同一設計拆分成獨立的圖層，以及每個部分的功能。
傳統資料庫的建置方式
在考慮 Lakebase 之前，先考慮它所取代的型號。 傳統的 Postgres 資料庫是一個整體。 一台機器會執行查詢引擎，將 先寫日誌（WAL） 和資料檔案寫入到連接在本地掛載點的磁碟上。 傳統上這些磁碟是真正的本地硬碟，屬於同一台機器，但隨著基礎設施發展，它們往往成為網路連接的儲存裝置。
WAL 與資料檔案扮演兩個互補的角色：
- WAL 加速寫入速度。 Postgres 會在確認提交前依序將每個變更附加到日誌中，這在單一磁碟上既快速又耐用。
- 資料檔案會加快讀取速度。 Postgres 將每個頁面的當前版本實體化成資料檔案，因此查詢可以讀取一列而無需重播日誌。
透過一台機器存取所有資料有缺點：
- 耐用度直接與該機器的物理基礎設施相關。 你還必須預先配置儲存，並預測工作量將成長多少，這不僅使成本管理與韌性規劃都變得複雜。
- 高可用性及多種水平擴展需要整個資料庫的實體克隆。
- 如果那台機器壞了，你可能會失去資料。 像 RAID 儲存這類技術能降低此風險，但額外的冗餘性可能大幅增加系統運行成本。
湖基建築
Lakebase 保留相同的職責，但將它們分為兩層獨立的層級：
- 一個執行標準、無狀態 Postgres 的 運算層 。
- 由安全管理員、分頁伺服器和雲端物件儲存組成的 儲存層 。
單體的兩個角色會直接對應到新的組件上。 加速寫入的 WAL 成為 保護者，負責擴展寫入。 加速讀取的速度資料檔案成為 分頁伺服器，負責擴展讀取。
由於資料存放於雲端物件儲存，而非單一機器，Lakebase 提供彈性、可擴展的計算與持久的寫入，跨區域複製。 沒有儲存空間需要配置：你只需支付你所佔用的儲存空間，且不必規劃像是硬碟用盡等故障模式。
此模型同時提升效能。 Lakebase 會將每個變更直接寫入多個位置，避免傳統撕寫保護和區塊對齊的負擔。 因為每次寫入都已經送到多個地點，無論是否啟用高可用性，效能都會保持一致。
下表將單體石碑的每個部分對應到湖基的對應部分。
| 傳統巨石碑 | Lakebase | 角色 |
|---|---|---|
| 單一電腦 | 無狀態運算 | 運行 Postgres 查詢引擎 |
| 本地 WAL 磁碟 | 保管人 | Durably 記錄每一個已提交的變更 |
| 本地資料檔案 | 分頁伺服器與物件儲存 | 實體化並儲存頁面版本 |
計算層
運算層執行 Postgres。 它僅儲存暫時狀態：Postgres 共享記憶體中的緩衝區，並有一個由快速本地磁碟支援的本地運算快取。 它不擁有持久的資料。
因為計算不擁有持久狀態：
- 它可以被替換、重新啟動、自動調整，或縮放到零，而不會移動或遺失資料。
- 它不是寫入本地檔案系統，而是將 WAL 串流到儲存層。
- 多個運算實例可以連接到同一儲存層，這也是 Lakebase 讀取 副本 和 快速故障轉移 的方式。
儲存層
儲存層具有耐用性，且可獨立於運算運作。 它包含三個組成部分。
保管人
Safekeepers 是 WAL，從單一機器中抽出，並高度可用。 當 Postgres 產生 WAL 紀錄時，會將這些資料串流給一群安全管理員，這些保管者會利用基於 Paxos 的共識協議在法定人數內複製日誌。
當一群安全管理員確認 WAL 記錄時，交易即構成承諾，而非單一機器完成本地 fsync。 耐久性來自節點間的複製，而非單一磁碟。
分頁伺服器
分頁伺服器是從 WAL 中擷取並重建的資料檔案。 分頁伺服器會從安全管理者處接收 WAL 串流，並按需實現頁面版本。 當計算請求特定日誌序號（LSN）的頁面時，分頁伺服器會重建並回傳該頁面。
分頁伺服器作為物件儲存之上的寫入快取。 它們會非同步地將實體化的頁面持續存在到雲端物件儲存，且頁面重建不會阻擋交易提交。
雲端物件記憶體
雲端物件儲存是整個儲存層的耐久性基礎。 它保存分頁伺服器持續存在的頁面資料。
喺 Azure 上，Lakebase 會將數據持久化到 Azure Blob 儲存體.
物件儲存則避免進入熱查詢路徑。 只有分頁伺服器會讀取它。 關於儲存冗餘的運作方式及其獨立於計算高可用性設定，請參見 儲存架構。
寫作的運作方式
寫入從計算流經儲存層：
- Postgres 會修改受影響的記憶體頁面並產生 WAL 記錄。
- Compute 會將 WAL 紀錄串流給 safekeepers。
- 當一群安全保管者確認紀錄時，交易即提交，客戶端獲得成功。
- 分頁伺服器會非同步套用 WA，並將更新的頁面持久化到物件儲存。
只要有足夠多安全保管人取得 WAL 紀錄，交易即為持久，因為僅有日誌即可重建資料。 分頁伺服器會在之後重建並儲存資料頁，置於提交路徑之外，因此寫入保持快速且不危及任何已提交變更。
閱讀的運作方式
讀取檢查快取的階層，從最快到最慢，並在包含該頁面的第一層停止：
- 緩衝池（記憶體）： Postgres 共享計算記憶體中的緩衝區。
- 本地運算快取： 運算節點上的磁碟備份快取，大小相對於運算記憶體大小。
- 分頁伺服器： 快取未命中時，計算會向分頁伺服器請求該頁面，伺服器會在請求的 LSN 上重建該頁面。
- 物件儲存： 分頁伺服器在需要時會從物件儲存內部讀取資料。 查詢不會直接到達物件儲存。
這種架構所能實現的功能
將無狀態運算與持久儲存分離，是 Lakebase 多項功能得以實現的原因：
| Feature | 它所帶來的意義 |
|---|---|
| 自動調整 | 由於運算是無狀態的，Lakebase 會根據工作負載調整運算大小，且不會移動資料。 |
| 縮減至零 | 運算可以完全暫停，當儲存空間持續存在時，資料則會立即可用。 |
| 即時分支 | 幾秒鐘內建立一份獨立且可寫入的資料庫副本。 由於分支是針對共享儲存的寫入複製元資料操作，因此不會重複資料。 |
| 讀取複本 | 多個運算實例會從同一儲存層讀取資料，因此副本不需要資料複製，且幾秒鐘內即可啟動。 |
| 點點查詢 | 由於儲存層會保留歷史，運算可以附加到過去的某個時間點，並讀取當時存在的資料庫，而不必將資料複製回原位。 |
| 快速故障切換 | 故障轉移會推動一個次要運算實例，該實例會附加到現有儲存空間，且無需資料移動。 |
| RPO = 0（無已提交的資料遺失） | Lakebase 會持續記錄每一筆已提交的交易，然後才確認，因此當計算失敗、重啟或縮放到零時，你不會失去已提交的資料。 |
此架構如何支援 LTAP
由於 Lakebase 會將所有已提交的變更永久儲存在雲端物件儲存中，因此相同的資料可以在交易中同時服務分析工作負載，而無需獨立的複製管線。 這是 Lake 交易與分析處理（LTAP）的基礎，單一資料副本即可同時支援交易與分析引擎。 欲了解 LTAP 如何建立在此架構上，請參閱 LTAP 架構。