1.背景
一張UML類圖可以簡單的說明GreenPlum和DeepGreen之間的關系：
- 首頁：http://greenplum.org/
- 源碼：開源，https://github.com/greenplum-db/gpdb，
DeepGreen：
- 首頁：http://vitessedata.com/deepgreen-db
- 源碼：不開源，安裝包：http://vitessedata.com/deepgreen-db-download
DeepGreen官方宣傳的優勢：
事實是否如此呢？
2.測試
在10GB資料集下的測試結果如下：
DeepGreen比GreenPlum快，基本符合預期，至于快多少倍，我們暫不關心，畢竟10GB的容量對于資料倉庫來講太小了。
在
1TB資料集下的測試結果如下：
大部分sql都是DeepGreen比GreenPlum快，但是3、5、17都是GreenPlum快，
不符合預期！
3.分析
我在附件中貼上了第1和第3兩個sql的explain以及DDL，大家感興趣的話可以對比下，能發現一些有趣的東西：）
我們關心的是為什麼DeepGreen會比GreenPlum慢！？我們以第3個sql來進行分析。
照着explain檔案逐行分析比對資料總結成如下兩個執行計劃圖，左邊是GreenPlum的執行計劃，右邊是DeepGreen的執行計劃：
整個執行計劃掃描3張表，原始記錄：lineitem表有5,999,989,709條記錄，orders表有1,500,000,000條記錄，customer表150,000,000條記錄。
明顯的，兩個執行計劃不一樣，圖中的數字是從explain檔案中抽取出來的，表示的是每個節點執行完後的有效資料記錄數量；每個執行計劃的耗時主要集中在圖中藍色節點部分。
善于觀察的同僚應該已經看到右側執行計劃中的紅色框框部分了:)
在custkey關聯這個階段：
左側各節點的計算量：(149,630,385/72) x 29,998,152 = 2,078,199 x 29,998,152
右側各節點的計算量：144,147,772 x (3,266,814,571/72) = 144,147,772 x 45,372,424
兩個執行計劃的關聯計算任務不在一個量級，耗時也顯而易見了，這就是為什麼DeepGreen比GreenPlum執行慢的原因！而為什麼DeepGreen會優化選擇這個慢的方案，這就同他優化器的具體實作有關了。
附件：
attachment.zip
看這裡：
《
【大資料之資料倉庫】選型流水記
》
本文來自網易雲社群，經作者何李夫授權釋出。
原文位址：【大資料之資料倉庫】GreenPlum PK DeepGreen（TPCH）
更多網易研發、産品、營運經驗分享請通路網易雲社群。