阿里雲新一代關係型資料庫 PolarDB

阿里妹導讀：本文通過描述關係型資料庫發展的背景以及雲計算的時代特徵，分享了資料庫計算力的螺旋式上升的進化理念，另外結合阿里雲 RDS 產品的發展路徑，闡述了自主研發的新一代雲託管關係型資料庫 PolarDB 的產品整體設計思想，對一些關鍵技術點進行了解讀。

關係型資料庫

談到關係型資料庫，在這個知識日新月異的 TMT 時代，聽起來有些「古董」，這個起源於半個世紀以前的 IT 技術，事實上一直處於現代社會科技的核心，支撐著當今世界絕大多數的商業科技文明。CPU、操作系統、資料庫這三大核心領域，基本上就是 IT 時代的縮影，同時也是一切信息化處理、計算力和智能化的基石。

從 1970 年 E.F.Codd 發表了一篇里程碑論文「A Relational Model of Data for Large Shared Data Banks」，到 80 年代初期支持 SQL 的商用關係型資料庫 DB2，Oracle 的面市，以及 90 年代初 SQL-Server 的誕生，都是關係型資料庫成功的代表。

時至今日，隨著全球互聯網的發展，大數據技術的廣泛應用，湧現出越來越多的新型資料庫，然而關係型資料庫仍然佔據主導地位。最主要的原因之一就是關係型資料庫採用了 SQL 標準，這種高級的非過程化編程介面語言，將計算機科學和易於人類理解認知的數據管理方式完美的銜接在了一起，目前還難以超越。

SQL 語言

SQL(Structured Query Language) 語言是 1974 年由 Boyce 和 Chamberlin 提出的一種介於關係代數與關係演算之間的結構化查詢語言，其本質是用一種類似於自然語言的關鍵字和語法來定義和操作數據，進行可編程的數據存儲、查詢以及管理。

這種抽象編程介面，將具體的數據問題與數據的存放、查詢實現的細節解耦開來，使得商業業務邏輯以及信息管理的計算模式能夠被大量複製和應用，解放了生產力，也極大的促進了商業化關係型資料庫自身的發展。

從 SQL 後來不斷發展和豐富來看，SQL 已經成為關係型資料庫語言的標準和王者。到今天這種編程語言還沒有更加完美的替代品。

OLTP

1976 年，Jim Gray 發表了名為"Granularity of Locks and Degrees of Consistency in a Shared DataBase"的論文，正式定義了資料庫事務的概念和數據一致性的機制。而 OLTP 是關係型資料庫涉及事務處理的典型應用，主要是基本的、日常的事務處理，例如銀行交易。

事務處理需要遵循 ACID 四個要素來保證數據的正確性，包括原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）。而衡量 OLTP 處理能力的性能指標主要有響應時間、吞吐率等。

開源資料庫生態

在我們簡要的回顧了關係型資料庫的歷史、地位和發展階段後，我們不難看到 Oracle、SQL-Server、DB2 等關係型資料庫仍然佔據著全球商業資料庫的主導地位，雖然曾經耳熟能詳的 Informix、Sybase 已經淡出大眾的視線。

然而，從 20 世紀 90 年代開始，另一股推崇知識分享、自由開放的軟體精神成為趨勢和潮流，尤其以 Linux、MySQL、PostgreSQL 等為代表的開源軟體，開始以強大的生命力不斷發展壯大，釋放出巨大的社會進步力量，這些被自由分享的科技紅利，孕育和促進了全球互聯網高科技公司的飛速發展。

這是整個人類社會的進步，我們要感謝那些開源軟體的鬥士們，Richard Stallman，Linus Torvalds，Michael Widenius 等。當然，最近幾年國內湧現出越來越多積极參与到開源主流社區的中國公司，也在不斷地將技術分享回饋給開源世界。

根據 DB-engines 網站的最新統計，不難發現，當把開源資料庫 MySQL 和 PostgreSQL 加在一起，開源資料庫就已經超越了商業資料庫 Oracle，成為世界上最流行的關係型資料庫。

雲計算當前的階段

如果說關係型資料庫是 IT 時代的產物。那麼在互聯網時代的雲計算，關係型資料庫目前正處於一個什麼階段呢？IT 時代從某種程度上講，更多是創造了計算力，那麼進入互聯網時代的雲計算，則是專註於用戶和計算力的連接，提供無處不在的計算力，這個其實是雲計算商業模式的成功所在，可以稱之為 1.0 版本。而雲計算 2.0 版本，需要在雲環境下，重新進化和升級計算力，這種進化體現了社會計算力的整合以及計算資源能效的進步。

為了順應綠色計算以及共享經濟的發展潮流，不僅僅需要雲伺服器，雲資料庫，網路互聯，硬體晶元等等各個軟硬體系統領域的融合以及演進升級，還需要堅持科技以需求為本、服務以用戶為根的科技普惠大眾的理念來進一步促進計算效率和計算智能的提高。

我們正處在一個蓬勃發展的雲計算 2.0 階段。在這個階段，關係型資料庫在雲託管環境逐漸暴露出一些問題，作為在雲計算時代的先行者，Amazon 於 2014 年 11 月 12 日 的 AWS re:Invent 2014 大會，發布 Aurora 雲託管關係型資料庫就是為了解決這些問題。這個新一代的資料庫的發布，也昭示著雲計算時代，傳統的 IT 技術核心產品將揭開自我進化的序幕。

而 2017 年 SIGMOD 數據大會， Amazon 發布了論文」Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases」, 更加開放的解釋了基於雲環境的 Cloud-Native 設計的關係型資料庫是如何應孕而生的。

為什麼阿里雲研發 PolarDB ?

在我們回顧了關係型資料庫以及雲計算的背景之後，我們不難發現, 雲計算 1.0 雖然解決了用戶和計算的連接的問題，但是還需要進一步解決在一個共享計算的環境下，傳統關係型資料庫和公有雲服務環境的融合問題。

雲計算 1.0 用低廉的成本，靈活快速的部署、彈性和擴展能力，獲得了傳統 IT 計算上雲的轉換動力。在低成本享受普惠科技成為常態之後，隨著用戶業務的增長，用戶新的痛點開始出現，例如，如何從根本上解決用持續低的成本，享受和傳統 IT 計算力一樣，甚至更好的雲服務，成為迫切需要。

這初看起來像偽命題，仔細分析之後，卻淋漓盡致的體現了螺旋式上升的哲學思想。就好像在 PC 伺服器湧現的時代，PC 伺服器首先用低廉的價格提供了和小型伺服器接近的計算能力，然後在保持成本和性價比優勢的基礎上，實現了超越小型伺服器的性能優勢，直至終結了小型伺服器時代，開始了 PC 伺服器時代。

所以說雲計算時代還遠遠沒有到達鼎盛時期，除非它通過自身進化演變，在不斷保持性價比優勢的同時，在具有快速靈活彈性的內在屬性基礎上，擁有超過傳統 IT 計算力的能力之後，雲計算才會真正進入它所主宰的時代，這只是個時間問題。

也就是說今天不只是阿里雲要做這樣一款關係型資料庫，而是所有的雲計算廠商都不可避免的要經歷這樣一個階段。那就是雲計算時代傳統 IT 計算力的重建和進化！只不過 Amazon 走在了最前面，而阿里雲緊跟其後，都需要經歷這進化到蛻變的過程。

在這個過程中，新一代關係型資料庫是關鍵的里程碑之一。同理，接下來應該有更多更加高級的雲服務，比如智能雲操作系統出現，來融合為雲時代設計的硬體晶元和網路互聯等等。

在 IT 時代，傳統的計算力（例如用關係型資料庫來處理結構化數據等）是服務於系統硬體隔離環境下的多用戶使用場景的。而雲計算時代是多客戶 Self-Service 租用環境，各種計算負載場景更加複雜，在這種計算負載變遷的環境下，如何解決 IT 時代的技術產物和雲計算時代應用環境的適配矛盾，正是雲計算自我進化的內在推動力。

例如，在公有雲環境下，隨著用戶的增多，以及用戶業務和數據的增長，備份、性能、遷移、升級、只讀實例、磁碟容量、Binlog 延遲等相關問題漸漸顯現出來。這背後大部分原因是由於 I/O 瓶頸（存儲和網路）導致，亟須通過技術革新以及新的產品架構解決這個問題。另一方面，從產品形態來講，阿里雲 RDS 目前的產品形態各具優勢，在下一節會詳細介紹。

但是從產品架構的發展來看，除去資料庫存儲引擎的類型之外，對於關係型資料庫，考慮到工程效率以及運維成本，最好有一種通用的產品技術架構能兼顧不同用戶場景的需求，而不是針對每一個場景都實現一種對應的技術架構。

在接下來的內容，通過講述阿里雲 RDS 的不同產品形態的特點，我們會更加清晰的了解到，PolarDB 的產品形態正是在吸收了之前幾種產品形態的優點而孕育而生的。

PolarDB 的設計思想

用戶需求和公有雲自身發展的選擇

作為雲託管的關係型數據，除了關係型資料庫的核心特徵之外。PoalrDB 更多的關注於如何提供滿足用戶業務需求的雲服務，並且通過技術革新，不斷進化，在提供更好的資料庫計算力的同時，滿足用戶以下業務需求：上雲成本、OLTP 性能、業務連續性、在線業務擴展、數據安全。

另一方面雲計算除了成本優勢之外，彈性和可擴展性也是雲計算的天然屬性。為了用戶業務的擴展，更好的 Scale Up 以及故障恢復，計算和存儲分離的架構成為雲資源環境更好的選擇。這一點將在下一節 RDS 產品架構的演進中得到進一步的詮釋。

阿里雲 RDS 產品架構的演進

如上所述，阿里雲 PolarDB 和 Amazon Aurora 資料庫進化的方向是一致的，然而進化的路徑各有不同。本身來講，這是由於各自的資料庫雲服務實現方式不同所決定的。阿里雲 RDS MySQL 有如下幾個版本。這些產品形態滿足不同的用戶業務場景，具有不同的特點，可以進行優勢互補。

MySQL 基礎版

MySQL 基礎版採用資料庫計算節點和存儲節點分離的方式，利用雲盤數據本身的可靠性和多副本的特性，同時也利用了 ECS 雲伺服器虛擬化來提升標準化部署、版本和運維的管理效率，能夠滿足低端用戶不太注重高可用服務的業務場景。

同時這種架構對於資料庫的遷移，數據容量的擴容，計算節點的 Scale Up，計算節點故障恢復都有天然的優勢，根本原因就是計算和存儲的分離。後面也會講到，PolarDB 也採用了存儲和計算分離的設計理念。

MySQL 高可用版

MySQL 高可用版則是針對企業級用戶提供的高可用資料庫版本，提供 99.95% 的 SLA 保障。採用 Active-Standby 的高可用架構，主節點和備節點之間通過 MySQL Binlog 進行數據的 Replication。當主節點發生故障，備節點接管服務。

同時還支持多個只讀節點，支持負載均衡的數據讀寫分離的訪問方式。採用 Shared-Nothing 架構，計算和數據位於同一個節點，最大程度保障性能的同時又通過數據的多副本帶來可靠性。

MySQL 金融版

MySQL 金融版可以說是針對金融行業等高端用戶設計的高可用、高可靠雲服務產品，採用分散式 Raft 協議來保證數據的強一致性，擁有更加優異的故障恢復時間，更加滿足數據容災備份等業務場景的需求。

PolarDB 的進化

PolarDB 採用存儲與計算分離的技術架構，同時可以支持更多的只讀節點。主節點和只讀節點之間是 Active-Active 的 Failover 方式，計算節點資源得到充分利用，由於使用共享存儲，共享同一份數據，進一步降低了用戶的使用成本。下一節我們將進一步從細節上描述 PolarDB 的關鍵特性。

PolarDB 的設計思想有幾個大的革新。一是通過重新設計特定的文件系統來存取 Redo log 這種特定的 WAL I/O 數據，二是通過高速網路和高效協議將資料庫文件和 Redo log 文件放在共享存儲設備上，避免了多次長路徑 I/O 的重複操作，相比較 Binlog 這種方式更加巧妙。

另外在 DB Server 設計上，採用 MySQL 完全兼容的思路，完全擁抱開源生態，從 SQL 的編譯、性能優化器和執行計劃等等都保留了傳統關係型資料庫的特色。並且針對 Redolog 的 I/O 路徑，專門設計了多副本共享存儲塊設備。

我們知道，分散式資料庫一直是資料庫領域的熱點，具有非常大的實現難度。不管是遵循 CAP 理論，還是 BASE 思想，通用的分散式關係型資料庫基本上很難做到技術和商用的完美平衡。與 SQL 標準以及主流資料庫兼容，OLTP ACID 事務 100% 支持，99.99% 的高可用，高性能低延遲並發處理能力，彈性 Scale Up，Scale out 可擴展性，備份容災和低成本遷移等等，能夠完美兼顧所有這些特點的商用關係型資料庫還沒有出現。

阿里雲 PolarDB 和 Amazon Aurora 的一個共同設計哲學就是，放棄了通用分散式資料庫 OLTP 多路並發寫的支持，採用一寫多讀的架構設計，簡化了分散式系統難以兼顧的理論模型，又能滿足絕大多數 OLTP 的應用場景和性能要求。

總之，100% MySQL 的兼容性，加上專用的文件系統和共享存儲塊設備設計，以及在下文中提到的多項高級技術的應用，使得新一代關係型資料庫 PoalrDB 在雲時代必將大放異彩。

PolarDB 產品關鍵技術點剖析

在講述了阿里雲 RDS 的不同產品形態之後，我們再從整體上看一看 PolarDB 的產品架構。下圖勾畫了 PolarDB 產品的主要模塊，包括資料庫伺服器，文件系統，共享塊存儲等。

PoalrDB 產品架構

如圖所示，PolarDB 產品是一個分散式集群架構的設計。它集眾多高級的技術實現於一身，使得資料庫 OLTP 處理性能有了質的飛躍。PoalrDB 採用了存儲與計算分離的設計理念，滿足公有雲計算環境下用戶業務彈性擴展的剛性需求。資料庫計算節點和存儲節點之間採用高速網路互聯，並通過 RDMA 協議進行數據傳輸，使得 I/O 性能不在成為瓶頸。

資料庫節點採用和 MySQL 完全兼容的設計。主節點和只讀節點之間採用 Active-Active 的 Failover 方式，提供 DB 的高可用服務。DB 的數據文件、redolog 等通過 User-Space 用戶態文件系統，經過塊設備數據管理路由，依靠高速網路和 RDMA 協議傳輸到遠端的 Chunk Server。

同時 DB Server 之間僅需同步 Redo log 相關的元數據信息。Chunk Server 的數據採用多副本確保數據的可靠性，並通過 Parallel-Raft 協議保證數據的一致性。

在描述了 PolarDB 的產品架構之後，我們再分別從分散式架構，資料庫高可用，網路協議，存儲塊設備，文件系統和虛擬化等方面逐一介紹下 PolarDB 使用的關鍵技術點。

Shared Disk 架構

分散式系統的精髓就在於分分合合，有時候為了並發性能進行數據切分，而有時候為了數據狀態的一致性而不得不合，或者由於分散式鎖而不得不同步等待。

PolarDB 採用 Shared Disk 架構，其根本原因是上述的計算與存儲分離的需要。邏輯上 DB 數據都放在所有 DB server 都能夠共享訪問的數據 chunk 存儲伺服器上。而在存儲服務內部，實際上數據被切塊成 chunk 來達到通過多個伺服器並發訪問 I/O 的目的。

物理 Replication

我們知道，MySQL Binlog 記錄的是 Tuple 行級別的數據變更。而在 InnoDB 引擎層，需要支持事務 ACID，也維持了一份 Redo 日誌，存儲的是基於文件物理頁面的修改。

這樣 MySQL 的一個事務處理默認至少需要調用兩次 fsync() 進行日誌的持久化操作，這對事務處理的系統響應時間和吞吐性能造成了直接的影響。儘管 MySQL 採用了 Group Commit 的機制來提升高並發下的吞吐量，但並不能完全消除 I/O 瓶頸。

此外，由於單個資料庫實例的計算和網路帶寬有限，一種典型的做法是通過搭建多個只讀實例分擔讀負載來實現 Scale out。PolarDB 通過將資料庫文件以及 Redolog 等存放在共享存儲設備上，非常討巧的解決了只讀節點和主節點的數據 Replication 問題。

由於數據共享，只讀節點的增加無需再進行數據的完全複製，共用一份全量數據和 Redo log，只需要同步元數據信息，支持基本的 MVCC，保證數據讀取的一致性即可。這使得系統在主節點發生故障進行 Failover 時候，切換到只讀節點的故障恢復時間能縮短到 30 秒以內。

系統的高可用能力進一步得到增強。而且，只讀節點和主節點之間的數據延遲也可以降低到毫秒級別。

從並發的角度來看，使用 Binlog 複製現在只能按照表級別並行複製，而物理複製只按照數據頁維度，粒度更細，並行效率更加高。

最後一點，引入 Redolog 來實現 Replication 的好處是，Binlog 是可以關閉來減少對性能的影響，除非需要 Binlog 來用於邏輯上的容災備份或者數據遷移。

總之，在 I/O 路徑中，通常越往底層做，越容易和上層的業務邏輯和狀態解耦而降低系統複雜度。而且這種 WAL Redo log 大文件讀寫的 I/O 方式也非常適用於分散式文件系統的並發機制，為 PolarDB 帶來並發讀性能的提高。

高速網路下的 RDMA 協議

RDMA 之前是在 HPC 領域被使用多年的技術手段，現在開始被使用到雲計算領域，也證實我的一個判斷。雲計算 2.0 時代，將重建人們對於雲計算的認識，雲端也能夠創造超越傳統 IT 技術的計算力，這將是一個越來越嚴謹的工業實現。

RDMA 通常是需要有支持高速網路連接的網路設備（如交換機，NIC 等），通過特定的編程介面，來和 NIC Driver 進行通訊，然後通常以 Zero-Copy 的技術以達到數據在 NIC 和遠端應用內存之間高效率低延遲傳遞，而不用通過中斷 CPU 的方式來進行數據從內核態到應用態的拷貝，極大的降低了性能的抖動，提高了整體系統的處理能力。

Snapshot 物理備份

Snapshot 是一種流行的基於存儲塊設備的備份方案。其本質是採用 Copy-On-Write 的機制，通過記錄塊設備的元數據變化，對於發生寫操作的塊設備進行寫時複製，將寫操作內容改動到新複製出的塊設備上，來實現恢復到快照時間點的數據的目的。

Snapshot 是一個典型的基於時間以及寫負載模型的後置處理機制。也就是說創建 Snapshot 時，並沒有備份數據，而是把備份數據的負載均分到創建 Snapshot 之後的實際數據寫發生的時間窗口，以此實現備份、恢復的快速響應。PolarDB 提供基於 Snapshot 以及 Redo log 的機制，在按時間點恢復用戶數據的功能上，比傳統的全量數據結合 Binlog 增量數據的恢復方式更加高效。

Parallel-Raft 演算法

談到分散式資料庫的事務一致性，我們很容易想到 2PC（2 Phases Commit），3PC（3 Phases Commit）協議。而論數據狀態一致性，我們就不得不提到 Leslie Lamport 發明的 Paxos 協議，在 Paxos 為 Google 等互聯網廠商所廣泛應用到多個分散式系統實現之後，Paxos 成為了最受關注的數據狀態一致性演算法之一。可是由於 Paxos 演算法論文的理論和實現過於複雜，導致難以被快速應用到工程技術上。

Paxos 解決的問題之一是，在多個機器的集合中，集合中初始狀態相同的任何機器能否通過相同的命令序列到達同樣相同的狀態點，形成一個一致的收斂的狀態機。另一個問題是，作為集群中的一員，通過微觀的時間串列通訊方式，需要找到一個始終有效的協議，當一個機器的某個數據狀態需要改變時，需要和整個集群（包括其他機器）靠通訊和協議達成相同的認知，一起認同這個機器上的某個狀態的改變。

基於這兩點，基本上就解決了分散式集群架構中，不同角色的機器，達成一致性狀態機的問題。也就可以進一步設計出絕大多數分散式系統的框架。

Paxos 可以堪稱是 P2P（Peer to Peer）的對等設計，更加抽象和通用，也更難以理解。而 Raft 則是選舉出 Leader，再經由 Leader 發起對其他角色進行狀態一致性更新的實現，更容易理解。而協議本身的實現流程和 Paxos 有相似之處。

Parallel-Raft 是在 Raft 協議的基礎上，針對 PolarDB chunk Server 的 I/O 模型，進行改良的一致性演算法。Raft 協議基於 Log 是連續的，log#n 沒有提交的話，後面的 Log 不允許提交。而 PolarDB 實現的 Parallel-Raft 允許並行的提交，打破了 Raft 的 log 是連續的假設，提高並發度，通過額外的限制來確保一致性。

Docker

容器虛擬化技術最早的出現是 Linux 內核為了解決進程在操作系統之間，或者在進程運行過程當中做遷移，通過進程和操作系統之間的解耦，來達到進程運行時的上下文和狀態能夠保存，複製和恢復的目的。可是 LXC 的實現，卻促成了曾紅極一時的 Docker 的誕生。

從原理上講，容器虛擬化的實現相對於 KVM 等虛擬化技術而言，更加輕量級。如果用戶不需要感知整個操作系統的功能，那麼用容器虛擬化技術理論上應該能夠獲得更好的計算能效比。

其實 LXC 加上 Cgroup 這種進程虛擬和資源隔離的方式已經被使用很多年，在 HPC 領域就常被應用到 MPI 超級任務的 checkpoint 和 restart 恢復上。PolarDB 採用 Docker 環境來運行 DB 計算節點，用更輕量的虛擬化方式，解決了資源的隔離和性能的隔離，也節省了系統資源。

User-Space 文件系統

談到文件系統，就不得不提一下 IEEE 發明的 POSIX 語義（POSIX.1 已經被 ISO 所接受），就像說到資料庫要談到 SQL 標準。通用分散式文件系統實現的最大挑戰就是在完全兼容 POSIX 標準的基礎上提供強勁的並發文件讀寫性能。

可是 POSIX 的兼容勢必會犧牲一部分性能來獲得對於標準的完全支持，同時系統實現的複雜度也極大的增加。說到底是通用設計和專有設計的取捨和區別，也是易用性和性能之間的平衡，這是個經典問題。

分散式文件系統是 IT 行業最經久不衰的技術，從 HPC 時代，雲計算時代，互聯網時代，大數據時代一直在推陳出新，其實更嚴格的說應該是針對不同應用 I/O 場景湧現出很多定製化的實現，再說白點，就是不去支持 POSIX 標準。

這一點上，只能說知難而退，不過只服務於專門的 I/O 場景時，不適用 POSIX 也不是什麼問題。這一點，和從 SQL 到 NoSQL 的發展如出一轍。支持 POSIX 的文件系統，需要實現兼容標準的文件讀寫操作的系統調用介面，這樣對於用戶而言，就無需修改 POSIX 介面實現的文件操作應用程序。這樣一來就要求通過 Linux VFS 層來鉚接具體的文件系統內核實現。這也是導致文件系統工程實現難度加大的原因之一。

對於分散式文件系統而言，內核模塊還必須和用戶態的 Daemon 進行數據交換，以達到數據分片以及通過 Daemon 進程傳送到其他機器上的目的。而 User-Space 文件系統提供用戶使用的專用 API，不用完全兼容 POSIX 標準，也無需在操作系統內核進行系統調用的 1:1mapping 對接，直接在用戶態實現文件系統的元數據管理和數據讀寫訪問支持即可，實現難度大大降低，並且更加有利於分散式系統的進程間通訊。

小結：通過以上的介紹，我們不難發現，PolarDB 採用了從計算虛擬化，高速網路互聯，存儲塊設備，分散式文件系統，資料庫物理 Replication 等全方位的技術手段，可以說是眾多熱點技術的集大成。正式這些關鍵技術的整合創新，才使得 PolarDB 的性能有了質的飛躍。

你可能還喜歡

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 阿里技術 的精彩文章: