從新定義數據庫的時刻，阿里雲數據庫專家帶你瞭解POLARDB

摘要：POLARDB是阿里雲ApsaraDB數據庫團隊研發的基於雲計算架構的下一代關係型數據庫，其最大的特點是計算節點與存儲節點分離，藉助優秀的RDMA網絡以及最新的塊存儲技術。POLARDB不但知足了公有云計算環境下用戶業務快速彈性擴展的剛性需求，同時也知足了互聯網環境下用戶對數據庫服務器高可用的需求。本文就帶領你們瞭解什麼是「雲原生數據庫」，雲原生數據庫的標準是什麼，如何定義以及爲什麼如此定義？爲你們介紹下一代雲原生數據庫POLARDB的架構、產品設計、將來工做等內容。

如下內容根據演講嘉賓視頻分享以及PPT整理而成，PPT下載連接。

演講嘉賓簡介：蔡松露（子嘉），阿里云云數據庫總架構師，主要負責阿里雲POLARDB、NoSQL技術以及阿里雲數據庫總體架構等工做。在搜索引擎、NoSQL數據庫、分佈式系統、操做系統內核等領域有深厚積累與豐富的經驗。

本文主要內容有：

• 1、什麼是雲原生數據庫
• 2、雲原生數據庫POLARDB架構實現
• 3、雲原生數據庫POLARDB產品設計

1、什麼是雲原生數據庫

POLARDB是一個雲原生數據庫，關於雲原生，演講者團隊在ICDE上作了相關闡述。本文經過視頻整理，從架構和產品設計方面介紹POLARDB的架構和實現。

首先介紹實現雲原生的門檻（PPT內容以下圖所示），一個雲原生的數據庫必須擁有出色的性能，有上百萬的QPS，規模很容易擴展到上百TB，同時在版本升級時儘可能知足零宕機，最重要的一點是百分百兼容開源生態。門檻的定義，咱們能夠經過下面例子理解，一輛車可能有很拉風的外觀，又有很快的速度，可是這輛車不能被直接稱爲跑車，也有多是山寨車。也就是說以上的四點只是達到了雲原生數據庫的門檻值，還並不表明是這一個雲原生的數據庫。

 

下面介紹實現雲原生的標準，首先咱們看下圖中所展現的，這些年數據庫的演變。從數據庫的規模來看，咱們現現在處在一個數據爆炸的時代，從線性增加到現在指數級別的增加，數據庫領域的核心理論也在發生變化，分佈式系統領域中的CAP理論是指導咱們設計系統的原則和基石，可是這個理論在最近幾年也在發生改變，同時，最近也出現了不少的理論算法，例如paxos，raft等，如何應用這些算法到數據庫架構的設計中是一個問題。另外，客戶也在發生變化，之前的數據庫客戶來自於銀行，政府或者全世界前500強企業，但如今的形式已經發生了巨大的轉變，如今數據庫的主體變成了互聯網+，IOT等公司。此外，基礎設施也在發生變化，之前用的是IDC等，如今不少新興的業務都往雲上遷移，並且在這個過程當中一切都是在線的，包括用戶與數據。

 

下圖很好地展現了現在的數據爆炸形勢。下圖出自互聯網女皇米克爾的互聯網形勢報告，經過報告，下圖將互聯網大概分爲三個時代，第一是PC互聯網時代，數據主要由PC產生；第二是移動互聯網時代，數據產生自衣食住行，社交，工做等多個方面；第三是物聯網時代，數據由傳感器和終端設備產生，數據量從之前的線性增加變成了指數級別的增加。數據爆炸使得處理數據的成本愈來愈大，怎麼採集數據，怎麼存儲數據，怎麼搬運分析數據，都變得越發複雜。操做數據的複雜性直接帶來的後果就是，數據很難再被利用。可是，在這個新時代，數據像是石油，價值很是之大。

 

下圖解釋了CAP理論是怎麼變化的。CAP中C表明一致性，A表明可用性，P表明分區容忍性，CAP的核心在於指出了當網絡分區發生時，一致性和可用性是沒法被完美地保證，沒法同時被知足。C和A不是０和１的關係，而是９９％和１％的關係，也就是說C和A不是互斥關係，它們是能夠無限逼近的。在有些場景下，P問題和A問題能夠建模成相同的問題，谷歌大神Jeff Dean有篇論文中對這個問題作了很好的闡述，他認爲在某些場景下，P問題本質上就是A問題。P產生可能有兩種狀況，第一種，多是網卡宕機了致使機器發生了網絡分區，也多是交換機掛掉致使一堆機器也掛了。網卡掛掉了，看上去像機器在系統中消失了，但本質上和宕機沒有區別，由於宕機看上去也是機器忽然消失了，因此在這種狀況下，P問題就是A問題。第二種，機器的硬件不穩定，好比磁盤很卡致使響應請求很慢，這時候取決於怎麼建模， P或A問題均可以解釋。Paxos的核心在於每作一個決定時，多數派贊成就行，能夠容忍少數派不一樣意，因此Paxos對網絡分區是有容忍性的，若是三個副本中的一個副本寫的比較慢或者出現了問題，在Paxos下不會影響其餘兩個副本，仍然會正確返回結果。當發生大規模的宕機時，若是系統中使用Paxos利用拓撲容忍單個交換機掛掉的狀況。若是多個交換機掛掉，甚至出現了3-4個網絡分區，做爲一個數據庫，追求的是百分百的C，其次纔是A。可是，時間上，多個交換機所有掛掉的概率很是小，相反，幾臺機器出問題的機率很是大，因此應該着重於解決常見問題，以後使得C和A無限逼近。

 

下面介紹客戶發生的變化，以下圖所示。客戶對數據庫的需求正不斷演變，首先客戶但願數據庫更靈活，尤爲對一些創業公司來講，機會是很是重要的，例如，當出現熱點新聞，或者舉辦雙十一的活動，公司很不但願數據庫成爲效率的瓶頸。此外，客戶但願下降使用數據庫的成本，也但願數據庫更高效，可以花更少的錢買到更多的能力。同時，客戶但願數據庫更敏捷，假設一個公司在舉辦雙十一活動時，系統掛1個小時或1分鐘是徹底不一樣的概念，也就是說客戶但願在有故障發生時，數據庫是靈活的，自治的，能快速從從故障中恢復過來。總結一下，現階段，客戶對數據庫的要求是，彈性，低成本，高性能，業務永續性。

 

在新時代，數據是實時在線產生，收集，清洗，存儲，分析的（即Everything is Online），再實時的應用到算法訓練模型上。在中國，大概有70%的新興公司都遇到了數據化的挑戰，數據化的挑戰也影響到了客戶的業務。以下圖中列出了遇到的一些挑戰，主要有高成本，能力不足(沒有專業的工程師，沒法實現數據的備份，數據挖掘等功能)，數據孤島化（數據散落在各個IDC或自建的機房中，沒有被很好的利用），數據規模很大（難以存儲，搬運，分析，利用）。

 

以上提到的挑戰促使咱們設計雲原生的數據庫，根據總結的挑戰，得出了設計雲原生數據庫的標準，以下圖所示。首先，雲原生數據庫必須是HTAP的，是一整套解決方案，不只知足TP的需求也知足AP的需求，使得TP和AP不須要遠程同步，再作數據的轉換，數據之間沒有延遲，同時，能用一份存儲同時完成TP和AP，明顯下降了用戶的存儲成本；另外，雲原生數據庫應是serverless的，能夠將存儲進行分級，將成本降到最低，而且在serverless下的升降配很是簡單；最後，雲原生數據庫必須是智能化的，能提供一些SQL優化，索引等，能實時監控診斷，也能提供管理系統方便成本控制。

 

下面將詳細介紹作HTAP的緣由，以下圖所示。首先，HTAP對於分析來講，不存在任何延遲，對於實時性要求較高的業務是很是重要的，好比說實時反欺詐，過海關時須要調查的信息。同時，在架構中不須要同步，共用一份存儲後，成本也會下降，不須要額外複製副本。AP和TP在計算層是被分開的，物理上徹底隔離，能夠在不一樣的維度擴展AP和TP，當AP的需求多，TP需求少時，能夠擴展AP的結點，反之，擴展TP的結點，同時，AP也對TP不會形成干擾。

 

下面介紹實現Serverless的緣由，以下圖所示。緣由主要在於兩個方面，一個是成本，客戶只爲使用或存儲付費，並且客戶能夠根據本身的業務模型定製不一樣的存儲級別，好比說冷存儲或熱存儲。這使得用戶的消費呈現階梯性，不會出現很大的躍遷。用戶在剛辦網站，流量還不多時，這時候能夠採用serverless架構，在存儲層使用冷存儲，雖然延遲可能會大一些，但這是最經濟的作法。隨着業務的擴大，也能夠在計算層繼續使用Serverless架構，在存儲層將冷存儲換成熱存儲，業務再次擴大時，能夠在計算層加一些結點，這樣很大的提升了靈活性。

 

下面介紹提供智能化的緣由，以下圖所示。不少創業公司一開始支出較少，各方面的人才配置並不會齊全，雲原生數據庫的智能化可以告訴這些創業公司，該如何應對遇到的一些問題。同時，系統須要告訴用戶此時此刻全鏈路的情況，存在哪些問題，如何解決。有了這些功能以後，能幫助用戶從小白成爲數據庫專家，分佈式系統專家，財務安全專家。

 

2、雲原生數據庫POLARDB架構實現

下文從架構，產品設計與將來工做介紹POLARDB。下圖展示了POLARDB的總體架構，藍色的線表明數據流，紅色的線爲控制流。控制流主要負責POLARDB生命週期的管理，數據流展示數據在整個系統中流轉的狀況。在設計POLARDB時遵循如下四個原則，第一爲存儲計算分離，全用戶態，零拷貝。在架構的存儲層使用三副本，採用變種raft算法，容許亂序的提交確認和應用，亂序也會引入一些問題。在設計POLARDB時，大量採用新硬件，例如RDMA，3D XPOINT等。

 

下面介紹進行存儲計算分離的緣由，以下圖所示，上面一層爲計算層，下面一層爲存儲層，兩層使用RDMA鏈接。在計算層有一個主結點負責讀寫請求，還有一些備結點，只負責接收讀請求。存儲計算分離的好處在於對一體化架構的數據庫進行水平切分，至關於切成了兩層，對於這兩層之前必須使用相同的硬件，如今能夠根據這兩層不一樣的特色定製不一樣的硬件策略。例如，在計算層更關注CPU和內存，在存儲層更關注I/O響應時間和I/O成本，因此分離以後，針對這兩層作出的硬件差異是很大的，這種差異又會帶來新的紅利，這些紅利又能夠釋放給用戶，這就是有時候技術優秀，成本還低的緣由。在計算層，計算不持有數據，很方便進行遷移，在存儲層，從原來大一統的架構中拆分出來，能夠針對存儲（分佈式文件系統）有本身的複製策略，高可用的策略。相較於之前大一統的架構設計，若是對存儲作一些策略會干擾到計算，對計算作策略可能干擾到存儲。存儲分離出來後，很方便進行池化，池化的好處在於沒有碎片，也不會有不均衡的狀況出現。若是有不均衡，存儲層能夠本身進行遷移。存儲計算分離也能方便實現serverless。

 

下圖展現了全用戶態的設計，有用戶態的文件系統，有Libpfs(分佈式文件系統)，有本地相似於網關的polarswitch，有用戶態的IO棧，用戶態的網絡。POLARDB性能的提高很大一部分來自於全用戶態和對新硬件的利用。消除進程切換，以及內存拷貝帶來的收益很是大。

 

下圖是對文件系統的詳細解釋，文件系統的特色是使用POSIX API，對DB層的侵入較小。同時，它是一個靜態庫，直接連接到數據庫進程中。分佈式系統的元數據是經過PAXOS進行同步的，帶來的好處是，多臺機器看到的是同一個目錄，當用戶去操做目錄時，PAXOS能夠在底部作一個串行，因此不會存在數據衝突的問題。在每一個計算層的節點上，都會有對元數據的緩存，目的是作訪問加速。

下圖展現了ParallelRaft算法，亂序會讓寫入加速，帶來接近翻倍的性能提高。

 

架構也用到了大量的新硬件，以下圖所示，包括RDMA，3D XPOINT，演講者團隊正在研究的Open-Channel SSD。雖然SSD已經工業化不少年了，主流的存儲都是SSD，可是目前對SSD的應用還存在不少問題。由於SSD的軟件和硬件並非很是匹配，致使咱們對SSD的使用存在浪費，浪費一方面來自性能以及壽命。Open-Channel SSD方式對IO性能和壽命的影響最終反映到成本上，都比之前有了很大的提高。

 

下圖展示了POLARDB和MySQL的對比結果，讀性能相較於MySQL提升了５－６倍，寫性能提升了３倍左右。同時，性能也在不斷提高。

 

3、雲原生數據庫POLARDB產品設計

接下來介紹一些產品設計的特色，主要從五個維度設計產品，以下圖所示，首先是性能，應該很方便地就能擴展到上百萬QPS，並且RT很低；存儲能夠很方便的擴展到100TB，也很方便的縮回來；彈性上，版本升級時，儘可能作到零宕機，在存儲層，計算層能夠方便進行scale-up以及scale-out；目前100%能兼容MySQL5.6；在可用性方面，承諾99.95%的可用性，99.999%的可靠性。在數據安全方面，演講者團隊會作定時的snapshot，並實時上傳到OSS，提供物理備份和邏輯備份。在可用性上，主結點和readonly結點能夠很方便的進行角色切換。

 

產品設計上是讀寫分離的，以下圖所示，有一個結點是主結點接收讀寫請求，能夠很方便地進行scale-up，其餘結點都是隻讀結點，只讀結點能夠很方便的進行scale-out。讀能力和只讀結點的數量呈線性正比。

 

可擴展性方面，以下圖所示，能夠在計算層作scale-out和scale-up，從用戶看來存儲層是在作scale-up，但由於底層是分佈式文件系統，當存儲水位比較高時能夠很方便的加入新的存儲結點，因此本質上是scale-out。

 

在數據遷移方面，以下圖所示，假設你是一個RDS的用戶，經過備份到OSS，在POLARDB的實例里加載OSS上的備份的數據新生成POLARDB的實例，也能夠經過DTS進行數據實時的遷移。在將來還能夠提供一種方式，將POLARDB作成slave，直接掛到RDS的結點上，把數據實時的同步。若是用戶使用的是第三方商用的數據庫，由於DTS支持的數據庫類型很是多，因此建議使用DTS。

 

在數據可靠性上，以下圖所示，目前在官網上購買到的版本是在一個AZ裏面的三副本。

 

將來工做中，在DB引擎層將來會提供多寫的能力，並且數據庫引擎層會引入新的組件例如CacheFusion，最大提高計算層的性能。將來會支持更多的數據庫類型，在存儲層會應用更多新的硬件，對某些IO進行加速，會用Open-Channel SSD對性能進一步提高，成本進一步下降。在掃描時，作計算下推，使回到計算層的數據儘可能少。演講者但願現有的分佈式文件系統和數據庫聯繫的更緊密，能感知InnoDB的語義。

 

原文連接