分析：Greenplum釋出6.0

消息見： https://greenplum.cn/2019/03/20/greenplum6-0/?from=timeline&isappinstalled=0 Greenplum 6.0在社群陸陸續續也是做了很久，從2017年就開始規劃功能，到如今落地曆時兩年。諸多新特性算是頗有吸引力，無論從運維方面、事務能力、功能豐富程度等方面都有提升。這裡僅就文章中所描述的特性做下分析。

1. PGSQL版本更新

Greenplum最開始基于 PGSQL 8.3（開發時最新），已經有近十年的時間（最早的8.3在2008年，參考

https://www.postgresql.org/docs/8.3/release.html

）。在此期間，PGSQL演化的速度是非常可觀的，尤其是從2015年之後，每年一個大版本的疊代更新，都會有很大性能上、功能上的提升，各種特性層出不窮。而這些，卻無法在Greenplum直接展現。

原因在于，Greenplum在PGSQL 8.3核心中直接修改，而不是類似CitusDB等采取插件的方式。這樣的好處是，能夠充分修改優化器、執行器、事務、存儲等各個子產品，達到最優的效果；壞處自然也很明顯，與PGSQL社群長期脫節，無法充分利用社群紅利。

也是以，在Greenplum中更新PGSQL版本是非常痛苦的一件事。而且，Greenplum長期處于閉源狀态，其内部開發者對此的動力未必足夠。有意思的是，Greenplum在開源之後，有些PGSQL社群的老杆子參與進來，也引來了不少原來使用PGSQL的客戶。自然而然地，會更多地考慮更新PGSQL的版本。如今，也算是衆望所歸。

PGSQL版本更新帶來的好處是很明顯的，且不說第一個特性“核心更新”裡帶來的諸多特性，後面的“2. HTAP （OLAP + OLTP）性能大幅提升”和“8. 基于流複制的全新高可用機制“多多少少都跟這個有關系。而在這些特性中，安全性、權限管理增強、JSONB（應該是由我們的PGSQL團隊送出的PATCH）、GIN索引、SP-GiST索引、并行vacuum、CTE等，都是屬于客戶比較期待的功能。

2. HTAP （OLAP + OLTP）性能大幅提升

OLAP對事務正确性的需求一直存在，隻不過被各種各樣的中間工具自己解決了一部分，也就是各種資料同步、清洗、轉換等工作中較為重要的一部分。剩餘不好解決的部分，相當于一直被忍受着，比如T+1的分析、隔夜快變味兒的報表等。

HTAP雖然不能說包治百病的良藥，但其适用場景也是有足夠誘惑力。TP、AP 都在一個系統裡，節約了資料存儲成本、少了資料傳輸等操作成本、不同系統的運維成本等，更有價值的則是資料實時分析，可以及時掌握業務運作情況，不必等待一段時間之後再做決策。

sharding + 2PC看起來似乎都不夠完美，如果實作細節做得足夠好，其實已經足夠解決問題。有多少業務，TPS能夠達到幾萬幾十萬每秒？這裡的TPS，是指類似TPCC等複雜的事務模型，不是TPCB等網際網路裡簡單的點寫、點查。PGSQL從8.3到9.4的增長，是很多細節實作上的累積，在性能方面的提升也很明顯，能夠覆寫的場景已經足夠多樣。如果對資料感興趣，可以測試一下兩階段方面的性能。

在Greenplum中，根據分布鍵做sharding已經與PGSQL中操作單表在使用者體驗方面相差無幾。在分區表等方面甚至更勝一籌。PGSQL MVCC和Snapshot Isolation實作的2PC已經給了Greenplum足夠的事務能力和無縫的事務體驗。

然而，Greenplum在HTAP方面也不是沒有問題存在。

一個是MPP對資源的極度消耗，如果每個Segment配上8個CPU，則8個SQL大查詢就會将CPU吃得死死的，渣都不會給TP業務留，進而影響TP業務的響應時間和并發能力。這個問題，恐怕大部分HTAP系統都要小心處理才行（比如大池子下的租戶、以serverless方式提供AP業務等）。

第二個則是分布鍵帶來的傾斜問題。個别業務可能會對多個字段有JOIN需求，那麼分布鍵的選擇就成為性能優化的第一考慮。分布鍵選擇不好，JOIN引起的資料傳輸過多不說（比如随機分布），還會導緻某個節點資料過多，進而拖累整個SQL性能（木桶效應）。雖然可能有Range Partition等方法能夠緩解（比如騰訊就曾在PGXC上做了Group Partition的東西），還是不可避免地提高了運維複雜度并需要各種取舍。後面提到的一緻性Hash和“7. 靈活資料分布”，一定程度上可以緩解這個問題。

3. 支援複制表（Replicated Table）

這也是一個有意思的功能，典型的以空間換時間。印象中，AWS Redshift老早就有了這個功能（應該在2016年以前）。功能雖然不複雜，在實際場景中，卻會有非常明确的用處。

一個典型的例子就是次元表，比如人員資訊、機構資訊等。這類資料表的特點是，資料量不大、很多查詢/分析都會與此關聯，導緻這類表在查詢時經常被全量傳到各個節點中去。當有這類查詢時，現在則不用進行資料的motion，減少網絡開銷和CPU開銷。

簡單有效、好了解。

4. 線上擴容（Online expand)和一緻性哈希（Jump Consistent Hash）

這個功能，可能DBA或運維系統感受最為深刻。多少運維的同學，經受過磁盤滿的恐懼？一緻性Hash的引入，一定程度上可能緩解傾斜問題，更大的好處在于擴容更友善了。

現在Greenplum在擴容時有兩種方式：

• 添加節點，然後對每張表進行重分布，即複制一份出來後切換表名
• 建立叢集，資料以表為機關導入過去後，切換VIP

基于Greenplum的HDB For PGSQL目前主要采用的是第二種方式，借公共雲大池子堆資源，簡單有效。在之前的版本中，第一種方式腳本問題頗多、資源占用也沒少多少、磁盤空間管理也更複雜，實作下來運作過程中發現并不值得。

與消息中描述的不同，在雲上主要采用了第二種方式，不用停機，隻是讓執行個體隻讀半個小左右和兩次連接配接閃斷重連即可完成。

而在有了一緻性Hash之後，則可以更細粒度的排程，比如以表為機關進行操作，實作上面第一種方式。配合第二種方式，達到更理想的運維效果。

5. 磁盤配額（Disk Quota）

之前的版本中，就已經有Resource Queue用于資源細粒度排程，此次算是功能豐富了一些。目前不是很清楚客戶對這塊的需求如何，暫不評論。

6. 支援Zstandard壓縮算法

Facebook新的壓縮算法，加上之前就支援的LZ4、zlib等，算是更豐富了些。在建表時可選擇，包括分區子表。

7. 靈活資料分布

這個就比較有意思了，典型PGSQL的玩法（自定義類型和操作接口等）。分布不再是簡單的根據計算得來的Hash結果，可以是自定義的算法，那麼給使用者的空間瞬間大了很多。毫無疑問對寫入是有影響的，影響多大跟這個Operator關系很大。比如，基于時間的順序、業務單元（很容易做到類似TDDL）等。問題在于怎麼跟查詢情況比對起來，使用上提高了複雜度。

8. 基于流複制的全新高可用機制

這個功能有很多潛在的好處，充分利用能夠玩出很多花樣。畢竟，Replication是PGSQL連續搞了好多年的功能，在HA、備份、恢複（到時間點）等諸多場景中必不可少，提供了非常高的靈活度。

Greenplum的結構是一個Master下面挂多個Segment（分片），Master有自己的Slave，兩者資料同步走Replication；Segment也有主備，被稱為Primary / Mirror，通過類似于檔案内容傳輸的方式進行資料傳輸，隻能以同步的方式進行，其原因主要是列存儲沒有支援WAL。列存儲資料同步走Replication，就是Primary和Mirror之間資料同步走Replication的最大的障礙。

如果Replication支援了Primary和Mirror間資料同步的話，則意味着列存儲資料也應該是寫入WAL了。那麼，兩個比較大的花活就可以玩了起來：

• 增量備份

  全量備份集加上各節點WAL日志，應該可以做到恢複到時間點。RDS For PGSQL / MySQL借助WAL和邏輯日志，已經做到了這一點；HDB For PGSQL，因為節點上不支援WAL，就隻能支援恢複到備份集。RDS恢複到時間，一直都很受客戶喜歡。相信Greenplum如果實作這個功能，應該會有一定市場。

• 增量同步

  乍看起來，好像對于一個AP系統意義不大。但回想上面叢集擴容的第二種方案，如果從執行個體的備份集恢複，然後建立起到源執行個體的Repliation，那麼執行個體擴容就可以做到秒級切換，且對使用者沒有除了一次閃斷外的其他影響。但需要評估一下，相比于一緻性Hash擴容，建立叢集的優勢在哪裡，比如一次擴容較大的情況。兩種可以互相配合，覆寫不同的場景。

這兩點，是在看到這個功能後的猜想，需要實際驗證是否存在什麼不足和限制。總之，Replication其中價值的挖掘還是有一些想像力在的。

總結

除了以上幾點特性以外，另外一個隐形的好處是：與PGSQL的代碼基線差别更小了。下一個版本估計是10.0甚至12，那麼又将是另外一個大的breakthrough。

PGSQL 10.0的并行查詢已經完備，配合MPP，則會成為性能巨獸，但也是資源吞噬者。對于雲産品來說，資源的消耗帶來性能的提升是好事情，可以刺激客戶買單。 如果再能配合PGSQL 12中的Pluggable Storage，其中可玩的花樣又是多了很多。