深度 | 帶領國產資料庫走向世界，POLARDB底層邏輯是什麼？

POLARDB 是阿里雲自主研發的下一代雲原生分散式資料庫，100%相容MySQL、PostgreSQL等開源資料庫，高度相容Oracle語法，使用RDS服務的客戶不需要修改應用程式碼，可以一鍵遷移到POLARDB，體驗更大的容量，更高的效能，更低的成本，和更靈活的彈性。

目前，POLARDB是阿里雲增速最快的資料庫產品，廣泛應用於網際網路金融、政府便民工程、新零售、教育、遊戲、社交直播等行業。

作為基於計算與儲存分離架構的新一代雲原生資料庫，POLARDB的計算節點裡主要實現了 SQL 解析和最佳化、以及查詢並行執行與無鎖高效能事務處理，計算節點之間透過高吞吐的物理複製協議同步記憶體狀態。

而儲存層基於分散式檔案系統PolarFS，透過Parallel Raft共識演算法實現多資料副本間的強一致性，在儲存層進行儲存引擎的多版本頁管理來支援全叢集跨計算節點的Snapshot Isolation隔離級別。

01基於計算與儲存分離的先進架構

計算節點與儲存節點之間透過理解資料庫語義的智慧互聯協議將filter和projection等運算元從計算層下推到儲存層執行。為了保證事務和查詢語句的低延遲，同時降低計算節點之間狀態同步的延遲，計算節點和儲存節點之間使用25Gb高速RDMA網路互聯，採用Bypass kernel的使用者態網路協議層進行通訊。

基於計算與儲存分離的先進架構，POLARDB可以從1個計算節點（2個CPU核）彈性伸縮到16個計算節點（最高達到1000核）的事務擴充套件能力，單例項儲存容量從10GB按使用量彈性擴充套件到100TB。

計算節點與儲存節點分離的架構設計給POLARDB帶來了實時的水平擴充套件能力。由於單個資料庫例項的計算能力有限，傳統的做法是透過搭建多個資料庫副本來分擔壓力，從而提供資料庫Scale out 的擴充套件能力。

然而，這種做法需要儲存多份全量資料，並且頻繁同步日誌資料造成了過高的網路開銷。此外，在傳統資料庫叢集上，增加副本需要同步所有增量資料，這帶來了同步延遲上漲的問題。

POLARDB將資料庫檔案以及Redo log 等日誌檔案存放在共享儲存裝置上，確保主例項和所有副本共享同一份全量資料和增量日誌資料。節點間只需要同步記憶體裡的後設資料資訊，透過MVCC機制的保證，就能支援跨節點讀取資料的一致性，非常巧妙地解決了主例項和副本之間的資料同步問題，大大節約了跨節點的網路開銷，降低副本間的同步延遲。

02提升事務效能 POLARDB核心層面最佳化揭秘

為了提高事務效能，POLARDB 在核心層面進行了大量最佳化。把一系列效能瓶頸用無鎖（lockless）演算法以及各種並行最佳化演算法進行改造，減少甚至消除各種鎖之間的相互衝突，大大增加了系統的scalability 能力。

同時，我們依託處理雙十一這種大規模高併發場景下的經驗, 在 POLARDB 上實現了對庫存等熱點資料進行最佳化的功能。對於簡單重複的查詢，POLARDB支援直接從儲存引擎獲取結果，從而減少了最佳化器及執行器的開銷。

此外，進一步最佳化已經高效的物理複製。比如，我們在重做日誌加了一些後設資料，以減少日誌解析CPU開銷. 這個簡單最佳化減少了60%日誌解析時間。我們也重用 一些資料結構，以減少記憶體分配器的開銷。

POLARDB運用了一系列演算法來最佳化日誌應用，比如只有在buffer pool中的資料頁面 才需要日誌應用。同時我們也最佳化了page cleaner and double write buffer，大大減少這些工作的成本. 這一系列最佳化使得在效能上 POLARDB 遠超 MySQL ，在sysbencholtp_insert等大量併發寫入的基準評測中達到最高6倍於MySQL 的效能。

03支援並行查詢（Parallel Query）

為了提高子查詢和join等複雜查詢（例如TPC-H基準評測）的能力，POLARDB的查詢處理器支援並行查詢（parallel query），可以將一個查詢同時在多個或所有可用CPU核上進行執行。並行查詢能夠將一個查詢任務（當前只支援SELECT語句）劃分為多個子任務，多個子任務可以並行進行處理，整體採用Leader-Worker的併發模型。

Leader執行緒負責生成並行查詢計劃，協調並行執行過程的其他元件，並行執行計劃會包括並行掃描、多表並行連線、並行排序、並行分組、並行聚集等子動作。

Message queue是leader執行緒和worker執行緒的通訊層，worker執行緒透過message queue向leader執行緒傳送資料，而leader執行緒也會透過message queue向worker執行緒傳送控制資訊。

Worker執行緒負責真正的執行任務。Leader執行緒解析查詢語句生成並行計劃，然後同時啟動多個worker執行緒進行並行任務處理，為了高效的執行查詢，Worker上的執行不需要進行再次最佳化，而是直接從Leader上來複製生成好的計劃分片。這需要實現執行計劃樹上所有節點的複製。

worker執行緒在進行掃描，聚集，排序等操作後將中間結果集返回給leader，leader負責收集來自worker的所有資料集，然後進行適當的二次處理（比如merge sort，二次group by 等操作），最後將最終結果返回給客戶端。

Parallel Scan層會結合儲存引擎的資料結構特徵來實現工作負載的均衡。如何將掃描資料劃分成多個分割槽，使得所有的工作執行緒儘可能的均勻的工作是資料分割槽劃分的目標。在以B+樹作為儲存結構的儲存引擎裡，劃分分割槽的時候，是先從根上來劃分，如果根上不能劃分出足夠多的分割槽（>= 並行度），將會繼續從下一層進行劃分。

而如果我們需要6個分割槽的話，根節點最多分出4個分割槽，所以就需要繼續搜尋下一層來進行分割槽，以此類推。在實際實現並行查詢的過程中，為了能讓多個工作執行緒更加均勻的分配掃描段，會在B+樹裡儘可能的多劃分分割槽，這樣如果某個工作執行緒由於過濾性比較高會優先完成當前分割槽，那麼它會自動attach下一個分割槽繼續執行，透過自動attach的方式來實現所有執行緒的負載均衡。

04新一代基於代價的最佳化器

雲上客戶的業務是多樣化的，如果執行計劃選錯會導致慢查詢。為了系統性地解決這些問題，POLARDB推出了新一代的基於代價的最佳化器。POLARDB裡實現新的直方圖Compressed Histogram對高頻率資料進行自動探測並構建精確描述，在選擇率計算時考慮資料頻率和取值空間，解決實際應用中普遍存在的資料傾斜場景。

POLARDB大量基於改良的直方圖進行代價估算，比如估算表和表join的結果大小，是join代價和join order最佳化的決定性因素，MySQL只能根據經驗公式粗略的估算，無論是有索引時的rows_per_key,還是無索引時的預設引數值，估算的誤差都較大，這些誤差會在多表連線的過程中不斷放大，導致生成效率低下的執行計劃。

在POLARDB中使用直方圖對重合部分進行合併計算，並根據不同的直方圖型別適配不同的estimation演算法，大大提高了估算精度，幫助最佳化器做出更優的join order選擇。在隨機生成的正態分佈資料測試中，多表聯合查詢最佳化後可提速2.4-12倍，TPC-H測試中多個查詢的join order發生變化，效能提升77%-332%。

POLARDB也使用直方圖最佳化了record_in_range的邏輯，MySQL對於有索引的過濾條件採用index dive來估算區間的記錄數，這個操作在OLTP短查詢中CPU佔比較高。在使用基於直方圖估算替換index dive後，在淘寶電商核心業務中，絕大多數的查詢查詢響應時間減少一半。

05、自研分散式檔案系統PolarFS：高可靠、高可用、與資料庫協同設計

POLARDB的儲存層採用的是阿里雲自主研製的分散式檔案系統PolarFS。PolarFS是國內首款面向DB應用設計的採用了全使用者空間I/O棧的低延遲高效能分散式儲存系統（參見VLDB 2018 上的文章 PolarFS: An Ultra-low Latency and Failure Resilient Distributed FileSystem for Shared Storage Cloud Database），其具備與本地SSD硬碟架構相當的低延遲高效能I/O能力，同時也以分散式叢集的方式提供了優異的儲存容量與儲存效能的擴充套件能力。

而PolarFS作為一款與POLARDB深度協同的儲存基礎設施，其最核心的競爭力不僅體現在效能和擴充套件性方面，更深層次的則是在面臨有許多挑戰性的POLARDB客戶業務需求和規模化的公有云研發運維過程中而長期積累形成的一系列高可靠、高可用、與資料庫協同設計的儲存技術。

為了支援POLARDB在多個計算節點之間分發查詢且保持全域性的Snapshot Isolation語義，PolarFS支援儲存POLARDB儲存引擎B+樹動態生成的多版本（Multi-version page）。

為了減少讀寫衝突，現代資料庫一般都透過以MVCC併發控制為框架來提供RC、SI、SSI等不同的事務隔離級別，在MVCC機制下，B+樹的每個頁面會動態維護一系列的版本，併發執行中的多個事務允許各自訪問一個頁面的不同版本。

在POLARDB叢集裡，由於跨節點複製同步延遲的存在，每個計算節點B+樹的頁面可能是不同版本的，這時多版本儲存可以為各節點提供其所對應版本。在POLARDB中，計算節點向PolarFS寫入一個頁面的同時要提供該資料頁的版本資訊（LSN），PolarFS不僅儲存資料頁的同時還要儲存資料版本元資訊；計算節點讀取資料頁時，也會提供版本資訊從儲存獲取相應的資料頁（歷史）版本。

POLARDB資料庫層定期會將叢集所有計算節點版本號的低水位線傳送給PolarFS，PolarFS會基於此版本號清理不再使用的歷史版本。

保證資料可靠性是POLARDB所有設計的底線。在實際的分散式系統中，硬碟、網路與記憶體等硬體、韌體或軟體的bug等問題可能會造成資料錯誤，從而給資料可靠性保障帶來各種挑戰。儲存端的可靠性問題來自靜默錯誤（lost write、misdirected write，block corruption等），網路和記憶體主要來自於位元反轉和軟體bug。

為了確保各種異常情況（包括：硬體故障，軟體故障，人工操作故障）發生時的資料可靠性，POLARDB和PolarFS提供了端到端全鏈路資料校驗保障。

在資料寫入時，POLARDB 從計算節點的儲存引擎開始，一直到PolarFS儲存節點的資料落盤，經過的中間鏈路，都會對資料的正確性做校驗，防止異常資料寫入。

在資料讀取時，PolarFS和POLARDB儲存引擎都會對讀取到的資料做checksum校驗，準確地識別磁碟靜默錯誤的發生，防止靜默錯誤擴散。

在業務流量低峰時，還會在後臺持續性的做資料一致性掃描，用於檢查單副本資料的checksum是否正確以及各個副本間的資料是否一致。資料遷移過程中的正確校驗性也非常重要：POLARDB在執行任何形式的資料遷移動作時，除了副本自身資料的 checksum 校驗，還會對多個副本資料的一致性做校驗；當這兩個校驗都透過，才會將資料遷移到目標端；最大限度的防止由於遷移動作，導致單副本上的資料錯誤擴散，避免資料損壞問題。

PolarFS還支援對POLARDB做快速的物理快照備份與還原。快照是一種流行的基於儲存系統的備份方案。其本質是採用Redirect-On-Write 的機制，透過記錄塊裝置的後設資料變化，對於發生寫操作的儲存捲進行寫時複製，將寫操作內容改動到新複製出的儲存捲上，來實現恢復到快照時間點的資料的目的。

快照是一個典型的基於時間以及寫負載模型的後置處理機制。也就是說建立快照時，並沒有備份資料，而是把備份資料的負載均分到建立 快照之後的實際資料寫發生的時間視窗，以此實現備份、恢復的快速響應。

POLARDB透過底層儲存系統的快照機制以及Redo log增量備份，在按時間點恢復使用者資料的功能上，比傳統的全量資料結合邏輯日誌增量資料的恢復方式更加高效。

06高度相容Oracle語法 成本是商業資料庫的1/10

除了100%相容MySQL和PostgreSQL這兩個最流行的開源資料庫生態， POLARDB還高度相容Oracle語法，為傳統企業上雲提供成本是商業資料庫1/10的方案。

透過用DMS替換Oracle的GUI管理工具OEM，以及用POLARDBPlus替換命令列工具SQL Plus，沿襲了OracleDBA的使用習慣；客戶端SDK可以從OCI和O-JDBC Driver替換成libpq和JDBC Driver，只需要做so和jar包的替換，程式主體程式碼不需要修改；

對Oracle的SQL普通DML語法都能支援，對幾乎所有高階語法如connect by、pivot、listagg等也都全面支援；對PL/SQL儲存過程、以及儲存過程用到的內建函式庫也能做到全面覆蓋支援；

對一些高階功能（如安全管理、AWR等）提供完全相同的格式佈局和操作語法，所以綜合看來，POLARDB對Oracle的操作方法、使用習慣、生態工具、SQL語法、格式佈局等都做到了全面的相容和替換，結合遷移評估工具ADAM，應用可以做到少量改動甚至無改動。

07提前看：更多新技術和企業級特性即將上線

除了上面介紹的技術，POLARDB還有大量新技術和企業級特性在2019下半年陸續釋出，這些技術會全面提升POLARDB的可用性、效能，降低POLARDB的使用成本：

1）從彈性儲存到彈性記憶體，熱緩衝池（warm buffer pool）技術

POLARDB即將支援和計算節點程式解構的“熱”緩衝池，這將大大減少使用者業務在計算節點重啟時受到的影響。在進行機型替換規格升降級的時候（serverless），對業務的影響更小。同時，一個獨立的記憶體也使得其動態按需擴充套件或收縮成為可能。

2） 效能數倍增長，更好的DDL支援（FAST DDL）

POLARDB即將支援並行DDL，這將大大縮短表級別的DDL延遲。這個功能把並行化做到極致，可以把建索引等DDL的時間減少近10倍。同時，POLARDB還進行了大量的DDL複製層面的最佳化，這使得DDL可以進行跨區域的大批次複製，速度更加迅速，資源的消耗更少。

3） 支援跨地域的全球資料庫（Global Database）

POLARDB 支援跨地域、長距離的物理複製，幫助使用者建立其全球資料庫的部署。透過物理複製，資料可以實時複製到全球各個機房，使得全球使用者的查詢在當地機房就得到響應，反應更迅速。

4）分割槽表的支援

POLARDB支援100T的儲存容量。但是隨著表的大小的增長，單表索引的層次也增加，導致資料的查詢定位也變得更慢，一些單表上的物理鎖也導致並行DML碰到天花板。

所以進行合理的分割槽變得更加緊迫。之前不少使用者依賴資料庫外部中介軟體的分庫分表的來減少單表的壓力。

但是，隨著POLARDB在各方面比如並行查詢的發展，我們可以把這些分庫分表的功能透過分割槽表的形式在資料庫內更有效的實現。

有效的分割槽不但使我們能夠支援更大的表，而且它減少了一些資料庫索引的全域性物理鎖的衝突，從而提高整體DML的效能。

同時，這種形態之後可以更好的支援冷熱資料分離，把不同“溫度“的資料存放在不同的儲存介質中，在保證資料access的效能的同時，減少資料存放的成本。

POLARDB在增強分割槽表的一系列功能，包括全域性索引（Global Index），分割槽表的外來鍵（Foreign Key Constraint），自增分割槽表（Interval Partition）等，使得POLARDB更好的應對特大表

5） 行級壓縮

POLARDB即將推出行級壓縮功能。業界通常的做法是在資料頁級別透過通用壓縮演算法（比如LZ77、Snappy）進行壓縮，但頁級壓縮會帶來CPU開銷過大的問題，因為改動一行資料，也要把整個資料頁解壓，改動，再壓縮。

此外，有些場景下資料頁壓縮後反而變大（bloat），還會導致多重索引頁分裂 （multiple splits）。POLARDB採用細粒度（fine-grain）行級壓縮技術，對不同的資料型別採用特定的壓縮方式。

資料以壓縮的方式同時存在於外存及記憶體中，只有在要查詢的時候才進行行級資料的解壓，而不用解壓整個資料頁。由於資料除查詢外都是以壓縮方式儲存，所以日誌也記錄了壓縮的資料，這個進一步減少了日誌的大小，以及在網路傳輸的資料/日誌的壓力。同時其相對應的索引也只儲存壓縮的資料。

整體資料量的減少足以抵消解壓所引起的額外開銷，使得這種壓縮在大大減少資料儲存的同時並不會引起效能衰退。

6）In-Memory的列存（HTAP）

在傳統的資料庫領域，分析資料庫和線上事務處理是分隔開來的。因此通常需要在一天的經營結束後將線上事務處理的資料與往期分析處理的資料一起匯入至資料倉儲後執行分析，以生成相應的報表。

在HTAP資料庫中，則省去了大規模資料搬移的時間與運營成本，一站式解決大部分企業級應用的需求，並在交易結束當天同步出具T+0的分析報告。

在這種需求下，POLARDB在實現in-memory的列存資料表。透過物理邏輯日誌直接和POLARDB行存資料同步。這樣透過特定適合分析的運算元可以對這些列存資料進行實時的大資料分析。使得使用者可以一站式的得到分析結果。

7）冷熱分離儲存引擎X-Engine

儲存資料的規模越來越龐大，但不是所有的資料訪問頻率都相同，實際上資料訪問總是呈現比較明顯的冷熱分佈特徵，基於這一特徵，X-Engine設計了冷熱分層的儲存架構，根據資料訪問頻度(冷熱)的不同將資料劃分為多個層次，針對每個層次資料的訪問特點，設計對應的儲存結構，寫入合適的儲存裝置。

不同於傳統的B+樹技術，X-Engine使用了LSM-Tree作為分層儲存的架構基礎，使用多事務處理佇列和流水線處理技術，減少執行緒上下文切換代價，並計算每個階段任務量配比，使整個流水線充分流轉，極大提升事務處理效能。資料複用技術減少資料合併代價，並且因為資料複用減少快取淘汰帶來的效能抖動。進一步利用FPGA硬體加速compaction過程，使得系統上限進一步提升。

相對於其他類似架構的儲存引擎比如RocksDB，X-Engine的事務處理效能有10倍以上提升。

X-Engine的詳細技術參考SIGMOD 2019的論文X-Engine: An Optimized StorageEngine for Large-scale E-Commerce Transaction Processing。

目前，POLARDB不僅支撐阿里巴巴集團淘寶、天貓、菜鳥等業務場景，還廣泛應用於政務、零售、金融、電信、製造等領域，目前已經有40萬個資料庫遷上阿里雲。

基於POLARDB分散式資料庫，北京的公交系統快捷、流暢地安排著全市2萬多輛公交車，方便每天800萬人次出行；

眾安保險使用該資料庫處理保單資料，效率提升25%。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。