数据库激荡 40 年，深入解析 PostgreSQL、NewSQL 演进历程
作者 | 張秋劍，天云數據上海副總經理
責編 | 唐小引
頭圖 | CSDN 下載自東方 IC
出品 | CSDN（ID：CSDNnews）
近日，有傳聞 PostgreSQL 會發布 13 版本，這是去年 9 月發布 12 版本之后，PG 社區緊鑼密鼓的又一大動作，包括提升查詢性能，特別是對大數據集，總的空間利用率等方面。同時，國內以華為 GaussDB 200 從 PostgreSQL 9 中繼承而來，PostgreSQL 在中國的生態變得空前火熱。
這與近兩年來以 Google F1 理論為代表的 NewSQL 數據庫一起，形成了數據庫在這個時代的兩支牛角，氣勢如虹地改變著 TI 數據中心架構的新世界。我們今天就來“庖丁解牛”一把，看看兩種技術路線的不同之處。
PostgreSQL 的前世今生
PostgreSQL 是一個功能強大的開源對象關系型數據庫系統，它使用和擴展了 SQL 語言，并結合了許多安全存儲和擴展最復雜數據工作負載的功能。PostgreSQL 的起源可以追溯到 1986 年，作為加州大學伯克利分校 POSTGRES 項目的一部分，并且在核心平臺上進行了 30 多年的積極開發。直到 2019 年 9 月，已經正式發布到了 12 版本。
圖片來源：維基百科
Michael Stonebraker，2014 圖靈獎獲得者，PostgreSQL 數據庫創始人。目前數據庫領域一共有四位獲得圖靈獎：
1973 年 Bachman（數據庫與網狀數據庫）
1981 年 Codd（關系數據庫）
1998 年 Gray（數據庫與事務處理）
伯克利分校是 Postgres 的搖籃
（圖：伯克利分校著名地標薩瑟門，CSDN 下載自東方 IC）
PostgreSQL 的特點可以用以下這張圖來概括，PostgreSQL 的架構最合適做企業級數據庫。
基于 PostgreSQL 的開源項目分支
述說完了 PostgreSQL 的歷史，我們來聊聊 PostgreSQL 在開源社區世界的發展，我們知道，數據庫近 40 年來的發展，基本上是從 RDBMS 到 OLTP/OLAP 分離，再到分布式數據庫發展的這樣一個歷程。
PostgreSQL 的歷程也是如此，從 PostgreSQL 內核開始，也經歷了 OLTP 分支、OLAP 分支，再到大勢所趨，兩者重新融合，往混合 OLA/TP 的分布式數據庫方向演進。
分布式 PostgreSQL-X2 架構介紹
既然 PostgreSQL 已經發展到了混布階段，那么我們就直接從本文主旨開講，看一看 X2 架構的特點。
首先，X2 是基于 PostgreSQL 源代碼改造成的分布式數據庫，所以幾乎擁有與單機數據庫的所有功能：
支持復雜的 SQL 和跨節點 JOIN；
全局事務的強一致性；
支持 Read commited 事務隔離級別；
幾乎支持所有單機數據庫的 DDL 語句；
支持跨節點的視圖；
支持跨節點的存儲過程。
其次，X2 主要目的實現數據是水平分片，也就是說需要基于分庫分表來解決數據線性擴展的問題。
再次，X2 針對 OLAP 是 shared-nothing 架構，所以是一種 MPP 的技術原理，可以實現 ETL 的數倉加工。
最后，API 完全兼容，外部應用程序可以透明的訪問 Postgres-X2，原先的 jdbc 等不同編程語言的驅動也基本不需要修改就可以訪問 Postgres-X2。
從上圖的 X2 架構我們可以看到，X2 主要由三個部分組成：
GTM：全局事務管理，提供全局事務的服務；
Coordinator：存儲全局的元數據，接受用戶請求，負責生成并執行全局查詢計劃（全局查詢計劃由若干局部查詢計劃組成，執行時將局部查詢計劃分發給 datanode）；
Datanode：存儲本地的元數據，接受并執行 coordinator 的局部查詢計劃（局部查詢計劃也是 SQL）。
分布式 PostgreSQL-X2 的 CAP 分析
我們知道 CAP 原理是考量一個數據庫標高的評價標準，在 RDBMS 時代，Oracle、MS SQLServer 都能較好地接近 CAP。在分布式數據庫時代，CAP 理論依然是我們評價的主要工具。AP 原則又稱 CAP 定理，指的是在一個分布式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。
首先，在一致性上，PostgreSQL-X2 采用 GTM 來實現：
GTM 對事務強一致的保護是比肩傳統 RDBMS 的，這一點上具備生產級。與 2PC 和 MVCC 相比，有先進之處。然而，總體開銷會比較大，如果是巨大的互聯網應用場景，動作上億的并發訪問，性能難于優于 MySQL。
2PC 又稱兩階段提交（two-phase commit protocol）,2pc 是一個非常經典的強一致、中心化的原子提交協議。這里所說的中心化是指協議中有兩類節點：一個是中心化協調者節點（coordinator）和 N 個參與者節點（partcipant）。
MVCC 英文全稱為 Multi-Version Concurrency Control,翻譯為中文即多版本并發控制。MVCC 的實現，通過保存數據在某個時間點的快照來實現的。這意味著一個事務無論運行多長時間，在同一個事務里能夠看到數據一致的視圖。根據事務開始的時間不同，同時也意味著在同一個時刻不同事務看到的相同表里的數據可能是不同的。
客觀上，我們認為它就是樂觀鎖的一整個實現方式，就是每行都有版本號，保存時根據版本號決定是否成功。
在可擴展性方面，Postgres-X2 的擴容，可以在 Coordinator 和 Datanode 兩個方面同時進行擴容。
Postgres-X2 符合分布式數據庫線性擴展的標準，在 x86 橫行的時代，通過橫向對機器的方式擴展計算資源和存儲資源是分布式的核心理念，在這一點上，Postgres-X2 也是這么做的。
但是，Postgres 本身的問題是數據量不能支持很大，數據量在 40 個 TB~200TB，做大型數倉倉庫，性能隨數據量增大，節點數增多，而出現衰減，不能夠完全跟隨線性擴展做線性性能疊加。這是容易被詬病的一點。
再一個，不能夠很好地支持在線熱插拔，熱添加。如果新增節點，需要做停機重啟，這樣的話，實時 ODS 這一類的應用就不能夠在 Postgres-X2 構建的 OLAP 上應用。
分區容錯性不是 PostgresSQL 主要考慮的問題。因為多數分布式系統都分布在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信。
上圖中，G1 和 G2 是兩臺跨區的服務器。G1 向 G2 發送一條消息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。這種情況，目前主要是大型云廠商如：Amazon QWS S3、Google Spanner 和阿里云的 OceanBase 去著重打造。Postgres-X2 我們只從數據中心的高可用性上探討：
高可用方面，GTM 不像 Greenplum 只有一個 master 節點，不適合 OLTP 業務。雖然 Postgres-X2 本身也沒有自動的高可用性，但可以通過 SPOF（single point of failure）分析，根據不同的業務情況進行高可用建設，例如上圖是采用 Primary–Standby 的方式來構建高可用架構。另外，原來的 Postgres-XC 的 D-Node 間不能傳數據，數據需要匯聚到 C 節點進行處理 Postgres-X2 之后允許 D-Node 間進行數據傳輸。
以上，我們算是比較全面的了解了 PostgresSQL 和他的分布式項目 Postgres-X2，我們可以總結一下：
在“從數據庫技術的 40 年發展歷程看新征程”一文中，我們通過回顧數據庫的發展史，重新理解了數據庫的定義——數據庫就是一個存放數據的倉庫，這個倉庫按照一定的數據結構（數據結構是指數據的組織形式或數據之間的聯系）來組織存儲的，我們可以通過數據庫提供的多種方法來管理數據庫里的數據。我們的程序都是在內存中運行的，一旦程序運行結束或者計算機斷電，程序運行中的數據都會丟失,所以我們就需要將一些程序運行的數據持久化到硬盤之中，以確保數據的安全性。說白了，數據庫就是存儲數據的倉庫。
我們已經提到數據庫已經可以分為幾類有：
數據庫經過 40 年的發展，經過從 RDBMS 到 MPP?再到 NoSQL 數庫，如今我們開始關注 NewSQL 數據庫。每個階段的特點是怎樣的呢？
RDBMS——關系型數據庫的優點是：事務、索引、關聯、強一致性，其缺點是：有限的擴展能力、有限的可用性、數據結構取決于表空間；
MPP——大規模并行計算數據庫的優點為擴展性強、事務、索引、關聯、可調一致性，缺點：應用級切分、數據結構取決于表空間；
NoSQL——超越關系型數據庫，數據庫其優點在于擴展性強、可調一致性、靈活的數據結構，而缺點是事務支持差、索引支持差、SQL 支持差。
最經典的是傳統關系型 OLTP 數據庫，其主要用于事務處理的結構化數據庫，典型例子是企業的轉賬記賬、訂單以及商品庫存管理等。其面臨的核心挑戰是高并發、高可用以及高性能下的數據正確性和一致性。
其次是 NoSQL 數據庫及專用型數據庫，其主要用于存儲和處理非結構化或半結構化數據（如文檔，圖，時序、時空，K-V），不強制數據的一致性，以此換來系統的水平拓展、吞吐能力的提升。
再者是分析型數據庫(On-Line Analytic Processing，OLAP)，其應用場景就是海量的數據、數據類型復雜以及分析條件復雜的情況，能夠支持深度智能化分析。其面臨的挑戰主要是高性能、分析深度、與 TP 數據庫的聯動，以及與 NoSQL 數據庫的聯動。
除了數據的核心引擎之外，還有數據庫外圍的服務和管理類工具，比如數據傳輸、數據備份以及數據管理等。
NoSQL 數據庫解決了擴展性，高并發訪問，但還有很多未盡如人意之處，比如：
索引，無法有效使用索引 —>Ad Hoc Query；
協處理器無法分散計算任務 —>大表的 Join 查詢；
SQL 以外的分析查詢 —>Data Science / Machine Learning；
訪問其他數據源 —>和現有 Hadoop 數據聯合查詢（多源異構）；
交互式分析—>復雜 SQL 查詢的性能問題。
于是 NewSQL 呼之欲出。
要說 NewSQL 數據庫，我們要先從 Google 的 F1/Spanner 大規模分布式數據庫說起。
一、Google F1/Spanner
和眾多互聯網公司一樣，在早期 Google 大量使用了 Mysql。Mysql 是單機的，可以用 Master-Slave 來容錯，分區來擴展。但是需要大量的手工運維工作，有很多的限制。因此 Google 開發了一個可容錯可擴展的 RDBMS——F1。和一般的分布式數據庫不同，F1 對應 RDMS 應有的功能，毫不妥協。起初 F1 是基于 MySQL 的，不過會逐漸遷移到 Spanner。
F1 有如下特點：
7×24 高可用。哪怕某一個數據中心停止運轉，仍然可用；
可以同時提供強一致性和弱一致；
可擴展；
支持 SQL；
事務提交延遲 50-100ms，讀延遲 5-10ms，高吞吐。
Spanner 是 Google 的全球級的分布式數據庫(Globally-Distributed Database)。Spanner 的擴展性達到了令人咋舌的全球級，可以擴展到數百萬的機器，數以百計的數據中心，上萬億的行。更給力的是，除了夸張的擴展性之外，他還能同時通過同步復制和多版本來滿足外部一致性，可用性也是很好的。沖破 CAP 的枷鎖，在三者之間完美平衡。
Spanner 是個可擴展、多版本、全球分布式還支持同步復制的數據庫。他是 Google 的第一個可以全球擴展并且支持外部一致的事務。Spanner 能做到這些，離不開一個用 GPS 和原子鐘實現的時間 API。這個 API 能將數據中心之間的時間同步精確到 10ms 以內。因此有幾個核心的功能：無鎖讀事務，原子 schema 修改，讀歷史數據無 block。
由于 F1/Spanner 并不開源，通過現有公開資料僅僅只能窺得 F1/Spanner 的滄海一粟，所以我們主要通過 Google 的公開資料的學習和發展自身，這比拿來主義的 PostgreSQL 要難能可貴的多。
二、F1 Query 對于 NewSQL 的奠基
2018 年，Google 發表了論文“F1 Query：Declarative Querying at Scale”，意味著對 F1/Spanner 架構的升級。解決了如下幾個核心問題：
一是，多種異構的存儲平臺（Bigtable,Spanner,Google Spreadsheets 等）共存；
二是，不同存儲平臺上的計算不統一；
三是，復雜的商業邏輯開始需要實時的分析和數據處理（HTAP）。
于是 F1 數據庫延伸成了這樣一種數據庫：
第一，它是獨立計算層，底層對接了不同的數據源；
第二，它試圖統一 OLTP、OLAP 和 ETL 的 Workload；
第三，它也是一個完整的 ETL 平臺；
第四，它推出了幾種訪問數據的新形式，UDF、UDA 和 TVF SQL；
第五，Shading-nothing，這個之后會詳細介紹。
一種數據，在完美融合 CAP 原理之后，又破天荒的解決了同時支持 OLTP、OLAP、ETL 三種場景的數據庫使用。可以說給我們帶來了一片“新”天地，因為開創了數據庫的“新”紀元。這個“新”，被 451 Group 的分析師 Matthew Aslett 命名為“NewSQL”。
三、NoSQL 謝幕，NewSQL 登場
NewSQL 一詞是由 451 Group 的分析師 Matthew Aslett 在研究論文中提出的。它代指對老牌數據庫廠商做出挑戰的一類新型數據庫系統。NewSQL 是對各種新的可擴展/高性能數據庫的簡稱，這類數據庫不僅具有 NoSQL 對海量數據的存儲管理能力，還保持了傳統數據庫支持 ACID 和 SQL 等特性。
NewSQL 是指這樣一類新式的關系型數據庫管理系統，針對 OLTP（讀-寫）工作負載，追求提供和 NoSQL 系統相同的擴展性能，且仍然保持 ACID 和 SQL 等特性（scalable and ACID and (relational and/or sql -access)）。
NewSQL 一經問世，發展至今，已經形成一個龐大的技術 family 了：
通過上文我們可以知道，NewSQL 的優勢在于 SQL 的支持能力、擴展性、實時性和事務的處理能力。在 NewSQL 蓬勃發展的前提下，許多新興技術公司開始打造自己的新一代分布式數據庫，其設計理念：
一、分布式架構
通過主節點下發任務的模式，每個節點都可以提供服務，在擴展性上，Master 不會是瓶頸。
客戶端通過不同的接口訪問形式，直接訪問主服務節點服務；
主服務節點收到服務請求進行分析處理，分配到不同的分配服務節點執行；
分片服務節點收到執行請求，進行 SQL 解析處理并執行 SQL 計劃；
SQL 執行服務底層存儲數據進行處理訪問，并反回處理結果；
通過 Raft 協議確保服務之間數據同步；
存儲根據 AP、TP 分為共享存儲和非共享存儲。
而與之相比較，PostgreSQL 現在的分布式都是 MPP 的架構，share nothing，存在增加、減少節點數據重新分配的問題。
二、從分庫分表走向 Sharding 與 Partition（分片與分區）
通過我們前面對 PostgreSQL 的解讀，數據分庫分表是一種被迫的選擇，無奈之舉，如果能夠不做分庫分表，就盡量不要做這方面的設計，因為會對業務提出要求，或者改動業務。所以，我們在 NewSQL 的設計上，要多做 Sharding 與 Partition（分片與分區）的設計。
數據分區
分區就是把一張表的數據分成 N 個區塊，在邏輯上看最終只是一張表，但底層是由 N 個物理區塊組成的。
什么時候考慮使用分區呢？當一張表的查詢速度已經慢到影響使用的時候，數據量大，SQL 經過優化，表中的數據是分段的，或者對數據的操作往往只涉及一部分數據，而不是所有的數據。
分區解決的問題主要是可以提升查詢效率。
數據分片
在分布式存儲系統中，數據需要分散存儲在多臺設備上，數據分片（Sharding）就是用來確定數據在多臺存儲設備上分布的技術。數據分片要達到三個目的：
分布均勻，即每臺設備上的數據量要盡可能相近；
負載均衡，即每臺設備上的請求量要盡可能相近；
擴縮容時產生的數據遷移盡可能少。
三、數據同步與一致性 —— Raft/Paxos
目前主流的 NewSQL 數據庫的數據同步是基于 Raft 協議的。
在 Raft 中三種角色：
Leader：負責接收客戶端的請求，將日志復制到其他節點并告知其他節點何時應用這些日志是安全的；
Candidate：用于選舉 Leader 的一種角色；
Follower：負責響應來自 Leader 或者 Candidate 的請求。
所有節點初始狀態都是 Follower 角色；
超時時間內沒有收到 Leader 的請求則轉換為 Candidate 進行選舉；
Candidate 收到大多數節點的選票則轉換為 Leader；發現 Leader 或者收到更高任期的請求則轉換為 Follower；
Leader 在收到更高任期的請求后轉換為 Follower。
Raft 狀態機：
所有一致性算法都會涉及到狀態機，而狀態機保證系統從一個一致的狀態開始，以相同的順序執行一些列指令最終會達到另一個一致的狀態。
所有的節點以相同的順序處理日志，那么最終 x、y、z 的值在多個節點中都是一致的。
在這一點上，PostgreSQL-X2 的架構是以主備的模式來確定的。
四、分布式事務
事務開始，記錄事務唯一 ID，執行操作，記錄修改的 shard，執行預提交動作，提交或回滾；
寫入時當前采用鎖機制；
讀取使用快照讀取，存儲層每次寫入都是追加寫入，通過覆蓋機制進行數據變更。
這樣的好處是，數據的鮮活性可以實時保證，數據更新插入和分析可以一起完成，像實時數倉、實時統計匯總計算就能夠實現了。而在 PostgreSQL 的 OLAP 雖然可以通過批量或者插入的方式實現更新，但要人工做優化，持續投入人力干預，性能被動式保證。
五、存儲層——KV 存儲
在存儲方面，我們有兩種選擇：
堆存：數據可以通過 key 獲取，同時可以直接讀取數據；
非堆存：數據只能通過 key 來獲取，無法直接讀取到數據。
非堆存儲只能通過 key 來獲取數據，會導致不斷的離散的讀取，所以不能適應于 AP 的場景。
客戶端通過不同的接口訪問形式，直接訪問主服務節點服務；
主服務節點收到服務請求進行分析處理，分配到不同的分配服務節點執行；
分片服務節點收到執行請求，進行 sql 解析處理并執行 SQL 計劃；
SQL 執行服務底層存儲數據進行處理訪問，并反回處理結果；
Zookeeper 保證相關服務應用的高可用；
HDFS 持久化底層存儲數據，并利用三副本技術保證數據不丟失。
與之相比較，PostgreSQL 是本地化存儲，存儲也可以分為列存和行存等。
六、多源異構與數據邦聯
NewSQL 的數據多源異構，要兼顧考慮對過去數據庫的全面支持，尤其是 NoSQL 和 Hadoop 生態體系，因為畢竟這兩者已經非常普及。
在多源異構方面，PostgreSQL 是通過 FDW 支持多源異構，可訪問 Oracle、PG、MySQL、MongoDB 等，對 Hadoop 體系和 NoSQL 支持力度低，效率和性能也較難做到極致。
七、基于 NewSQL 的分布式數據庫實踐
綜合以上六點，通過對 NewSQL 的：
分布式架構；
數據的分區分片；
數據同步與一致性；
分布式事務；
存儲層，KV 存儲設計；
數據庫多源異構。
我們綜合設計研發，推出了一款自主可控的國產分布式數據庫 —— Hubble。Hubble 同時支持 OLTP 和 OLAP 場景，即在同一份數據上，實現事務型處理的同時支持實時分析，省去了費時的 ETL 過程。
最后，將 Hubble 作為代表與 PsostgreSQL-X2 做一個橫向分析，能夠幫助我們更好地理解本文開篇所言 ——?分布式數據庫的兩支牛角各自的技術路線。
作者簡介：張秋劍，天云數據上海分公司副總經理，資深金融行業大數據技術架構專家。計算機科學技術碩士學位后，曾就職于 IBM 等公司，九三學社金融委員會委員。目前主要為銀行、證券和保險等金融行業客戶提供大數據平臺及人工智能平臺的規劃和方案設計工作。曾在 IEEE 等期刊發表多篇論文。
推薦閱讀
一文帶你認識keepalived，再帶你通關LVS+Keepalived！
那個分分鐘處理 10 億節點圖計算的 Plato，現在怎么樣了？
“谷歌殺手”發明者，科學天才 Wolfram
數據庫激蕩 40 年，深入解析 PostgreSQL、NewSQL 演進歷程
超詳細！一文告訴你 SparkStreaming 如何整合 Kafka ！附代碼可實踐
5分鐘！就能學會以太坊 JSON API 基礎知識！
真香，朕在看了！
總結
以上是生活随笔為你收集整理的数据库激荡 40 年，深入解析 PostgreSQL、NewSQL 演进历程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 最新！Vicor 270V-28V DC
- 下一篇： Linux系统常用指令总结