摘要：?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和它的分布式存儲的詳細的信息，我們也正在歐洲進行招聘，我們在巴黎和德國都設有辦公室。

原文鏈接

干貨好文，請關注掃描以下二維碼：

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的ICDE:POLARDB定义云原生数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。