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

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

本文主要內容有：

• 一、什麽是雲原生數據庫

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

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

一、什麽是雲原生數據庫

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架構，在存儲層將冷存儲換成熱存儲，業務再次擴大時，可以在計算層加一些結點，這樣很大的提高了靈活性。

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

二、雲原生數據庫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提高了５－６倍，寫性能提高了３倍左右。同時，性能也在不斷提升。

三、雲原生數據庫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的語義。

原文鏈接

重新定義數據庫的時刻，阿裏雲數據庫專家帶你了解POLARDB