ICDE：POLARDB定義雲原生資料庫

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

end

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