簡介：作者：蔡樂

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

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

本文將花一些時間闡述對這個背景的理解和分析，并在此基礎上提出產品開源的路線圖及其所要達成的目標和需要解決的問題。

一、 背景

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

首先介紹的背景是關于開源，講講現在數據庫上云是如何利用開源的，然后如何回饋了到開源產品，并且最終成就開源。

過去數據庫作為傳統的IT基礎設施，基本上壟斷在幾大主力的廠商手里。雖然開源數據庫產品很多也很流行，比如MySQL等，都是叫好不叫座，掙錢能力不足，商業能力可能不是很好，這其實由下面的一些因素來決定。因為數據庫作為核心的IT基礎設施，因此對其可靠性、穩定性、功能全面性和性能要求很高，每個企業在選型數據庫時非常謹慎，開源數據庫在10年前也沒有拿出足夠的能力來撼動這些商業數據庫的地位。

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

隨著IT的云化，公有云市場的發展，比如AWS，阿里云等，這些后期的IT提供商從計算，存儲，資源優化開始，為用戶提供按需的資源，進而自然進入基礎軟件的供應。

顯然，使用來自壟斷廠商生產的商用數據庫為云用戶提供服務，將導致云的利潤都被商用數據庫廠商拿走，將開源數據庫，特別是像MySQL、PostgreSQL推上前線，和商用數據庫一爭高低，是其背后的商業背景和目的決定的，其中的路徑基本上有下面幾步。

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

因此，第一步是開源數據庫上云，用云化管理來替代DBA，實現對商用數據庫的商業模式的超越。當然，云化的數據庫資源的隨用隨取也是一個非常重要的點。完成這一步還不夠，畢竟開源數據庫在本身能力上和商業數據庫是有一定差別的。

要想取得商用數據庫開辟的大市場，開源數據庫的云化增強就開始了，因為補上差距是不夠的，不能夠吸引客戶轉投開源數據庫，必須有超越商用數據庫技術的的技術和競爭力。

比如阿里云開發了PolarDB，首先對數據庫依賴的存儲系統進行云化改造，提供云延伸的擴展性和資源彈性，同時對外維持開源數據庫的所有特性，保證開源數據庫的生態可以很好地被繼承。

改造解決了商用數據庫對底層存儲硬件固有的依賴，比如其性能和容量完全受限于存儲硬件，不容易擴容，也不能實時在線地提供按需吞吐，后續引入的一寫多讀分布式以及Global DataBase的技術，使得云原生基于開源數據庫的產品，完成了對傳統商業數據庫的技術超越，為用戶提供了它們不能提供的價值和競爭力。

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

我們無法往社區推很多東西，因為PG社區非常謹慎的，對每一個特性的需求和設計都有非常嚴格的要求，需要經過多位重量級的Commit的同意和競爭開發者的同意。很多特性在社區歷史上都被其他開發者開發過，只是設計角度和覆蓋方面沒有滿足社區的需求而被擱置。任何一個Patch，都是需要超越以前的版本，最終才能被PG社區接收。

我們經過半年多的時間，最終實現了被社區所接受的特性。考慮到社區版本演進的謹慎性，我們有許多技術可以回饋開源社區，但是因為社區的相對謹慎，我們很難做到這個事情，其中的周期非常長，這就成為我們開源PalarDB的一個重要原因。我們希望開源的技術是對社區內核能力的輔助增強，所以最好都是垂直于社區能力，用戶拿我們的開源軟件加上社區的內核版本，就可以同時享用兩邊的貢獻，就是我們目前選擇開源高可用能力、分布式擴展能力、后續云化運維能力等功能的主要考慮因素。

通過這些技術的開源，我們就可以和社區共同成長，我們的技術就是社區的一份子，同時社區的發展也能夠幫助我們更好地服務客戶，最終收益的是開源社區和我們的用戶，社區和開源數據庫的用戶們獲得了共同成長的利益和價值，而阿里數據庫團隊將成為其中的一個助力，這是我們對開源產品的理解。

（二）數據庫架構

接下來介紹的是關于數據庫的架構，它是如何演進，現在有哪些數據庫的架構。

上圖列了三種架構，最左邊的是單機數據庫，一臺服務器在運行一個數據庫，存儲就是本地磁盤系統，用戶通過網絡連接數據庫進行SQL查詢和計算。

很明顯，這種架構的問題是當數據庫故障的時候，用戶服務將會被中斷，同時本地盤系統的容量和吞吐有限，當用戶負載增加的時候，單機數據庫會出現服務響應時間過長等性能問題。但有些商用數據庫、開源數據庫、MySQL、PostgreSQL，它在一臺服務器上部署的時候就是這種類型。

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

另外一個特點是當有實例故障的時候，可以快速恢復，快速地切換負載到其他實例上去執行，中斷時間非常短。但用戶負載和要求吞吐增加的時候，這個架構需要提升硬件的規格來實現能力的提升，比如增加數據庫節點的CPU核數，增加共享存儲的能力等，所以這種擴展能力我們稱之為垂直擴展或叫做Scale up。

最右邊這個架構稱為Shared Nothing架構，或者叫分布式架構，每個數據庫實例和單機數據庫類似，有自己的存儲和計算資源，每個數據庫實例都是一個獨立的數據庫。但是，這些數據庫通過一定的MetaData和字典表的管理，實現對用戶來看就是一個數據庫。每一個數據庫實例其實管理一個分片數據庫，存儲一部分數據庫的數據，相互之間是邏輯和物理的隔離，所以稱之為是Shared Nothing架構。其主要特點是當涉及多個分片數據庫時，需要執行分布式的SQL計算，需要通過分布式事務保持事務一致性，這種架構的優點是系統可以水平擴展。

當用戶需要更大的存儲容量，更高的計算吞吐時，就可以通過增加數據庫分片，也就是數據庫節點的方式來提升系統容量性能，這種擴展方式稱為水平擴展或叫Scale out。

開源的Polar DB將是后面兩種架構的融合。

（三）數據庫系統的演進

接下來介紹一下數據庫系統的演進，以及演進對我們開源數據庫產品的路線的影響。

無論是傳統的商業數據庫，還是我們開源數據庫MySQL或PG，它處理的都是關系型的數據，也就是結構化的數據。其中又分為兩種,RDBMS也就是關系型數據庫管理系統，主要處理在線的交易型負載，比如ATM，商家的在線交易等等。

另外一個稱為Data Warehouse，也就是數據倉庫。和RDBMS一樣，都使用標準的SQL來處理數據，但是其負載涉及大量數據，很多表計算非常復雜，典型的應用為ETL和在線分析計算。

隨著大數據的興起，Hadoop平臺的普及，用戶希望處理的數據類型逐漸多樣化，比如時間序列、地理數據、圖、向量、文本等等。相應的數據處理產品涌現，它們區別于關系型數據庫的最大差別是處理的數據類型和使用的處理語言是不一樣的，以及它們和Hadoop等大數據平臺的融合，帶來了極高的可用性和擴展性，能夠水平擴展到幾十臺甚至幾百臺、上千臺服務器上。

受這些產品的啟發，許多新型數據庫系統開始轉向分布式的高可用、高擴展，引入了共識協議，實現高可用，同時維持對數據庫處理語言SQL的支持，典型例子有Google的Spanner，雖然這些NewSQL實現了上述目標，但是其對SQL支持的完整度上和開源數據庫仍然有一定的差距，可以說只是后者的子集，需要投入很大的資源來完善這部分功能。

我們的想法是能否在開源數據庫的基礎上引入分布式，引入共識協議，以及存儲和計算層的彈性優化，實現NewSQL產品的高可用、高擴展、高彈性，但是保留對開源生態SQL的完整支持，這是我們開源路線圖一個支撐的因素。

（四）業務痛點分析

下面我們來分析一下當前看到的傳統數據庫或者集中數據庫的業務痛點。

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

集中式通過讀寫分離和存儲計算分布式，有限地提升了應對這種并發的能力，但是仍然存在單點處理能力不足的瓶頸。同樣的，業務通過ETL產生的數據，對存儲容量的需求逐漸超越單機或集中式能夠提供的限制，這些其實都可以通過分布式化的Shared Nothing的產品架構來應對。比如將查詢事務分攤到多個計算節點，來成倍地提升吞吐，加入更多節點來實現存儲容量的水平擴展等。

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

這些業務痛點其實都是提出了對分布式和水平擴展的需求，也是考慮我們技術路線圖的一個因素。

（五）技術趨勢：云化，分布式，資源共享

背景方面，我們最后主要討論一下數據庫的技術趨勢背景，但數據庫技術很多，我們不可能每一個點都覆蓋，因此主要從云化的角度去理解，因為畢竟數據庫產品現在的主要方向是云化。

從云化角度來看，首先數據庫需要云化的技術是什么呢？

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

其次數據庫還需要分布式技術，不管是存儲的分布式還是計算層，還是事務一致性層，甚至是故障恢復和數據冗余方面，都需要分布式的技術。

業務層面上，現在的數據庫系統需要支撐海量的數據業務所帶來的高并發負載和混合負載。從云化角度，分布式能力是實時彈性所需要的核心能力，所以也是云化的必要條件。

最后的技術趨勢是資源要共享，資源要隔離，實現按資源或按系統分層的獨立擴展。比如計算和存儲的分離，就可以實現數據庫計算按需擴展，相應的如果存儲容量需要增加，則只需要增加存儲層的資源和節點、這種隔離和獨立擴展能力可以擴展到內存，擴展到計算、存儲網絡，甚至數據數據庫的一些核心處理能力，比如事務處理和復雜查詢處理等等。

在上述的趨勢下，我們來看云化數據庫需要發展的一些核心技術和特性。

首先數據庫的高可用將成為重點發力的地方，因為這關系到云數據庫的核心能力，即簡化用戶運維和管理的代價。如果一款數據庫產品在任何故障下，用戶都不掉線，查詢都不受影響，那將極大提升用戶對產品的信心，簡化背后管理的復雜度。同時如果數據庫任何運維操作，比如備份恢復、增刪節點、Scale up節點等等都不會中斷負載，不僅用戶在使用體驗上更上一層樓，也為數據庫調優、提供更加自由和更多維度的方便。比如Scale up操作，就可以更加動態地進行，使得硬件能力更加貼近負載。

其次另外一個技術趨勢就是擴展性，包含各種能力的擴展，存儲/計算事務和復雜查詢。比如事務存儲是否可以按需擴展，比如并發數是否可以擴展，比如復雜查詢能否根據數據量擴展分布式計算能力，從而減少查詢延時。

另外一方面，這種擴展是否有瓶頸？比如為提升事務吞吐，我們一般會采用MVCC機制，也就是所謂的多版本并發控制。在分布式下，MVCC需要全局時鐘或者全局排序的數列，產生全局數列將對擴展規模形成約束，因為產生全局序列的服務可能就成為擴展的瓶頸。Google Spanner的Truetime就是為解決這個瓶頸而設計的，我們也設計了自己的時鐘機制來應對這樣的約束。

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

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

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

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

所以概括起來，我們對云化數據庫技術趨勢就是4個方面，高可用、擴展性、彈性和兼容性。

（六）背景小結

基于以上背景，最后我們總結出開源Polar DB應該走哪些路線，然后實現哪些目標，如上圖所示。

在架構上我們要支持分布式，技術上我們要云化，同時解決客戶的業務痛點，在生態上擁抱開源。

二、 ?開源路線圖

（一）開源路線圖

基于背景、技術架構等方面的考量，我們最終提出了開源產品的路線圖。

首先開源的版本是基于 X-Consensus共識協議的高可用集群版本，該版本主打的是高可用特性，讓用戶可以快速自建一個和阿里集團內能力一樣的數據庫集群底座。

在實現極高吞吐的情況下，支持Leader跟Follow間的全局一致性，故障時保證數據不丟失，并且Follow能夠快速地升為Leader，對外進行服務，該版本解決用戶對高可用的一些最根本、最初步的需求。

在第二階段我們將推出基于混合邏輯時鐘HLC的高擴展分布式版，這個版本將實現Shared Nothing架構，支持數據庫集群的水平擴展，解決單機存儲容量受限問題，并支持高并發和高吞吐的事務處理。

通過分布式事務和分布式時鐘HLC做到分布式全局一致，也就是說整個分布式數據庫集群對外呈現單機數據庫的特性，用戶應用像使用單機數據庫那樣獲得ACID的支持。

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

路線圖簡潔地體現了我們對云化數據庫的需求的理解，通過開發和社區互補的工作，實現對社區的增強，同時保持社區的兼容，實現生態統一，最小化用戶的使用和升級代價。

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

下面介紹每一個階段的主要特點。

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

上圖左邊顯示的是版本架構圖，這個架構中包括多個組件，比如Leader、 Follower、Logger數據庫節點，其內核都是PG。CM集群管理組件，負責系統和節點的啟動、停止、集群操作等。

唯一核心的是稱為X -Consensus的阿里自研的共識協議。在X-Consensus的支持下，PolarDB實現了節點故障不能恢復的時候，已提交數據不丟失，并且保證對外一致性。

在實踐層面上，PolarDB仍然使用PG自帶的Streaming Repliation，而是通過X -Consensus共識協議，保證節點間日志同步的位點的同步。這樣做的好處是不改變內核的數據復制協議，減少對內核的侵入性修改，同時維護對工具生態的兼容。

這個選擇反映了我們在開源項目中堅持的原則，就是做社區的補充，做的功能最好是垂直于社區的功能和發展，共識協議的穩定性和正確性是其核心能力。我們使用的協議已經被使用在阿里集團內部業務成千上萬的后臺數據庫，經過多年的高壓測試和實際負載的打磨，相信其作為一個開源數據庫協議被大家接受，肯定也會成為這個方向的一個標桿產品，后續這個協議將會作為獨立開源產品被推出。

除了穩定性和正確性的保證，本次開源項目還使用了該協議的多角色能力，支持Leader、Follower和Logger。其中Logger沒有數據庫，數據只保留一份日志參與選舉，但是不能被選舉。Logger角色的引入將減少1/3的數據存儲，同時保留共識協議在下面一些的能力，比如自動選主，比如網絡性能抖動時候對事務提交的影響。Logger可以參與選舉，就可以在自動選主時快速找出多數派，當網絡性能抖動時，事務提交需要的日志同步，可以在Logger節點和Follower節點間進行選擇，避免一些網絡抖動的影響。

共識協議保證了快速和正確的選舉，數據庫高可用的一個主要指標RTO（Recovery Time Objective），反映的是從故障發生、用戶服務中斷到服務恢復的時間長度，所以除了故障檢測時間和選主時間外，還包括升主時間和服務恢復時間，二者和數據庫的日志回放速度有關。

我們的測試發現，當Leader經受非常大并發的時候，Follower雖然實時地接收到了日志，但是其日志回放是串行的，所以Follower的同步狀態經常落后Leader很長時間，當這種壓力持續的時候，這個落后時間將持續增加，甚至超過一個小時。可以想象如果Leader這個時候故障不能恢復，那么Follower需要恢復一個小時時間，才能完成升主并對外服務，也就是說RTO可能會達到一個多小時以上，這個是大部分在線數據庫應用難以接受的。

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

所以這個版本我們的主要特性就是打造高可用的數據庫服務，包括共識協議的使用，多復制角色的支持，以及快速和并行的日志回放。

（三）HLC高擴展分布式版

下一個階段，我們開源的項目將會是一個Shared Nothing的分布式產品，但仍然是基于第一期的高可用能力。這一期的核心是對PG內核的分布式擴展，使得擴展后的系統能夠最大限度地兼容單機SQL的能力，包括DML、DDL等，同時保持對外呈現單個數據庫的ACID和MVCC的能力。

二者的目的就是保證分布式擴展后的這個系統，對用戶大部分應用仍然像單機PG那樣兼容，減少用戶遷移和開發的工作量。

上圖所示的架構中可以看到，分布式Shared Nothing系統中出現更多的組件，其中data node部分就是一期的高可用集群，只是有多個這樣的集群，或稱為基于X -Consensus復制組，每個data node復制組中有Leader、Follower和Logger。通過X -Consensus共識協議保持數據一致性，每一個復制組負責整個數據庫的部分數據，稱為數據庫分片。因為data node上實際上運行的獨立的PG內核又稱為數據庫分片，這些數據庫分片其實就是多個數據庫實例，通過一個新的引入組件叫協調節點（Coordinator nodes），實現對外呈現單個數據庫的能力。

也就是對用戶來說，看到的是一個數據庫，一個字典表和一套用戶表，但是在物理上每個數據庫分片都存了用戶表，只是一部分數據。用戶查詢先路由到協調節點，協調節點通過字典表和集群拓撲信息，判斷查詢需要涉及的數據庫分片，并發送查詢到相應節點，獲得各個節點的返回結果后，協調節點還將負責將結果組合返回給用戶。

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

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

通過HLC對事務和操作進行時間意義上的全局排序，不僅僅需要實現HLC的協議，同時需要數據庫內核的支持。這個支持我們在一期已經完成了，是對PG SnapShot管理的增強，作為替換原來的活躍事務列表，為提交序列數或者叫CSN，作為SnapShot，這樣分布式的HOC和單機PG的CSN機制整合，實現了事務的全局排序，從而為實現分布式MVCC提供這個基礎。當所有的事務都按照時間排序時，那原有的MVCC機制就可以正常地運行，保證數據多版本支持，讀寫操作的并行執行。

在分布式Shared Nothing下，除了事務一致性外，如何分布式地處理SQL計算也是一個非常重要的特性。就像剛才提到的，我們首要的目標是最大限度地兼容單機的SQL能力，和事務一致性一起保證用戶應用可以快速在功能上適配分布式數據庫系統，比如對DDL的支持，對簡單DML的支持，對帶子查詢的復雜DML的支持等等。

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

根據項目一期的基礎，data node已經具備高可用，但是集群管理和分布式數據庫的MetaData的管理都需要類似的高可用能力。我們需要一個基于X- Consensus的共識協議的分布式方案，解決用戶數據庫協調邏輯，集群管理和Meta管理的統一的高可用問題，所以我們將會在這個版本里實現分布式的高可用。

總體上，二期將推出一個具備完整SQL和數據一致能力的分布式Shared Nohting數據庫，其主要特性都是對現有單機PG的補充、增強和擴展，這些能力的大部分將在第三期成為插件，滿足用戶快速升級的需求。

? （四） Sharding 和 插件化版

第三期我們將在前面兩期基礎上持續地增強分布式能力、云化能力以及PG社區兼容能力，上方的架構圖反映了我們在第三期的主要思路。

首先DB Node作為核心組件，提供單機數據庫內核能力和分布式計算能力，同時管理每個Shard和跨Shard的事務，保持數據一致性，DB Node自己通過X- Consensus共識協議復制數據到Follower，維護節點級別的數據和邏輯冗余，有助于故障Shard快速恢復。每個DB Node的功能將通過對PG社區內核支持，加上分布式和高可用的插件的Patch實現這些功能。

在DB node上，我們維護一個PolarDB服務層，提供像集群管理，各種運維操作，負載路由以及中心時鐘，是一個Option的需求。相對獨立的服務層將有助于用戶應用的對接，不受內核升級變化的影響，服務層可以隨環境變化，針對不同云提供商和專有云來進行提供支持。

第三期主要的增強體現在以下幾個方面。首先我們加強了Sharding，提供了細粒度的Sharding能力，細粒度Sharding主要加強了PG原生內核相對單機化的架構，計算存儲相對耦合，不利于云化和分布式下彈性和擴展管理。通過細粒度Sharding，使得用戶表在存儲層實現一定程度上的隔離，支持在線的Shard遷移，進一步提升分布式的能力和云化彈性能力。

同時，通過統一化組件，將協調節點和data node合二為一，成為統一的DB Node，和數據庫相關的功能在一個組件里面提供，使得云化部署和管理更加的簡潔。最后通過分布式和Sharding能力的插件化，保持對社區版本的兼容，保證用戶可以快速地升級。

至此，Polar DB開源項目通過三步演進，實現了對PG內核的分布式擴展，保證分布式一致性，同時兼容PG SQL能力和內核版本的升級，具備云化的彈性和管理的簡潔性。當然，后續仍然有很大的優化空間和很多特性會持續推出，比如分布式計算的持續優化、混合負載、HTTP等。

（五）路線圖小結

最后，用下圖來小結我們路線圖的目標和希望達成的方向。

我們期望開源PolarDB是一個高擴展分布式、細粒度、彈性、基于共享協議的高可用，以及易于兼容社區的插件化，每一個目標都反映了我們對云化數據庫基礎需求的理解。

三、開放問題

最后有三個相對開放的問題。

第一個問題是關于分布式和集中式數據庫的市場的考慮，從個人角度來看，傳統數據庫以集中式為主，市場也是如此，將來在很長時間內集中式仍然會是主體。分布式在完善功能、構建生態上會不斷地進步，可以占據一定的市場份額。如果分布式能夠兼容集中式的模式，那么分布式產品既可以當做集中式來使用，還可以按需擴展成分布式，那么更多市場份額就可以期待，這也是我們為什么選擇把開源產品做成分布式主要的原因。

第二個問題是關于分布式和計算存儲分離的關系，個人理解二者是不沖突的，是垂直的關系。分布系統是可以使用集中式的存儲，甚至更加廣義地講，很多云設施可以當成集中式來使用，比如云的塊存儲，對象存儲等等。分布式可以通過自身的擴展性，更加有效地利用這些云存儲的帶寬和IOPS，所以我們的分布式開源產品將來也會做針對存儲計算分離，或者是利用云存儲這樣的架構的優化跟提升。

第三個問題是關于擴展分布式數據庫生態，我們既然已經有了分布式數據庫，它天然就具備一致性，擴展性和分布式計算等能力。那么我們是否可以通過新的數據訪問接口和引入新的用戶定義計算功能，來擴展它所能支持的服務能力，比如將它擴展成其他服務的存儲系統，擴展成其他服務的計算執行系統，這些都是非常值得我們去思考的，但是前提條件是我們先打造出一個完整、功能完善、穩定的開源分布式數據庫，這樣在此基礎上，我們就可以做更多更加有意思的多生態的工作。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

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

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