ICDE:POLARDB定義雲原生數據庫

摘要： 4月17日（巴黎時間）阿里雲POLARDB走出國門，亮相ICDE2018，並同步舉辦阿里雲自有的POLARDB技術專場。在會上，阿里雲進行了學術成果展現，從而推進Cloud Native DataBase成爲行業標準。

 

4月17日（巴黎時間）阿里雲POLARDB走出國門，亮相ICDE2018，並同步舉辦阿里雲自有的POLARDB技術專場。在會上，阿里雲進行了學術成果展現，從而推進Cloud Native DataBase成爲行業標準。

 

如下爲阿里雲資深技術專家蔡松露演講實錄：

 

如今我給你們介紹一下咱們的雲原生數據庫-POLARDB。

你們可能要問到底什麼是「雲原生數據庫」，雲原生數據庫的標準是什麼，咱們是如何定義的以及爲什麼如此定義？如今，咱們先把這些問題放一邊，咱們稍後回答。

如今咱們看一下一個雲原生的數據庫大概是什麼樣子，門檻是什麼，特性是什麼，首先，雲原生數據庫必須有優越的性能，有百萬級別的QPS；其次，必須有超大規模的存儲，可達到100TB的存儲空間；在雲上0宕機能力也是很是重要的；最後一個也是最重要的，雲是一個生態系統，數據庫必須兼容開源生態。

雲原生數據庫就像一輛跑車，一輛跑車可能有不少特性，好比外觀、速度，可是一個有這樣外觀和速度的車不必定是跑車。因此回到咱們的問題，雲原生數據庫的標準是什麼，在回答這個問題以前，咱們看一下數據庫的發展歷史。

我從4個維度來看一下數據庫的發展歷史，首先，從數據規模上來看，咱們生活在一個數據大爆炸的時代；其次，某些數據庫理論發生了演變，尤爲是CAP理論，咱們在算法理論上也有所突破；第三，用戶和應用場景也在發生變化；第四，基礎設施也在從傳統IDC遷移到雲上。

爲何會有數據大爆炸呢？數據是如何爆炸的呢？這是我引用的互聯網女王米克爾的報告，你能夠看到，互聯網歷史能夠總體分爲三個階段，第一階段咱們稱之爲PC互聯網，數據主要由PC產生，第二個階段能夠稱之爲移動互聯網，數據主要由智能手機產生，第三個階段是IoT，從如今開始，幾乎全部的數據由物聯網設備產生，多是你的手錶、冰箱、家裏的電燈和汽車，多是任何設備。

隨着數據大爆炸，也帶了不少挑戰，大規模的數據意味着用於存儲和分析數據的成本也大幅上升，搬運和分析數據也變得困難，總之，數據很難被利用。

最近這些年分佈式系統的一些理論也有了重大變化，CAP就是其中之一，CAP理論在2000年引入，在這個理論中，C表明一致性，A表明可用性，P表明分區容錯性，這個理論的核心觀點是在P發生時C和A不可能同時被知足，CAP是一個偉大的理論，可是對CAP理論也存在不少誤解，其中一個誤解就是C和A是互斥的，因此有些系統選擇放棄其中一個來知足另外一個，好比不少NoSQL數據庫，可是實際上，C和A的關係不是0和1的關係，而是100%和99%的關係。

如今咱們也能夠把P問題建模成A問題，P問題主要由網卡、交換機、錯誤的路由配置等故障引發，咱們考慮一下這樣一個例子，一個節點由於網卡錯誤而被網絡分區，到這個節點的請求會失敗，若是咱們可以將這個節點自動剔除，那麼請求會重試而且會被髮送到一個健康的節點，事實上，當一個節點宕機的時候咱們也採用一樣的處理方式，因此基本上，P和A問題在某些狀況下能夠看作是一類問題。

咱們如何把失敗的節點自動剔除而且可以同時保障數據一致性呢？咱們能夠用PAXOS算法來達到這個目的，PAXOS可以保證一致性，並且PAXOS只須要過半數的操做成功便可，因此當有網絡分區、宕機、慢節點出現時，咱們能夠容忍這些問題節點並作到自動剔除。若是超過半數節點被分紅了若干個分區，這時咱們選擇一致性犧牲可用性，可是在現實世界中這種狀況極少發生，因此在大多數狀況下，咱們能夠經過將P問題建模成A問題來同時保證完整的C和A。

 

20年前，只有政府和一些巨頭公司會選擇數據庫，如今從巨頭到小微企業全部的業務都會跑在數據庫上，並且對數據庫的需求也在發生變化。

首先，數據庫必須靈活，有時咱們須要作一個市場活動，好比黑色星期五，咱們不知道當天的真實流量，有時會有突發的熱點信息，這時流量會有一個飆漲而且是不可預測的，咱們但願數據庫可以靈活地進行擴展；其次，隨着全球化的發展，貿易也愈來愈透明，不少用戶的業務規模比較小，意味着利潤也不多，他們須要更經濟的解決方案；目前的客戶要求也比較嚴格而且對延遲很敏感，數據庫延遲越低帶給客戶的損失會越小；最後，數據庫必須對每個潛在的問題作到反應迅速，並能從問題狀態中快速恢復過來。

總之，目前對數據庫的潛在需求是：彈性、低成本、高性能、業務永續。

 

如今，全部的一切都是時刻在線的，在雲時代之前，數據散落在IDC中，如今數據都位於數據湖中，數據會在線產生而且同時被應用到訓練模型中，因此這些數據是在線產生、在線分析並在線應用；咱們的生活如今也是時刻在線的，好比衣食住行、工做、社交、娛樂等都是能夠在線解決的，你能夠用一部手機足不出戶就能活下來；如今你的客戶也是時刻在線的，他們遍及世界各地，不管白天仍是黑夜，一直在線。

 

在目前的中國，70%的新型企業都因數據挑戰而對業務產生了影響，他們面臨的問題主要有：高成本，他們負擔不起商業license和專業的工程師；他們有很強的發展的意願可是數據能力不夠強；對他們來講數據備份、數據挖掘和問題排查都是很是困難的事情；他們的數據目前像孤島同樣散落分隔在多個地方，數據沒法作到在線並被浪費，可是數據在持續增加爆炸，這些數據很難被存儲、轉移、分析並使用

根據上述演變趨勢和接踵而來的數據挑戰，咱們認爲一個雲原生的數據庫應該符合如下標準。

 

首先，一個雲原生數據庫不只是一個TP數據庫，也是一個AP數據庫，TP和AP融合在一塊兒，咱們稱之爲HTAP，咱們從這種架構中獲益良多；其次，雲原生數據庫必須是serverless的，有了serverless，咱們能夠大幅削減成本；最後，雲原生數據庫必須是智能的，就像一個顧問，能夠承擔不少診斷和管理工做，經過這些工做咱們能夠提高用戶體驗並讓用戶沒必要再關心這些枯燥棘手的事情。

接下來咱們詳細闡述一下。

在HTAP中TP和AP共享一份存儲，對於分析來講不存在任何數據延遲，因爲不須要數據同步，咱們也沒必要把數據從主節點同步到一個只讀節點，這時數據是實時的，對於時延要求比較苛刻的應用來講很是有益；當TP和AP共享一個存儲以後，至少會省去1個副本的成本，對於計算層，AP和TP經過容器來進行隔離，因此AP對TP沒有任何影響，並且有了這層隔離以後，TP和AP能夠輕鬆作到分別擴展。

有了serverless，產品規格或版本升級時能夠作到0成本，計算節點會跑在一個輕量的容器中，客戶端會話的生命週期比較短，因此當咱們進行滾動升級時，客戶端幾乎感知不到任何變化；有了serverless能夠輕鬆作到按需使用，按存儲付費，計算成本也很低，而且你能夠爲不一樣的業務模型指定不一樣的存儲策略，對於忙的業務，可使用更多的內存和SSD，對於閒置的業務，能夠把數據放到HDD盤上，這樣能夠大幅縮減成本。

提到智能，智能顧問會分析實例產生的如CPU/存儲/內存使用率和水位線等數據給你一個SQL或索引優化建議，在外人看來智能顧問就像是一個DBA，並把用戶也武裝成一個專業的DBA；當數據鏈路上有問題發生時，因爲數據鏈路又長又複雜，因此咱們不清楚問題到底出在哪裏，當咱們有一個監控和診斷系統後，咱們能夠輕鬆地去診斷整個鏈路並迅速給出根本緣由；智能顧問也能負責其餘如成本控制、安全、審計等職能。

在上述若干標準和門檻的指導下，咱們打造了一個全新的雲原生數據庫-POLARDB，我會從架構、產品設計、將來工做等幾個方面全方位闡述一下POLARDB。

這是一個POLARDB的架構大圖，上層是計算層，下層的存儲層，存儲和計算分離，他們中間經過RDMA高速網絡相鏈接，全部的邏輯都運行在用戶態，繞過了linux內核，在用戶路徑上，咱們實現了0拷貝，咱們同時實現了一個RAFT的變種ParellelRaft，它支持亂序提交，比傳統的Raft速度要快不少；咱們同時使用了大量新硬件，既能夠提高性能又能下降成本，POLARDB也是面向下一代硬件而設計。

對於計算節點，只有一個寫入口，R/W節點負責全部類型的請求，包括讀和寫請求，其餘節點都是隻讀節點，只能處理讀請求，對於存儲節點，咱們經過ParellelRaft算法來實現三副本一致性寫。咱們爲什麼要作存儲計算分離呢？首先，咱們能夠爲存儲和計算階段選取不一樣類型的硬件，對於計算層，咱們主要關注CPU和內存性能，對於存儲層，咱們主要關注低成本的存儲實現，這樣存儲和計算節點都能作到定製化和針對性優化；分離以後計算節點是無狀態的，變得易於遷移和failover，存儲的複製和HA也能夠獲得針對性的提高；存儲如今能夠方便地池化，以塊爲單位進行管理，因此再也不會有碎片問題、不均衡問題，而且易於擴展；在這種架構下，也很容易實現serverless，當你的業務比較空閒時你甚至能夠不須要任何計算節點。

 

在POLARDB中，任何邏輯都跑在用戶態，一個請求從數據庫引擎發出，而後PFS會把它映射成一組IO請求，而後PolarSwitch會把這些請求經過RDMA發送到存儲層，而後ParellelRaft leader處理這些請求並經過SPDK持久化到磁盤上，同時再經過RDMA同步兩份數據到兩個followers，在整個路徑上沒有系統調用，也就沒有上下文切換，同時也沒有多餘的數據拷貝，沒有上下文切換加0拷貝使得POLARDB成爲一個極快的數據庫。

 

這是POALRDB文件系統-PFS的詳細說明，PFS具備POSIX API，對數據庫引擎侵入性很低，PFS是一個靜態庫並被連接到數據庫進程中，PFS是一個分佈式文件系統，文件系統的元數據經過PAXOS算法進行同步，因此PFS容許並行讀寫，爲了訪問加速，在數據庫進程中有元數據的緩存，緩存經過版本控制來進行失效操做，爲了便於你們理解PFS，這是PFS和傳統文件系統的一個類比。

 

咱們使用ParellelRaft來同步三份數據，ParellelRaft是Raft的變種之一，Raft不容許亂序提交和日誌空洞，這些限制讓Raft性能比較低、吞吐比較小，在ParellelRaft中，咱們容許亂序提交、確認、和應用，事務的語義和串行化由數據庫引擎層來負責，對於空洞咱們有一整套完整的catch-up機制，這是一個很是複雜的過程，在VLDB 2018的論文中，咱們有詳細論述，這篇論文剛被接收。

 

在POLARDB中，咱們使用了一些新硬件並最大化利用這些硬件的能力，除了RDMA，咱們還在研究open-channel來最大化SSD的價值，咱們也在經過3D XPoint技術在加速存儲層。

 

 

這是POLARDB和RDS的對比壓測結果，咱們使用sysbench來進行壓測，紫色的柱子表明POLARDB，粉色的表明RDS，經過這些數字能夠看出，在使用相同資源的狀況下，POLARDB的平均讀性能是RDS的6倍，平均寫性能是RDS的3倍，因此這個提高是巨大的。

 

咱們接下來看一下POLARDB的產品特色，性能上，很容易擴展到100W QPS，而且延遲小於2ms；存儲最大支持100TB；彈性上，能夠很方便作橫向和縱向擴展，而且在規格升級時0宕機無干擾；對於兼容性，會100%兼容MySQL；在可用性上，當有錯誤發生時，咱們會選擇一致性犧牲可用性，因此目前咱們承諾3個9的可用性，在數據可靠性上，咱們承諾5個9。

 

在POLARDB中，讀和寫被分離到不一樣的節點上，只有一個寫節點，寫節點能夠處理讀寫請求，能夠有多個只讀節點，寫QPS最多可達13W，讀QPS能夠很方便地擴展到幾百萬。

 

對於可擴展性，全部節點均可以作縱向擴展，只讀節點能夠作橫向擴展，實例的存儲能夠作縱向擴展，存儲集羣能夠作橫向擴展，當讀寫節點和只讀節點之間作failover時能夠作到0宕機。

 

 

對於數據遷移，你能夠經過加載一個OSS（相似AWS S3）上的備份來啓動你的數據庫，也能夠經過將POLARDB當成RDS的slave來從RDS實時複製數據，也能夠利用DTS（data transfer service數據傳輸服務）來從RDS和其餘數據庫遷移到POLARDB。

 

對於數據可靠性，咱們能夠作到1個region內可用區內多個可用區之間的failover，你能夠在其餘可用區啓動一個standby實例而且使用redolog來進行復制，也能夠在多個region之間failover，咱們一般使用binlog進行復制，對於備份，咱們能夠秒級打出一個snapshot而後傳輸到OSS上。

 

下面是POLARDB的一些將來工做，目前POLARDB還只是個嬰兒，咱們仍然有大量工做須要去作，在引擎層咱們將會支持多寫，目前POLARDB是一個共享磁盤的架構，將來會是一個共享全部資源的架構，好比在計算層咱們會引入一個集中化Cache的角色來提高咱們的查詢性能，咱們也在移植更多的數據庫到POLARDB，好比更多的MySQL版本、PostgreSQL、DocumentDB等。在存儲層，咱們會使用3D XPoint技術來提高IO性能，咱們也會經過open-channel技術在提高SSD性能，未來咱們也會將更多引擎層的邏輯進行下推，儘可能減小更多的IO，讓計算層更加簡單。

 

關於學術咱們的基本思想是：學術要在工程落地，工程要有學術產出，沒有單純的工程或者學術。咱們團隊已經向Sigmod和VLDB提交了數篇論文，最近這些論文將會出版，你們會看到更多的關於POLARDB和它的分佈式存儲的詳細的信息，咱們也正在歐洲進行招聘，咱們在巴黎和德國都設有辦公室。

 

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：