簡介：在3月2日的阿里云開源 PolarDB 企業(yè)級架構發(fā)布會上，阿里云 PolarDB 內核技術專家北俠帶來了主題為《PolarDB 總體架構設計和企業(yè)級特性》的精彩演講。

在3月2日的阿里云開源 PolarDB 企業(yè)級架構發(fā)布會上，阿里云 PolarDB 內核技術專家
北俠帶來了主題為《PolarDB 總體架構設計和企業(yè)級特性》的精彩演講。主要分享了存儲計算分離架構、HTAP架構、節(jié)點高可用架構是PolarDB 可支持的三種架構，PolarDB還具備可用性、高性能、安全的企業(yè)級特性。并對PolarDB 總體架構和企業(yè)級特性進行展開分析。

直播回顧視頻：開源PolarDB企業(yè)級架構重磅發(fā)布-阿里云
PDF下載：?文件下載-阿里云開發(fā)者社區(qū)

以下根據(jù)發(fā)布會演講視頻內容整理：

PolarDB 是阿里云自主研發(fā)的云原生數(shù)據(jù)庫，它的源代碼已經(jīng)全部開源（源碼倉庫地址：https://github.com/ApsaraDB/PolarDB-for-PostgreSQL?）。下面將為大家詳細解讀開源 PolarDB 的總體架構和企業(yè)級的特性。

一、PolarDB總體架構設計

PolarDB 的基礎架構是云原生架構。傳統(tǒng)數(shù)據(jù)庫由主庫、備庫和一個 Standby節(jié)點構成，主庫復制redo日志到備庫。傳統(tǒng)數(shù)據(jù)庫的架構存在以下四個問題：

① 擴展性差。增加節(jié)點的時候需要先將數(shù)據(jù)完整復制，花費的時間通常是小時級別甚至更長。

② 可靠性差。主庫和備庫之間需要采用同步復制，會導致性能下降大概 20% 以上；如果采用異步復制，則會發(fā)生數(shù)據(jù)丟失的風險。

③ 可用性差。主庫發(fā)生了故障后， HA 會切換到備庫。新的備庫需要回放大量 redo 日志才能進入可服務的狀態(tài)，該過程可能需要分鐘級別的耗時。

④ 成本高。存儲成本會隨著節(jié)點數(shù)目的增加而呈線性增加，此外還需要預留一些資源。

為了徹底解決以上問題，PolarDB提出了云原生的架構，將計算和存儲資源解耦。

上圖左側是傳統(tǒng)的數(shù)據(jù)庫，它的 CPU 、內存、存儲都在一臺服務器上，稱作計算存儲一體化。右側是 PolarDB 的架構，它分成了計算節(jié)點和存儲節(jié)點兩種類型的節(jié)點。數(shù)據(jù)存儲在由存儲節(jié)點構成的存儲池里，各個計算節(jié)點通過高速網(wǎng)絡讀取存儲池中的數(shù)據(jù)。

計算存儲分離的架構的優(yōu)勢在于以下幾個方面：

① 極致的、彈性的擴展能力：存儲和計算能夠分別獨立地擴容。

② 降低存儲成本：那么計算集群擴展到多少個，數(shù)據(jù)始終只有一份。

③ 易用性：具備分布式的優(yōu)勢和單機數(shù)據(jù)庫的體感，因為每個計算節(jié)點都能看到所有數(shù)據(jù)。對于用戶來說，任何一個計算節(jié)點就相當于是一個單機數(shù)據(jù)庫。

④ 可靠性比較高：底層共享存儲提供了三副本以及秒級快照的功能，為數(shù)據(jù)庫的備份提供了比較便捷的方式。

PolarDB 不僅設計研發(fā)了計算存儲分離的架構，還在在數(shù)據(jù)庫的模塊棧上進行了大量優(yōu)化。

在事務層，實現(xiàn)了 CSN 快照來代替?zhèn)鹘y(tǒng)的事務快照；在日志層，實現(xiàn)了 LogIndex 這樣核心的數(shù)據(jù)結構，解決了在計算存儲分離架構下遇到的特有的過去頁面以及未來頁面的數(shù)據(jù)問題，同時實現(xiàn)了延遲回放和并行回放；在緩存層，實現(xiàn)了常駐的 BufferPool 和多版本頁面；在存儲層，實現(xiàn)了 DirectIO 模型頁面的預讀和預擴展的能力。

此外，用戶還經(jīng)常需要對 TP 事務的數(shù)據(jù)進行復雜的分析查詢，比如在夜里做匯總報表和對賬。此類查詢一般都是一些非常復雜的 SQL ，但并發(fā)不高，是典型的 OLAP 場景。

最初 PolarDB 的計算存儲分離架構在處理這類復雜的 SQL 時，只能由單個計算節(jié)點來計算，無法發(fā)揮出計算集群的整體算力，同時也沒有辦法發(fā)揮出存儲池大帶寬的特性。

當時業(yè)界的解決方案通常有兩類：

① 在原有的 TP 系統(tǒng)外面部署一套 AP 系統(tǒng)，將 TP 的事務數(shù)據(jù)通過日志導入到 AP 系統(tǒng)。此方案存在的問題在于兩個系統(tǒng)之間的延遲比較高，會導致數(shù)據(jù)的新鮮度不高。另外，部署一套獨立的 AP 系統(tǒng)會導致存儲和運維的成本增加。

② 在原有的 TP 系統(tǒng)上就地執(zhí)行 AP 查詢，但這勢必會造成 TP 和 AP 兩種業(yè)務互相影響。另外， AP 系統(tǒng)也沒有辦法做彈性的擴展。

因此， PolarDB 研發(fā)了一個基于共享存儲的分布式計算引擎，這也是業(yè)界首創(chuàng)的解決方案。該方案具備以下優(yōu)勢：

① 它是一個一體化的存儲方案，TP 和 AP 共用一份存儲在共享存儲上數(shù)據(jù)。相比于兩套系統(tǒng)，它減少了存儲成本，同時也提供了毫秒級的數(shù)據(jù)新鮮度，即在 TP 系統(tǒng)里插入了一條數(shù)據(jù)，在 IP 系統(tǒng)里可以以毫秒級的速度查詢到。

② TP 和 IP 是物理隔離、互相不影響的。由部分計算節(jié)點執(zhí)行單機的引擎來處理高并發(fā)的 TP 查詢，由另外一部分節(jié)點執(zhí)行分布式的查詢引擎來處理復雜的 AP 查詢。

③ 具備彈性擴展能力。系統(tǒng)面度一些復雜的 SQL 時，出現(xiàn)算力不夠的情況，即可快速增加計算節(jié)點，新的節(jié)點也可以迅速增加到分布式的計算引擎的集群里。

相比于傳統(tǒng)的 OLAP 系統(tǒng)，它是一個即時生效的系統(tǒng)，不需要做數(shù)據(jù)的重分布和重打散，性能上有了巨大的提升。

在共享存儲上實現(xiàn)一個完備的分布式計算引擎需要實現(xiàn)以下幾個模塊：

① 分布式優(yōu)化器。優(yōu)化器會根據(jù)數(shù)據(jù)分布特征生成一個分布式的執(zhí)行計劃數(shù)。PolarDB 是基于 GPORCA 優(yōu)化器框架做的二次開發(fā)，在開發(fā)過程中，需要讓優(yōu)化器感知到數(shù)據(jù)是共享的。GPORCA優(yōu)化器框架是基于 share-nothing ，因此應用到 PolarDB 勢必要增加很多規(guī)則轉換。

② 分布式執(zhí)行器。為了實現(xiàn)分布式執(zhí)行器，需要實現(xiàn)一整套完整的并行化的算子。比如在做數(shù)據(jù)掃描的時候，因為在 PolarDB里底層數(shù)據(jù)是共享的，各個計算節(jié)點在做順序掃描的時候就需要做掃描算字的并行化。這些算子最后會組裝成火山執(zhí)行模型。

③ 事務一致性。由于分布式執(zhí)行跨了多個計算節(jié)點，需要使用統(tǒng)一的數(shù)據(jù)位點和快照來進行事務的可見性判斷，才能保證各個節(jié)點查詢到的數(shù)據(jù)是全值一致性的數(shù)據(jù)。

④ SQL 全兼容。為了使新的分布式計算引擎能夠被用戶的業(yè)務使用，還需要對 SQL 的標準進行大量兼容性的開發(fā)工作。

PolarDB 除了能夠以計算存儲分離的方式運行在一個共享存儲的設備上，也能支持三節(jié)點高可用的模式。此模式可以不需要依賴共享存儲的設備，以本地盤的模式來運行。

首先，節(jié)點之間通過 X-Paxos 算法來對 redo 日志進行復制，以保證在region 內部能夠提低延遲同時 RP=0 的可用性。

其次，借助X-Paxos算法的復制實現(xiàn)了自動 failover 當leader 節(jié)點宕機時，無需 DBA 人員介入，算法能夠自動選出一個新的 leader 來自動恢復。

此外，還可以借助 X-Paxos 算法實現(xiàn)集群成員變更。與此同時，PolarDB還實現(xiàn)了 log 節(jié)點（即節(jié)點上只有 redo 日志沒有數(shù)據(jù)頁），可以通過用兩個正常的節(jié)點加上一個 log 節(jié)點，實現(xiàn)2.5副本的方式，降低成本。

在跨region場景下，通過 log 節(jié)點實現(xiàn)了兩地三中心的高可用部署方式。如上圖， region1 是一個獨立的X-Paxos 三節(jié)點高可用的模式， region2 是一個獨立的 DB 部署，并在同城的另一個機房里去部署一個 log 節(jié)點。那么 region 1 和同城 log 節(jié)點之間可以采用同步復制或異步復制，而由于是在同一個城市內部，延遲也比較低，這樣即實現(xiàn)了兩地三中心的高可用的部署方式。

系統(tǒng)還兼容了原生的流復制和邏輯復制，用戶可以在下游部署一套自己的標準的 PostgreSQL 數(shù)據(jù)庫來消費上游的 redo 日志。

對于前文提到的三個 PolarDB 架構，用戶可以根據(jù)業(yè)務場景對其進行自由組合來使用。比如通過云原生+HTAP組合，可以滿足對彈性、 TP 和 AP 都有需求的業(yè)務。并且，三種架構的自由組合是在一套二進制里實現(xiàn)的，用戶只需要在配置文件里面進行簡單的配置，即可實現(xiàn)這三套架構的自由組合。

二、PolarDB企業(yè)級特性

PolarDB 的企業(yè)級特性有四個方面。

① 架構上的支持，前文已經(jīng)進行了詳細的講解，此處不再贅述。

② 高性能。

• 1) PolarDB 實現(xiàn)了 CSN 快照和WAL日志的流水線，解決了高并發(fā)下臨界區(qū)的問題。
• 2) 實現(xiàn)了預讀和預擴展、RelSizeCache以及 CLOG 的優(yōu)化。那么這些優(yōu)化是針對DirectIO 模型下 IO 的優(yōu)化。存儲計算分離之后，存儲的每一個 IO 都需要通過網(wǎng)絡去訪問后端的存儲池，與原生場景下存在一些差異，因此需要對其進行大量的優(yōu)化工作。
• 3) 研發(fā)了logIndex 核心數(shù)據(jù)結構,它記錄了每個頁面歷史上發(fā)生的redo日志。它不僅能解決在計算存儲分離下特有的過去頁面和未來頁面數(shù)據(jù)正確性的問題，還解決了 PB 數(shù)據(jù)庫特有的半寫問題。

③ 高可用。

• 1） 實現(xiàn)了 DataMax ，它提供了 log 模式來支持兩地三中心的部署，還實現(xiàn)了 Online Promote 、延遲回放和并行回放。這三個大的功能優(yōu)化了崩潰恢復的速度，縮短了 DB 進程崩潰時的不可用時間。
• 2） 實現(xiàn)了常駐BufferPool ，DB 進程重啟后， buffer 需要重新初始化，而目前的機器配置會導致 buffer 越來越大，進而使得buffer 的初始化需要耗費大量時間。
• 3） 提供了Replication Slot 解決了 DB failover時slot 的丟失問題。它借助共享存儲，將 slot 的信息存儲到共享存儲上，以此解決了復制槽丟失的問題。
• 4） 實現(xiàn)了算子級別的內存控制，為每個算子的內存設置了一個上限，避免了因單個算子內存過多而導致整個 DB 進程崩潰。

④ 安全。PolarDB 提供了透明加密的功能，保證存儲在盤上的數(shù)據(jù)是加密后的數(shù)據(jù)。目前透明加密支持 AES 128位 和 AES 256位 以及國密 SM4 的加密算法。

三、PolarDB開源社區(qū)

PolarDB已經(jīng)開源至 github 。源碼倉庫地址：https://github.com/ApsaraDB/PolarDB-for-PostgreSQL

在開源的過程中，我們堅持的策略就是100% 兼容社區(qū)標準的 PostgreSQL， 保證用戶能夠從標準的單機PostgreSQL 無縫遷移到 PolarDB 上。其次，我們將所有組件全部開源，包括PolarDB內核、PolarDB分布式文件系統(tǒng)和PolarDB云管控，并承諾開源的代碼與公有云上的代碼完全一致。

開放云代碼的同時，我們還提供了豐富的文檔和視頻資料，比如架構原理文檔、核心功能文檔、快速入門文檔。

原文鏈接

本文為阿里云原創(chuàng)內容，未經(jīng)允許不得轉載。?

總結

以上是生活随笔為你收集整理的首次公开，阿里云开源PolarDB总体架构和企业级特性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。