簡(jiǎn)介：作者：蔡樂

本文主要分享一下Polar DB for PG的開源路線圖，雖然路線圖已經(jīng)擬定，但是作為開源產(chǎn)品，所有參與者都能提出修改意見，包括架構(gòu)核心特性的技術(shù)以及周邊生態(tài)和工具等，希望大家能夠踴躍提供想法和建議，幫助產(chǎn)品提升。

本文主要圍繞項(xiàng)目的背景和路線圖來展開，傳統(tǒng)數(shù)據(jù)庫(kù)產(chǎn)品已經(jīng)研發(fā)了40多年，知名廠家有很多，產(chǎn)品也是層出不窮。看看數(shù)據(jù)庫(kù)排行榜，就知道我們面對(duì)多么豐富的數(shù)據(jù)庫(kù)產(chǎn)品族譜，加上最近10年來大數(shù)據(jù)NoSQL、NewSQL的興起，數(shù)據(jù)庫(kù)產(chǎn)品逐漸和大數(shù)據(jù)處理產(chǎn)生融合的趨勢(shì)，任何一個(gè)新研發(fā)的數(shù)據(jù)庫(kù)產(chǎn)品一定離不開這些背景，選擇一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品的技術(shù)方向，同樣受到大環(huán)境的影響和約束。

本文將花一些時(shí)間闡述對(duì)這個(gè)背景的理解和分析，并在此基礎(chǔ)上提出產(chǎn)品開源的路線圖及其所要達(dá)成的目標(biāo)和需要解決的問題。

一、 背景

（一）飲水思源，回饋開源，成就開源

首先介紹的背景是關(guān)于開源，講講現(xiàn)在數(shù)據(jù)庫(kù)上云是如何利用開源的，然后如何回饋了到開源產(chǎn)品，并且最終成就開源。

過去數(shù)據(jù)庫(kù)作為傳統(tǒng)的IT基礎(chǔ)設(shè)施，基本上壟斷在幾大主力的廠商手里。雖然開源數(shù)據(jù)庫(kù)產(chǎn)品很多也很流行，比如MySQL等，都是叫好不叫座，掙錢能力不足，商業(yè)能力可能不是很好，這其實(shí)由下面的一些因素來決定。因?yàn)閿?shù)據(jù)庫(kù)作為核心的IT基礎(chǔ)設(shè)施，因此對(duì)其可靠性、穩(wěn)定性、功能全面性和性能要求很高，每個(gè)企業(yè)在選型數(shù)據(jù)庫(kù)時(shí)非常謹(jǐn)慎，開源數(shù)據(jù)庫(kù)在10年前也沒有拿出足夠的能力來撼動(dòng)這些商業(yè)數(shù)據(jù)庫(kù)的地位。

其次就是在商業(yè)上，由于以前使用數(shù)據(jù)的大部分都是大客戶，有充足的資源，他們當(dāng)然希望被大公司來服務(wù)。上述兩個(gè)因素形成了商用數(shù)據(jù)庫(kù)的生態(tài)，用戶DBA開發(fā)以及中間商，大家都是基于這些商用數(shù)據(jù)庫(kù)工作，所以一個(gè)新產(chǎn)品如果想要進(jìn)入，它面臨的門檻是非常高的，自然就形成壟斷，造成某些廠商一枝獨(dú)大。

隨著IT的云化，公有云市場(chǎng)的發(fā)展，比如AWS，阿里云等，這些后期的IT提供商從計(jì)算，存儲(chǔ)，資源優(yōu)化開始，為用戶提供按需的資源，進(jìn)而自然進(jìn)入基礎(chǔ)軟件的供應(yīng)。

顯然，使用來自壟斷廠商生產(chǎn)的商用數(shù)據(jù)庫(kù)為云用戶提供服務(wù)，將導(dǎo)致云的利潤(rùn)都被商用數(shù)據(jù)庫(kù)廠商拿走，將開源數(shù)據(jù)庫(kù)，特別是像MySQL、PostgreSQL推上前線，和商用數(shù)據(jù)庫(kù)一爭(zhēng)高低，是其背后的商業(yè)背景和目的決定的，其中的路徑基本上有下面幾步。

首先是完善這些數(shù)據(jù)庫(kù)的企業(yè)級(jí)管理能力，也就是今天所謂的RDS服務(wù)，比如數(shù)據(jù)庫(kù)的部署，數(shù)據(jù)庫(kù)的啟動(dòng)、停止升級(jí)，擴(kuò)容備份恢復(fù)等操作。這些管理能力的云化和完善，使得上云的用戶不再需要DBA來管理數(shù)據(jù)庫(kù)，極大減少了用戶的運(yùn)營(yíng)成本。

因此，第一步是開源數(shù)據(jù)庫(kù)上云，用云化管理來替代DBA，實(shí)現(xiàn)對(duì)商用數(shù)據(jù)庫(kù)的商業(yè)模式的超越。當(dāng)然，云化的數(shù)據(jù)庫(kù)資源的隨用隨取也是一個(gè)非常重要的點(diǎn)。完成這一步還不夠，畢竟開源數(shù)據(jù)庫(kù)在本身能力上和商業(yè)數(shù)據(jù)庫(kù)是有一定差別的。

要想取得商用數(shù)據(jù)庫(kù)開辟的大市場(chǎng)，開源數(shù)據(jù)庫(kù)的云化增強(qiáng)就開始了，因?yàn)檠a(bǔ)上差距是不夠的，不能夠吸引客戶轉(zhuǎn)投開源數(shù)據(jù)庫(kù)，必須有超越商用數(shù)據(jù)庫(kù)技術(shù)的的技術(shù)和競(jìng)爭(zhēng)力。

比如阿里云開發(fā)了PolarDB，首先對(duì)數(shù)據(jù)庫(kù)依賴的存儲(chǔ)系統(tǒng)進(jìn)行云化改造，提供云延伸的擴(kuò)展性和資源彈性，同時(shí)對(duì)外維持開源數(shù)據(jù)庫(kù)的所有特性，保證開源數(shù)據(jù)庫(kù)的生態(tài)可以很好地被繼承。

改造解決了商用數(shù)據(jù)庫(kù)對(duì)底層存儲(chǔ)硬件固有的依賴，比如其性能和容量完全受限于存儲(chǔ)硬件，不容易擴(kuò)容，也不能實(shí)時(shí)在線地提供按需吞吐，后續(xù)引入的一寫多讀分布式以及Global DataBase的技術(shù)，使得云原生基于開源數(shù)據(jù)庫(kù)的產(chǎn)品，完成了對(duì)傳統(tǒng)商業(yè)數(shù)據(jù)庫(kù)的技術(shù)超越，為用戶提供了它們不能提供的價(jià)值和競(jìng)爭(zhēng)力。

阿里云在使用開源數(shù)據(jù)庫(kù)的同時(shí)，也在不斷地為開源社區(qū)輸出企業(yè)級(jí)的技術(shù)。比如阿里維護(hù)了MySQL分支AliSQL，比如我們推入PG社區(qū)的全局臨時(shí)表功能。

我們無法往社區(qū)推很多東西，因?yàn)镻G社區(qū)非常謹(jǐn)慎的，對(duì)每一個(gè)特性的需求和設(shè)計(jì)都有非常嚴(yán)格的要求，需要經(jīng)過多位重量級(jí)的Commit的同意和競(jìng)爭(zhēng)開發(fā)者的同意。很多特性在社區(qū)歷史上都被其他開發(fā)者開發(fā)過，只是設(shè)計(jì)角度和覆蓋方面沒有滿足社區(qū)的需求而被擱置。任何一個(gè)Patch，都是需要超越以前的版本，最終才能被PG社區(qū)接收。

我們經(jīng)過半年多的時(shí)間，最終實(shí)現(xiàn)了被社區(qū)所接受的特性。考慮到社區(qū)版本演進(jìn)的謹(jǐn)慎性，我們有許多技術(shù)可以回饋開源社區(qū)，但是因?yàn)樯鐓^(qū)的相對(duì)謹(jǐn)慎，我們很難做到這個(gè)事情，其中的周期非常長(zhǎng)，這就成為我們開源PalarDB的一個(gè)重要原因。我們希望開源的技術(shù)是對(duì)社區(qū)內(nèi)核能力的輔助增強(qiáng)，所以最好都是垂直于社區(qū)能力，用戶拿我們的開源軟件加上社區(qū)的內(nèi)核版本，就可以同時(shí)享用兩邊的貢獻(xiàn)，就是我們目前選擇開源高可用能力、分布式擴(kuò)展能力、后續(xù)云化運(yùn)維能力等功能的主要考慮因素。

通過這些技術(shù)的開源，我們就可以和社區(qū)共同成長(zhǎng)，我們的技術(shù)就是社區(qū)的一份子，同時(shí)社區(qū)的發(fā)展也能夠幫助我們更好地服務(wù)客戶，最終收益的是開源社區(qū)和我們的用戶，社區(qū)和開源數(shù)據(jù)庫(kù)的用戶們獲得了共同成長(zhǎng)的利益和價(jià)值，而阿里數(shù)據(jù)庫(kù)團(tuán)隊(duì)將成為其中的一個(gè)助力，這是我們對(duì)開源產(chǎn)品的理解。

（二）數(shù)據(jù)庫(kù)架構(gòu)

接下來介紹的是關(guān)于數(shù)據(jù)庫(kù)的架構(gòu)，它是如何演進(jìn)，現(xiàn)在有哪些數(shù)據(jù)庫(kù)的架構(gòu)。

上圖列了三種架構(gòu)，最左邊的是單機(jī)數(shù)據(jù)庫(kù)，一臺(tái)服務(wù)器在運(yùn)行一個(gè)數(shù)據(jù)庫(kù)，存儲(chǔ)就是本地磁盤系統(tǒng)，用戶通過網(wǎng)絡(luò)連接數(shù)據(jù)庫(kù)進(jìn)行SQL查詢和計(jì)算。

很明顯，這種架構(gòu)的問題是當(dāng)數(shù)據(jù)庫(kù)故障的時(shí)候，用戶服務(wù)將會(huì)被中斷，同時(shí)本地盤系統(tǒng)的容量和吞吐有限，當(dāng)用戶負(fù)載增加的時(shí)候，單機(jī)數(shù)據(jù)庫(kù)會(huì)出現(xiàn)服務(wù)響應(yīng)時(shí)間過長(zhǎng)等性能問題。但有些商用數(shù)據(jù)庫(kù)、開源數(shù)據(jù)庫(kù)、MySQL、PostgreSQL，它在一臺(tái)服務(wù)器上部署的時(shí)候就是這種類型。

中間這個(gè)架構(gòu)又稱為共享存儲(chǔ)或Shared Everything架構(gòu)，其特點(diǎn)是多個(gè)數(shù)據(jù)庫(kù)實(shí)例共享一個(gè)存儲(chǔ)系統(tǒng)。一般這種存儲(chǔ)系統(tǒng)它是由硬件廠家生產(chǎn)，或者通過云化的存儲(chǔ)服務(wù)，具備更高的性能和容量。多個(gè)數(shù)據(jù)庫(kù)實(shí)例除了可以共享這種系統(tǒng)外，還可以共享一個(gè)數(shù)據(jù)庫(kù)，包括其字典表、用戶表等。這些數(shù)據(jù)庫(kù)實(shí)例可以寫也可以讀，比如Oracle其數(shù)據(jù)庫(kù)實(shí)例就是可以同時(shí)讀寫，共享存儲(chǔ)。PolarDB現(xiàn)在只有一個(gè)寫節(jié)點(diǎn)，其他節(jié)點(diǎn)都是讀節(jié)點(diǎn)。這個(gè)架構(gòu)的特點(diǎn)是計(jì)算和存儲(chǔ)分離，數(shù)據(jù)庫(kù)計(jì)算有專門的數(shù)據(jù)庫(kù)節(jié)點(diǎn)來完成，而存儲(chǔ)有專門的硬件或者云化存儲(chǔ)系統(tǒng)來實(shí)現(xiàn)。

另外一個(gè)特點(diǎn)是當(dāng)有實(shí)例故障的時(shí)候，可以快速恢復(fù)，快速地切換負(fù)載到其他實(shí)例上去執(zhí)行，中斷時(shí)間非常短。但用戶負(fù)載和要求吞吐增加的時(shí)候，這個(gè)架構(gòu)需要提升硬件的規(guī)格來實(shí)現(xiàn)能力的提升，比如增加數(shù)據(jù)庫(kù)節(jié)點(diǎn)的CPU核數(shù)，增加共享存儲(chǔ)的能力等，所以這種擴(kuò)展能力我們稱之為垂直擴(kuò)展或叫做Scale up。

最右邊這個(gè)架構(gòu)稱為Shared Nothing架構(gòu)，或者叫分布式架構(gòu)，每個(gè)數(shù)據(jù)庫(kù)實(shí)例和單機(jī)數(shù)據(jù)庫(kù)類似，有自己的存儲(chǔ)和計(jì)算資源，每個(gè)數(shù)據(jù)庫(kù)實(shí)例都是一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)。但是，這些數(shù)據(jù)庫(kù)通過一定的MetaData和字典表的管理，實(shí)現(xiàn)對(duì)用戶來看就是一個(gè)數(shù)據(jù)庫(kù)。每一個(gè)數(shù)據(jù)庫(kù)實(shí)例其實(shí)管理一個(gè)分片數(shù)據(jù)庫(kù)，存儲(chǔ)一部分?jǐn)?shù)據(jù)庫(kù)的數(shù)據(jù)，相互之間是邏輯和物理的隔離，所以稱之為是Shared Nothing架構(gòu)。其主要特點(diǎn)是當(dāng)涉及多個(gè)分片數(shù)據(jù)庫(kù)時(shí)，需要執(zhí)行分布式的SQL計(jì)算，需要通過分布式事務(wù)保持事務(wù)一致性，這種架構(gòu)的優(yōu)點(diǎn)是系統(tǒng)可以水平擴(kuò)展。

當(dāng)用戶需要更大的存儲(chǔ)容量，更高的計(jì)算吞吐時(shí)，就可以通過增加數(shù)據(jù)庫(kù)分片，也就是數(shù)據(jù)庫(kù)節(jié)點(diǎn)的方式來提升系統(tǒng)容量性能，這種擴(kuò)展方式稱為水平擴(kuò)展或叫Scale out。

開源的Polar DB將是后面兩種架構(gòu)的融合。

（三）數(shù)據(jù)庫(kù)系統(tǒng)的演進(jìn)

接下來介紹一下數(shù)據(jù)庫(kù)系統(tǒng)的演進(jìn)，以及演進(jìn)對(duì)我們開源數(shù)據(jù)庫(kù)產(chǎn)品的路線的影響。

無論是傳統(tǒng)的商業(yè)數(shù)據(jù)庫(kù)，還是我們開源數(shù)據(jù)庫(kù)MySQL或PG，它處理的都是關(guān)系型的數(shù)據(jù)，也就是結(jié)構(gòu)化的數(shù)據(jù)。其中又分為兩種,RDBMS也就是關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)，主要處理在線的交易型負(fù)載，比如ATM，商家的在線交易等等。

另外一個(gè)稱為Data Warehouse，也就是數(shù)據(jù)倉(cāng)庫(kù)。和RDBMS一樣，都使用標(biāo)準(zhǔn)的SQL來處理數(shù)據(jù)，但是其負(fù)載涉及大量數(shù)據(jù)，很多表計(jì)算非常復(fù)雜，典型的應(yīng)用為ETL和在線分析計(jì)算。

隨著大數(shù)據(jù)的興起，Hadoop平臺(tái)的普及，用戶希望處理的數(shù)據(jù)類型逐漸多樣化，比如時(shí)間序列、地理數(shù)據(jù)、圖、向量、文本等等。相應(yīng)的數(shù)據(jù)處理產(chǎn)品涌現(xiàn)，它們區(qū)別于關(guān)系型數(shù)據(jù)庫(kù)的最大差別是處理的數(shù)據(jù)類型和使用的處理語言是不一樣的，以及它們和Hadoop等大數(shù)據(jù)平臺(tái)的融合，帶來了極高的可用性和擴(kuò)展性，能夠水平擴(kuò)展到幾十臺(tái)甚至幾百臺(tái)、上千臺(tái)服務(wù)器上。

受這些產(chǎn)品的啟發(fā)，許多新型數(shù)據(jù)庫(kù)系統(tǒng)開始轉(zhuǎn)向分布式的高可用、高擴(kuò)展，引入了共識(shí)協(xié)議，實(shí)現(xiàn)高可用，同時(shí)維持對(duì)數(shù)據(jù)庫(kù)處理語言SQL的支持，典型例子有Google的Spanner，雖然這些NewSQL實(shí)現(xiàn)了上述目標(biāo)，但是其對(duì)SQL支持的完整度上和開源數(shù)據(jù)庫(kù)仍然有一定的差距，可以說只是后者的子集，需要投入很大的資源來完善這部分功能。

我們的想法是能否在開源數(shù)據(jù)庫(kù)的基礎(chǔ)上引入分布式，引入共識(shí)協(xié)議，以及存儲(chǔ)和計(jì)算層的彈性優(yōu)化，實(shí)現(xiàn)NewSQL產(chǎn)品的高可用、高擴(kuò)展、高彈性，但是保留對(duì)開源生態(tài)SQL的完整支持，這是我們開源路線圖一個(gè)支撐的因素。

（四）業(yè)務(wù)痛點(diǎn)分析

下面我們來分析一下當(dāng)前看到的傳統(tǒng)數(shù)據(jù)庫(kù)或者集中數(shù)據(jù)庫(kù)的業(yè)務(wù)痛點(diǎn)。

雖然有這些痛點(diǎn)，這些數(shù)據(jù)庫(kù)仍然能夠服務(wù)用戶的很多需求。但是隨著互聯(lián)網(wǎng)移動(dòng)IoT還有人機(jī)交互方式的不斷演進(jìn)，數(shù)據(jù)量和并發(fā)量不斷地增加，逐漸超過了單機(jī)數(shù)據(jù)庫(kù)或集中式數(shù)據(jù)庫(kù)的吞吐，比如超高并發(fā)，每秒上千上萬的病房，對(duì)于大部分單機(jī)數(shù)據(jù)庫(kù)來說是很難處理的，要么就犧牲性能，延時(shí)極大，并且伴隨著大量的超時(shí)查詢，要么系統(tǒng)可能就會(huì)被擊垮。

集中式通過讀寫分離和存儲(chǔ)計(jì)算分布式，有限地提升了應(yīng)對(duì)這種并發(fā)的能力，但是仍然存在單點(diǎn)處理能力不足的瓶頸。同樣的，業(yè)務(wù)通過ETL產(chǎn)生的數(shù)據(jù)，對(duì)存儲(chǔ)容量的需求逐漸超越單機(jī)或集中式能夠提供的限制，這些其實(shí)都可以通過分布式化的Shared Nothing的產(chǎn)品架構(gòu)來應(yīng)對(duì)。比如將查詢事務(wù)分?jǐn)偟蕉鄠€(gè)計(jì)算節(jié)點(diǎn)，來成倍地提升吞吐，加入更多節(jié)點(diǎn)來實(shí)現(xiàn)存儲(chǔ)容量的水平擴(kuò)展等。

不僅如此，通過復(fù)雜大數(shù)據(jù)查詢的分布化，在各個(gè)計(jì)算節(jié)點(diǎn)上并行運(yùn)行，可以大大提升單機(jī)或集中式對(duì)這些查詢的處理效率。另外一方面，對(duì)于MySQL這樣的IoT表來說，單表太大，也將影響查詢性能。水平分區(qū)有效減少單個(gè)數(shù)據(jù)庫(kù)內(nèi)的表的大小，避免查詢性能受到比如說像緩存命中下降，Scan效率降低的影響。

這些業(yè)務(wù)痛點(diǎn)其實(shí)都是提出了對(duì)分布式和水平擴(kuò)展的需求，也是考慮我們技術(shù)路線圖的一個(gè)因素。

（五）技術(shù)趨勢(shì)：云化，分布式，資源共享

背景方面，我們最后主要討論一下數(shù)據(jù)庫(kù)的技術(shù)趨勢(shì)背景，但數(shù)據(jù)庫(kù)技術(shù)很多，我們不可能每一個(gè)點(diǎn)都覆蓋，因此主要從云化的角度去理解，因?yàn)楫吘箶?shù)據(jù)庫(kù)產(chǎn)品現(xiàn)在的主要方向是云化。

從云化角度來看，首先數(shù)據(jù)庫(kù)需要云化的技術(shù)是什么呢？

我們得看云化的核心是什么，云化的核心就是要極大地減少用戶使用數(shù)據(jù)庫(kù)的代價(jià)，或者叫TCO（Total Cost of Ownership）。這個(gè)代價(jià)主要包括管理、運(yùn)維、軟件、硬件代價(jià)。基于這個(gè)核心，目前公有云數(shù)據(jù)庫(kù)服務(wù)首要提供的就是管控功能，幫助用戶減少和避免管理和運(yùn)維的投入。同時(shí)，云化服務(wù)支持按需的軟硬件配置，發(fā)揮軟硬件的最大效率，并保留實(shí)時(shí)的彈性，保證用戶能夠最有效的支持負(fù)載水平所需的資源。云化技術(shù)目標(biāo)可以總結(jié)為簡(jiǎn)單易用，性價(jià)比最高。

其次數(shù)據(jù)庫(kù)還需要分布式技術(shù)，不管是存儲(chǔ)的分布式還是計(jì)算層，還是事務(wù)一致性層，甚至是故障恢復(fù)和數(shù)據(jù)冗余方面，都需要分布式的技術(shù)。

業(yè)務(wù)層面上，現(xiàn)在的數(shù)據(jù)庫(kù)系統(tǒng)需要支撐海量的數(shù)據(jù)業(yè)務(wù)所帶來的高并發(fā)負(fù)載和混合負(fù)載。從云化角度，分布式能力是實(shí)時(shí)彈性所需要的核心能力，所以也是云化的必要條件。

最后的技術(shù)趨勢(shì)是資源要共享，資源要隔離，實(shí)現(xiàn)按資源或按系統(tǒng)分層的獨(dú)立擴(kuò)展。比如計(jì)算和存儲(chǔ)的分離，就可以實(shí)現(xiàn)數(shù)據(jù)庫(kù)計(jì)算按需擴(kuò)展，相應(yīng)的如果存儲(chǔ)容量需要增加，則只需要增加存儲(chǔ)層的資源和節(jié)點(diǎn)、這種隔離和獨(dú)立擴(kuò)展能力可以擴(kuò)展到內(nèi)存，擴(kuò)展到計(jì)算、存儲(chǔ)網(wǎng)絡(luò)，甚至數(shù)據(jù)數(shù)據(jù)庫(kù)的一些核心處理能力，比如事務(wù)處理和復(fù)雜查詢處理等等。

在上述的趨勢(shì)下，我們來看云化數(shù)據(jù)庫(kù)需要發(fā)展的一些核心技術(shù)和特性。

首先數(shù)據(jù)庫(kù)的高可用將成為重點(diǎn)發(fā)力的地方，因?yàn)檫@關(guān)系到云數(shù)據(jù)庫(kù)的核心能力，即簡(jiǎn)化用戶運(yùn)維和管理的代價(jià)。如果一款數(shù)據(jù)庫(kù)產(chǎn)品在任何故障下，用戶都不掉線，查詢都不受影響，那將極大提升用戶對(duì)產(chǎn)品的信心，簡(jiǎn)化背后管理的復(fù)雜度。同時(shí)如果數(shù)據(jù)庫(kù)任何運(yùn)維操作，比如備份恢復(fù)、增刪節(jié)點(diǎn)、Scale up節(jié)點(diǎn)等等都不會(huì)中斷負(fù)載，不僅用戶在使用體驗(yàn)上更上一層樓，也為數(shù)據(jù)庫(kù)調(diào)優(yōu)、提供更加自由和更多維度的方便。比如Scale up操作，就可以更加動(dòng)態(tài)地進(jìn)行，使得硬件能力更加貼近負(fù)載。

其次另外一個(gè)技術(shù)趨勢(shì)就是擴(kuò)展性，包含各種能力的擴(kuò)展，存儲(chǔ)/計(jì)算事務(wù)和復(fù)雜查詢。比如事務(wù)存儲(chǔ)是否可以按需擴(kuò)展，比如并發(fā)數(shù)是否可以擴(kuò)展，比如復(fù)雜查詢能否根據(jù)數(shù)據(jù)量擴(kuò)展分布式計(jì)算能力，從而減少查詢延時(shí)。

另外一方面，這種擴(kuò)展是否有瓶頸？比如為提升事務(wù)吞吐，我們一般會(huì)采用MVCC機(jī)制，也就是所謂的多版本并發(fā)控制。在分布式下，MVCC需要全局時(shí)鐘或者全局排序的數(shù)列，產(chǎn)生全局?jǐn)?shù)列將對(duì)擴(kuò)展規(guī)模形成約束，因?yàn)楫a(chǎn)生全局序列的服務(wù)可能就成為擴(kuò)展的瓶頸。Google Spanner的Truetime就是為解決這個(gè)瓶頸而設(shè)計(jì)的，我們也設(shè)計(jì)了自己的時(shí)鐘機(jī)制來應(yīng)對(duì)這樣的約束。

在具備了極高的高可用和多層次的擴(kuò)展性以后，彈性地引入將會(huì)為產(chǎn)品帶來云化所必須的按資源使用的特性。以什么樣的彈性顆粒度來進(jìn)行彈性操作，以多快的速度提供資源的擴(kuò)縮，用戶負(fù)載和性能是否受到影響等等，都是彈性技術(shù)所需要面對(duì)的。

另外一個(gè)層面的彈性叫Serverless，大家可能都聽說過，或者看過別的產(chǎn)品在實(shí)現(xiàn)這方面的技術(shù)。所謂的Serverless實(shí)際上就是一個(gè)自動(dòng)化的彈性，按需使用，不用時(shí)自動(dòng)回收，這需要上述這些技術(shù)的綜合，并且能夠提供自動(dòng)化的資源管理能力。

最后回到對(duì)用戶應(yīng)用性上的支持，用戶經(jīng)常已經(jīng)有很多應(yīng)用跑在傳統(tǒng)數(shù)據(jù)庫(kù)或者跑在開源數(shù)據(jù)庫(kù)產(chǎn)品上，但是它沒有云化的基礎(chǔ)，沒有云化的這些技術(shù)的支持，比如應(yīng)用和高效的管控，極致的高可用，分布式擴(kuò)展以及Serverless彈性等。如何讓用戶的這些應(yīng)用可以順利簡(jiǎn)單地以較低的代價(jià)遷移到云化產(chǎn)品上，將是產(chǎn)品應(yīng)用性的首要考慮。這其中維持SQL和生態(tài)的兼容性至關(guān)重要，比如用戶應(yīng)用的SQL程序都不需要改動(dòng)，可以直接切換到云化的數(shù)據(jù)庫(kù)，是否可以減少大量的用戶投入，來改造應(yīng)用。比如用戶的應(yīng)用仍然可以使用相同生態(tài)類的工具，那么用戶就不需要購(gòu)買新的工具，省去為適配這些工具而需要的開發(fā)工作。

往往這些方面的一些應(yīng)用性的缺失，是造成用戶遷移的主要阻力。那么兼容性和易遷移性也將是我們考慮的重點(diǎn)。

所以概括起來，我們對(duì)云化數(shù)據(jù)庫(kù)技術(shù)趨勢(shì)就是4個(gè)方面，高可用、擴(kuò)展性、彈性和兼容性。

（六）背景小結(jié)

基于以上背景，最后我們總結(jié)出開源Polar DB應(yīng)該走哪些路線，然后實(shí)現(xiàn)哪些目標(biāo)，如上圖所示。

在架構(gòu)上我們要支持分布式，技術(shù)上我們要云化，同時(shí)解決客戶的業(yè)務(wù)痛點(diǎn)，在生態(tài)上擁抱開源。

二、 ?開源路線圖

（一）開源路線圖

基于背景、技術(shù)架構(gòu)等方面的考量，我們最終提出了開源產(chǎn)品的路線圖。

首先開源的版本是基于 X-Consensus共識(shí)協(xié)議的高可用集群版本，該版本主打的是高可用特性，讓用戶可以快速自建一個(gè)和阿里集團(tuán)內(nèi)能力一樣的數(shù)據(jù)庫(kù)集群底座。

在實(shí)現(xiàn)極高吞吐的情況下，支持Leader跟Follow間的全局一致性，故障時(shí)保證數(shù)據(jù)不丟失，并且Follow能夠快速地升為L(zhǎng)eader，對(duì)外進(jìn)行服務(wù)，該版本解決用戶對(duì)高可用的一些最根本、最初步的需求。

在第二階段我們將推出基于混合邏輯時(shí)鐘HLC的高擴(kuò)展分布式版，這個(gè)版本將實(shí)現(xiàn)Shared Nothing架構(gòu)，支持?jǐn)?shù)據(jù)庫(kù)集群的水平擴(kuò)展，解決單機(jī)存儲(chǔ)容量受限問題，并支持高并發(fā)和高吞吐的事務(wù)處理。

通過分布式事務(wù)和分布式時(shí)鐘HLC做到分布式全局一致，也就是說整個(gè)分布式數(shù)據(jù)庫(kù)集群對(duì)外呈現(xiàn)單機(jī)數(shù)據(jù)庫(kù)的特性，用戶應(yīng)用像使用單機(jī)數(shù)據(jù)庫(kù)那樣獲得ACID的支持。

在第三階段，我們把前兩個(gè)階段積累的大部分能力以插件化的形式改寫，包括分布式事務(wù)，分布式SQL計(jì)算，Sharding和彈性，從而使得我們的工作對(duì)社區(qū)內(nèi)核的開發(fā)是垂直的，可以互補(bǔ)，這樣我們用戶就可以快速地升級(jí)數(shù)據(jù)庫(kù)內(nèi)核版本，同時(shí)保留我們提供的分布式彈性和高可用的特性。

路線圖簡(jiǎn)潔地體現(xiàn)了我們對(duì)云化數(shù)據(jù)庫(kù)的需求的理解，通過開發(fā)和社區(qū)互補(bǔ)的工作，實(shí)現(xiàn)對(duì)社區(qū)的增強(qiáng)，同時(shí)保持社區(qū)的兼容，實(shí)現(xiàn)生態(tài)統(tǒng)一，最小化用戶的使用和升級(jí)代價(jià)。

（二）X-Consensus 高可用集群版

下面介紹每一個(gè)階段的主要特點(diǎn)。

我們第一期開源出來的項(xiàng)目稱為高可用集群版，顧名思義就是圍繞高可用打造產(chǎn)品特性。

上圖左邊顯示的是版本架構(gòu)圖，這個(gè)架構(gòu)中包括多個(gè)組件，比如Leader、 Follower、Logger數(shù)據(jù)庫(kù)節(jié)點(diǎn)，其內(nèi)核都是PG。CM集群管理組件，負(fù)責(zé)系統(tǒng)和節(jié)點(diǎn)的啟動(dòng)、停止、集群操作等。

唯一核心的是稱為X -Consensus的阿里自研的共識(shí)協(xié)議。在X-Consensus的支持下，PolarDB實(shí)現(xiàn)了節(jié)點(diǎn)故障不能恢復(fù)的時(shí)候，已提交數(shù)據(jù)不丟失，并且保證對(duì)外一致性。

在實(shí)踐層面上，PolarDB仍然使用PG自帶的Streaming Repliation，而是通過X -Consensus共識(shí)協(xié)議，保證節(jié)點(diǎn)間日志同步的位點(diǎn)的同步。這樣做的好處是不改變內(nèi)核的數(shù)據(jù)復(fù)制協(xié)議，減少對(duì)內(nèi)核的侵入性修改，同時(shí)維護(hù)對(duì)工具生態(tài)的兼容。

這個(gè)選擇反映了我們?cè)陂_源項(xiàng)目中堅(jiān)持的原則，就是做社區(qū)的補(bǔ)充，做的功能最好是垂直于社區(qū)的功能和發(fā)展，共識(shí)協(xié)議的穩(wěn)定性和正確性是其核心能力。我們使用的協(xié)議已經(jīng)被使用在阿里集團(tuán)內(nèi)部業(yè)務(wù)成千上萬的后臺(tái)數(shù)據(jù)庫(kù)，經(jīng)過多年的高壓測(cè)試和實(shí)際負(fù)載的打磨，相信其作為一個(gè)開源數(shù)據(jù)庫(kù)協(xié)議被大家接受，肯定也會(huì)成為這個(gè)方向的一個(gè)標(biāo)桿產(chǎn)品，后續(xù)這個(gè)協(xié)議將會(huì)作為獨(dú)立開源產(chǎn)品被推出。

除了穩(wěn)定性和正確性的保證，本次開源項(xiàng)目還使用了該協(xié)議的多角色能力，支持Leader、Follower和Logger。其中Logger沒有數(shù)據(jù)庫(kù)，數(shù)據(jù)只保留一份日志參與選舉，但是不能被選舉。Logger角色的引入將減少1/3的數(shù)據(jù)存儲(chǔ)，同時(shí)保留共識(shí)協(xié)議在下面一些的能力，比如自動(dòng)選主，比如網(wǎng)絡(luò)性能抖動(dòng)時(shí)候?qū)κ聞?wù)提交的影響。Logger可以參與選舉，就可以在自動(dòng)選主時(shí)快速找出多數(shù)派，當(dāng)網(wǎng)絡(luò)性能抖動(dòng)時(shí)，事務(wù)提交需要的日志同步，可以在Logger節(jié)點(diǎn)和Follower節(jié)點(diǎn)間進(jìn)行選擇，避免一些網(wǎng)絡(luò)抖動(dòng)的影響。

共識(shí)協(xié)議保證了快速和正確的選舉，數(shù)據(jù)庫(kù)高可用的一個(gè)主要指標(biāo)RTO（Recovery Time Objective），反映的是從故障發(fā)生、用戶服務(wù)中斷到服務(wù)恢復(fù)的時(shí)間長(zhǎng)度，所以除了故障檢測(cè)時(shí)間和選主時(shí)間外，還包括升主時(shí)間和服務(wù)恢復(fù)時(shí)間，二者和數(shù)據(jù)庫(kù)的日志回放速度有關(guān)。

我們的測(cè)試發(fā)現(xiàn)，當(dāng)Leader經(jīng)受非常大并發(fā)的時(shí)候，Follower雖然實(shí)時(shí)地接收到了日志，但是其日志回放是串行的，所以Follower的同步狀態(tài)經(jīng)常落后Leader很長(zhǎng)時(shí)間，當(dāng)這種壓力持續(xù)的時(shí)候，這個(gè)落后時(shí)間將持續(xù)增加，甚至超過一個(gè)小時(shí)。可以想象如果Leader這個(gè)時(shí)候故障不能恢復(fù)，那么Follower需要恢復(fù)一個(gè)小時(shí)時(shí)間，才能完成升主并對(duì)外服務(wù)，也就是說RTO可能會(huì)達(dá)到一個(gè)多小時(shí)以上，這個(gè)是大部分在線數(shù)據(jù)庫(kù)應(yīng)用難以接受的。

所以根據(jù)這個(gè)需求，我們的項(xiàng)目中實(shí)現(xiàn)了Follower的并行日志回放，在保證回放結(jié)果正確一致外，實(shí)現(xiàn)了Leader即使有很大的并發(fā)壓力，比如幾十萬TPMC的 TPCC負(fù)載，Follower上的回放落后時(shí)間仍然維持在幾秒甚至更小的時(shí)間范圍之內(nèi)。

所以這個(gè)版本我們的主要特性就是打造高可用的數(shù)據(jù)庫(kù)服務(wù)，包括共識(shí)協(xié)議的使用，多復(fù)制角色的支持，以及快速和并行的日志回放。

（三）HLC高擴(kuò)展分布式版

下一個(gè)階段，我們開源的項(xiàng)目將會(huì)是一個(gè)Shared Nothing的分布式產(chǎn)品，但仍然是基于第一期的高可用能力。這一期的核心是對(duì)PG內(nèi)核的分布式擴(kuò)展，使得擴(kuò)展后的系統(tǒng)能夠最大限度地兼容單機(jī)SQL的能力，包括DML、DDL等，同時(shí)保持對(duì)外呈現(xiàn)單個(gè)數(shù)據(jù)庫(kù)的ACID和MVCC的能力。

二者的目的就是保證分布式擴(kuò)展后的這個(gè)系統(tǒng)，對(duì)用戶大部分應(yīng)用仍然像單機(jī)PG那樣兼容，減少用戶遷移和開發(fā)的工作量。

上圖所示的架構(gòu)中可以看到，分布式Shared Nothing系統(tǒng)中出現(xiàn)更多的組件，其中data node部分就是一期的高可用集群，只是有多個(gè)這樣的集群，或稱為基于X -Consensus復(fù)制組，每個(gè)data node復(fù)制組中有Leader、Follower和Logger。通過X -Consensus共識(shí)協(xié)議保持?jǐn)?shù)據(jù)一致性，每一個(gè)復(fù)制組負(fù)責(zé)整個(gè)數(shù)據(jù)庫(kù)的部分?jǐn)?shù)據(jù)，稱為數(shù)據(jù)庫(kù)分片。因?yàn)閐ata node上實(shí)際上運(yùn)行的獨(dú)立的PG內(nèi)核又稱為數(shù)據(jù)庫(kù)分片，這些數(shù)據(jù)庫(kù)分片其實(shí)就是多個(gè)數(shù)據(jù)庫(kù)實(shí)例，通過一個(gè)新的引入組件叫協(xié)調(diào)節(jié)點(diǎn)（Coordinator nodes），實(shí)現(xiàn)對(duì)外呈現(xiàn)單個(gè)數(shù)據(jù)庫(kù)的能力。

也就是對(duì)用戶來說，看到的是一個(gè)數(shù)據(jù)庫(kù)，一個(gè)字典表和一套用戶表，但是在物理上每個(gè)數(shù)據(jù)庫(kù)分片都存了用戶表，只是一部分?jǐn)?shù)據(jù)。用戶查詢先路由到協(xié)調(diào)節(jié)點(diǎn)，協(xié)調(diào)節(jié)點(diǎn)通過字典表和集群拓?fù)湫畔?#xff0c;判斷查詢需要涉及的數(shù)據(jù)庫(kù)分片，并發(fā)送查詢到相應(yīng)節(jié)點(diǎn)，獲得各個(gè)節(jié)點(diǎn)的返回結(jié)果后，協(xié)調(diào)節(jié)點(diǎn)還將負(fù)責(zé)將結(jié)果組合返回給用戶。

除了查詢和表邏輯對(duì)外呈現(xiàn)單個(gè)數(shù)據(jù)庫(kù)特性外，分布數(shù)據(jù)庫(kù)的ACID和數(shù)據(jù)一致性也需要維護(hù)。為此我們引入另外兩個(gè)組件，一個(gè)是分布式事務(wù)管理TX Manager，保證一個(gè)事務(wù)在多個(gè)數(shù)據(jù)庫(kù)實(shí)例上執(zhí)行的時(shí)候滿足ACID。另外一個(gè)是混合邏輯時(shí)鐘，叫HOC，其目的是保證所有事務(wù)有一個(gè)全局的排序，從而實(shí)現(xiàn)分布式Shard的MVCC，也就是實(shí)現(xiàn)分布式Shard的SnapShot。

相對(duì)于中心使用來說，采用混合邏輯時(shí)鐘的好處是混合時(shí)鐘是分布式的，沒有中心，在大規(guī)模集群情況下不會(huì)引入熱點(diǎn)和瓶頸，同時(shí)可以避免新的組件，增加管理或者高可用的代價(jià)。

通過HLC對(duì)事務(wù)和操作進(jìn)行時(shí)間意義上的全局排序，不僅僅需要實(shí)現(xiàn)HLC的協(xié)議，同時(shí)需要數(shù)據(jù)庫(kù)內(nèi)核的支持。這個(gè)支持我們?cè)谝黄谝呀?jīng)完成了，是對(duì)PG SnapShot管理的增強(qiáng)，作為替換原來的活躍事務(wù)列表，為提交序列數(shù)或者叫CSN，作為SnapShot，這樣分布式的HOC和單機(jī)PG的CSN機(jī)制整合，實(shí)現(xiàn)了事務(wù)的全局排序，從而為實(shí)現(xiàn)分布式MVCC提供這個(gè)基礎(chǔ)。當(dāng)所有的事務(wù)都按照時(shí)間排序時(shí)，那原有的MVCC機(jī)制就可以正常地運(yùn)行，保證數(shù)據(jù)多版本支持，讀寫操作的并行執(zhí)行。

在分布式Shared Nothing下，除了事務(wù)一致性外，如何分布式地處理SQL計(jì)算也是一個(gè)非常重要的特性。就像剛才提到的，我們首要的目標(biāo)是最大限度地兼容單機(jī)的SQL能力，和事務(wù)一致性一起保證用戶應(yīng)用可以快速在功能上適配分布式數(shù)據(jù)庫(kù)系統(tǒng)，比如對(duì)DDL的支持，對(duì)簡(jiǎn)單DML的支持，對(duì)帶子查詢的復(fù)雜DML的支持等等。

其次，需要在查詢性能上進(jìn)行優(yōu)化，這中間的工作將非常地豐富，比如發(fā)送查詢到數(shù)據(jù)庫(kù)分片節(jié)點(diǎn)的操作，需要考慮是否整個(gè)或部分查詢可以直接下推給某個(gè)或某些節(jié)點(diǎn)。查詢計(jì)劃在分布式下如何優(yōu)化，如何結(jié)合分布式和單機(jī)的優(yōu)化器的能力，如何在data node間交互，如何結(jié)合MPP和SMP等，都是我們將來所需要考慮的一些方向跟技術(shù)特性。

根據(jù)項(xiàng)目一期的基礎(chǔ)，data node已經(jīng)具備高可用，但是集群管理和分布式數(shù)據(jù)庫(kù)的MetaData的管理都需要類似的高可用能力。我們需要一個(gè)基于X- Consensus的共識(shí)協(xié)議的分布式方案，解決用戶數(shù)據(jù)庫(kù)協(xié)調(diào)邏輯，集群管理和Meta管理的統(tǒng)一的高可用問題，所以我們將會(huì)在這個(gè)版本里實(shí)現(xiàn)分布式的高可用。

總體上，二期將推出一個(gè)具備完整SQL和數(shù)據(jù)一致能力的分布式Shared Nohting數(shù)據(jù)庫(kù)，其主要特性都是對(duì)現(xiàn)有單機(jī)PG的補(bǔ)充、增強(qiáng)和擴(kuò)展，這些能力的大部分將在第三期成為插件，滿足用戶快速升級(jí)的需求。

? （四） Sharding 和 插件化版

第三期我們將在前面兩期基礎(chǔ)上持續(xù)地增強(qiáng)分布式能力、云化能力以及PG社區(qū)兼容能力，上方的架構(gòu)圖反映了我們?cè)诘谌诘闹饕悸贰?/p>

首先DB Node作為核心組件，提供單機(jī)數(shù)據(jù)庫(kù)內(nèi)核能力和分布式計(jì)算能力，同時(shí)管理每個(gè)Shard和跨Shard的事務(wù)，保持?jǐn)?shù)據(jù)一致性，DB Node自己通過X- Consensus共識(shí)協(xié)議復(fù)制數(shù)據(jù)到Follower，維護(hù)節(jié)點(diǎn)級(jí)別的數(shù)據(jù)和邏輯冗余，有助于故障Shard快速恢復(fù)。每個(gè)DB Node的功能將通過對(duì)PG社區(qū)內(nèi)核支持，加上分布式和高可用的插件的Patch實(shí)現(xiàn)這些功能。

在DB node上，我們維護(hù)一個(gè)PolarDB服務(wù)層，提供像集群管理，各種運(yùn)維操作，負(fù)載路由以及中心時(shí)鐘，是一個(gè)Option的需求。相對(duì)獨(dú)立的服務(wù)層將有助于用戶應(yīng)用的對(duì)接，不受內(nèi)核升級(jí)變化的影響，服務(wù)層可以隨環(huán)境變化，針對(duì)不同云提供商和專有云來進(jìn)行提供支持。

第三期主要的增強(qiáng)體現(xiàn)在以下幾個(gè)方面。首先我們加強(qiáng)了Sharding，提供了細(xì)粒度的Sharding能力，細(xì)粒度Sharding主要加強(qiáng)了PG原生內(nèi)核相對(duì)單機(jī)化的架構(gòu)，計(jì)算存儲(chǔ)相對(duì)耦合，不利于云化和分布式下彈性和擴(kuò)展管理。通過細(xì)粒度Sharding，使得用戶表在存儲(chǔ)層實(shí)現(xiàn)一定程度上的隔離，支持在線的Shard遷移，進(jìn)一步提升分布式的能力和云化彈性能力。

同時(shí)，通過統(tǒng)一化組件，將協(xié)調(diào)節(jié)點(diǎn)和data node合二為一，成為統(tǒng)一的DB Node，和數(shù)據(jù)庫(kù)相關(guān)的功能在一個(gè)組件里面提供，使得云化部署和管理更加的簡(jiǎn)潔。最后通過分布式和Sharding能力的插件化，保持對(duì)社區(qū)版本的兼容，保證用戶可以快速地升級(jí)。

至此，Polar DB開源項(xiàng)目通過三步演進(jìn)，實(shí)現(xiàn)了對(duì)PG內(nèi)核的分布式擴(kuò)展，保證分布式一致性，同時(shí)兼容PG SQL能力和內(nèi)核版本的升級(jí)，具備云化的彈性和管理的簡(jiǎn)潔性。當(dāng)然，后續(xù)仍然有很大的優(yōu)化空間和很多特性會(huì)持續(xù)推出，比如分布式計(jì)算的持續(xù)優(yōu)化、混合負(fù)載、HTTP等。

（五）路線圖小結(jié)

最后，用下圖來小結(jié)我們路線圖的目標(biāo)和希望達(dá)成的方向。

我們期望開源PolarDB是一個(gè)高擴(kuò)展分布式、細(xì)粒度、彈性、基于共享協(xié)議的高可用，以及易于兼容社區(qū)的插件化，每一個(gè)目標(biāo)都反映了我們對(duì)云化數(shù)據(jù)庫(kù)基礎(chǔ)需求的理解。

三、開放問題

最后有三個(gè)相對(duì)開放的問題。

第一個(gè)問題是關(guān)于分布式和集中式數(shù)據(jù)庫(kù)的市場(chǎng)的考慮，從個(gè)人角度來看，傳統(tǒng)數(shù)據(jù)庫(kù)以集中式為主，市場(chǎng)也是如此，將來在很長(zhǎng)時(shí)間內(nèi)集中式仍然會(huì)是主體。分布式在完善功能、構(gòu)建生態(tài)上會(huì)不斷地進(jìn)步，可以占據(jù)一定的市場(chǎng)份額。如果分布式能夠兼容集中式的模式，那么分布式產(chǎn)品既可以當(dāng)做集中式來使用，還可以按需擴(kuò)展成分布式，那么更多市場(chǎng)份額就可以期待，這也是我們?yōu)槭裁催x擇把開源產(chǎn)品做成分布式主要的原因。

第二個(gè)問題是關(guān)于分布式和計(jì)算存儲(chǔ)分離的關(guān)系，個(gè)人理解二者是不沖突的，是垂直的關(guān)系。分布系統(tǒng)是可以使用集中式的存儲(chǔ)，甚至更加廣義地講，很多云設(shè)施可以當(dāng)成集中式來使用，比如云的塊存儲(chǔ)，對(duì)象存儲(chǔ)等等。分布式可以通過自身的擴(kuò)展性，更加有效地利用這些云存儲(chǔ)的帶寬和IOPS，所以我們的分布式開源產(chǎn)品將來也會(huì)做針對(duì)存儲(chǔ)計(jì)算分離，或者是利用云存儲(chǔ)這樣的架構(gòu)的優(yōu)化跟提升。

第三個(gè)問題是關(guān)于擴(kuò)展分布式數(shù)據(jù)庫(kù)生態(tài)，我們既然已經(jīng)有了分布式數(shù)據(jù)庫(kù)，它天然就具備一致性，擴(kuò)展性和分布式計(jì)算等能力。那么我們是否可以通過新的數(shù)據(jù)訪問接口和引入新的用戶定義計(jì)算功能，來擴(kuò)展它所能支持的服務(wù)能力，比如將它擴(kuò)展成其他服務(wù)的存儲(chǔ)系統(tǒng)，擴(kuò)展成其他服務(wù)的計(jì)算執(zhí)行系統(tǒng)，這些都是非常值得我們?nèi)ニ伎嫉?#xff0c;但是前提條件是我們先打造出一個(gè)完整、功能完善、穩(wěn)定的開源分布式數(shù)據(jù)庫(kù)，這樣在此基礎(chǔ)上，我們就可以做更多更加有意思的多生態(tài)的工作。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的PolarDB for PostgreSQL 开源路线图的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。