本文通過描述關系型資料庫發展的背景以及雲計算的時代特征，分享了資料庫計算力的螺旋式上升的進化理念。并且結合阿裡雲 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産品架構
阿裡雲關系型資料庫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的性能有了質的飛躍。
寫在最後
阿裡雲polardb是雲計算2.0時代産品進化的關鍵裡程碑之一，也是開源資料庫生态的積極推動力。polardb将于2017年9月底推出的公測版本，會和mysql完全相容。接下來，我們也會啟動相容postgresql資料庫引擎的研發。
作者 阿裡雲 賀軍
<a href="http://i.aliyun.com/inviteapply?agent_id=205">點此免費試用雲資料庫polardb</a>