本文通過描述關系型資料庫發展的背景以及雲計算的時代特征，分享了資料庫計算力的螺旋式上升的進化理念，另外結合阿裡雲 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 的性能有了質的飛躍。
來源：阿裡技術
<a href="https://mp.weixin.qq.com/s/Vv-qZtUvfHQEr5-ZbX5XDQ">原文連結</a>