共計 4213 個字符，預計需要花費 11 分鐘才能閱讀完成。
本篇內容主要講解“GreenPlum 簡單性能測試方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“GreenPlum 簡單性能測試方法是什么”吧!
一.TPC- H 原理簡介
TPC- H 是由 TPC(Transaction Processing Performance Council) 事務處理性能委員會公布的一套針對數據庫決策支持能力的測試基準，通過模擬數據庫中與業務相關的復雜查詢和并行的數據修改操作考察數據庫的綜合處理能力，獲取數據庫操作的響應時間和每小時執行的查詢數指標 (QphH@Size)。
TPC- H 基準模型中定義了一個數據庫模型，容量可以在 1GB~10000GB 的 8 個級別中進行選擇。數據庫模型包括 CUSTOMER、LINEITEM、NATION、ORDERS、PART、PARTSUPP、REGION 和 SUPPLIER 8 張數據表，涉及 22 條復雜的 select 查詢流語句和 2 條帶有 insert 和 delete 程序段的更新流語句。
二. 目的
1. 比較在同等資源條件下具有分布式屬性的 GreenPlum 與單機版 mysql 在進行 TPC- H 類測試的性能區別。
2. 分析兩種 DB 造成性能區別的原因。
三. 測試環境與配置信息
測試環境：騰訊云
測試對象：GreenPlum、Mysql，兩者的配置信息統計如下：
指標參數文本 1 文本 2 操作系統 CentOS 6.7 64 位 cpuIntel(R) Xeon(R) CPU E5-26xx v3 8 核內存 24GB 公網帶寬 100MbpsIP123.207.228.51 版本 MySql5.6
表 2 Mysql 服務器
四. 測試數據量統計表名稱數據條數 customer150000lineitem6001215nation25orders1500000part200000partsupp800000region5supplier10000
表 3 各測試表數據量統計
五. 執行時間統計執行的 sqlGeenPlum 執行時間（單位：秒）Mysql 執行時間（單位：秒）Q14.0112.66Q20.503.27Q31.355.06Q40.110.01Q50.1927.29Q60.012.50Q76.0610.79Q81.4639.78Q94.00 12 小時 Q100.144.74Q110.307.90Q120.082.35Q131.04 12 小時 Q140.049.37Q150.074.76Q160.512.90Q173.2148697.95Q1814.23 12 小時 Q190.9523.12Q200.16 12 小時 Q217.23 12 小時 Q220.968540.22
表 4 22 條 sql 執行時間統計
六. 性能對比分析
根據執行時間的統計，我們可以看出兩種數據庫在進行 TPC- H 類測試有著較大差異，下面我們將選取兩個典型的事例 SQL，分析 GreenPlum 與 Mysql 在執行該類 SQL 的性能差異原因。
示例一
我們選取 Q3，從執行時間統計可以看出 GreenPlum 的執行速度大概是 Mysql 的 4 倍左右。首先，查看下 Q3 語句，如下圖 1 所示。
圖 1 Q3 語句
然后，explain 下 Q3，得到結果分別如圖 2 和圖 3。
圖 2 GreenPlum 執行 explain Q3 的結果
圖 3 Mysql 執行 explain Q3 的結果
從以上的執行過程解釋可以看出，GreenPlum 上的執行步驟主要有：
在所有 segment（這里為 4 個）同時進行條件查詢 Filter；
兩表做關聯時，會進行數據廣播，每個 segment 將查詢到的結果廣播到其他所有 segment，每個 segment 得到該表 Filter 后的所有結果（全量數據），后會進行一次 hash；
在所有 segment 上同時做 hash join，因為還要和其他表做 join，會繼續將結果廣播到所有 segment 上；
進行 group by 聚合操作。首先在所有 segment 上根據 group by 條件進行一次 HashAggregate 聚合（目的是減少重分布的數據量），然后將結果數據按 group by 字段進行重分布，最后，每個 segment 再按條件聚合一次得到最終結果；
根據 order by 條件，在所有 segment 上同時進行 sort，根據 Limit 條件選取數據，這里是 Limit 10，每個 segment 都選取 10 條數據匯總到 master 上，由 master 再選取前 10 條；
進行 Merge，所有 segment 將結果發給 master，由 master 進行一次歸并，根據 Limit 條件選取結果的前 10 條數據，返回。
整個過程耗時的點主要有：
做了兩次廣播，總量為（30178+144314=174492）17 萬條；
根據 group by 的條件 Redistribute 一次，數量約為 8 萬條；
hash join 兩次，都是在兩個表之間進行的 hash join，在單個 segment 上，兩表之間的 hash join 量分別大約是 18 萬與 3 萬、84 萬與 14 萬；
sort 一次，單個 segment 的 sort 從 8 萬條數據中取出前 10 條記錄。
Mysql 的執行過程比較簡單，首先是在 lineitem 表做一次 where 過濾，獲取結果計算出 revenue 值，由于 order by 的值是 revenue，因此，需要一次非關鍵字（revenue）排序，排序的量為 3271974（約 320 萬），這里非常耗時。然后在 order 表和 customer 表做一些 where 過濾。
從以上執行過程可以看出，主要的耗時點應該在 sort 操作上，GreenPlum 是在所有 segment 上同時進行一次 8 萬條記錄的 sort，而 Mysql 則是直接進行一次 320 萬記錄的 sort。由于 Mysql 是在單個服務器上搭建的，該服務器的性能（8 核 CPU、24GB 內存）遠高于 GreenPlum 的單個 segment（1 核 CPU、4GB 內存），因此，如果充分利用服務器的性能，兩者的 sort 時間應該相差不大，可是事實如此嗎？接下來我們查看下 Mysql 所在服務器的 CPU 使用情況，得到執行 Q3 前后的結果如圖 4 所示：
圖 4 Mysql 執行 Q3 前后其所在服務器的 CPU 使用時間情況
可以看出，執行 Q3 前后，只有 CPU6 的使用時間有較大變化，變化時間大概為 500jiffies 即 5 秒，與總的 sql 執行時間（5.06 秒）基本吻合，因此，執行 Q3 過程中，mysql 所在的服務器只使用了一個 CPU 來進行計算。
綜上，Mysql 和 GreenPlum 的耗時區別主要體現在 sort 操作上，Mysql 對 320 萬條記錄做了一次 sort，但只能使用單個 CPU 計算，沒有發揮服務器本身多核 CPU 的性能優勢，整體執行時間較長。而 GreenPlum 由于采用了分布式的結構，每個 segment 對應一個 CPU，數據均勻分布到各個 segment，在各節點并行執行 Filter、hash join、group by，sort 等操作，充分利用了每個 CPU 的計算能力，然后將結果進行廣播，或對整體數據進行重分布再進行計算，最后由 master 歸并各 segment 的結果數據。在進行廣播或者重分布時，會在 segment 節點間進行數據傳輸，消耗了一定的時間，但由于 GreenPlum 對 sql 的優化更好，以及并行計算的能力，因此，相比于 Mysql，總的執行時間更短。
示例二
我們再選取一個典型的事例——Q17，根據執行時間統計，Mysql 的執行時間是 GreenPlum 的 1.5 萬倍，這是一個相當大的差距！究竟是什么原因會導致如此大的區別，我們首先查看 Q17 的 sql 語句如下圖 5 所示。
圖 5 Q17 語句
與 Q3 不同的是 Q17 涉及到了子查詢，依舊，我們在 mysql 和 GreenPlum 上 explain 下 sql，得到的結果如圖 6、圖 7 所示。
圖 6 GreenPlum 執行 explain Q17 的結果
圖 7 Mysql 執行 explain Q17 的結果
子查詢 sql（select l_partkey as agg_partkey, 0.2 * avg(l_quantity) as avg_quantity from lineitem group by l_partkey）里面涉及 group by，我們來看一下兩者在聚合上的區別：
Mysql：由于 group by 的是非索引關鍵字，所以直接進行了 filesort lineitem(600 萬條記錄)。
GreenPlum：首先在每個 segment（有該表 150 萬條記錄）做一次 group by l_partkey，采用了更高效的 HashAggregate 聚合方式。為了所有 segment 可以并行做 join，會將 lineitem 表的數據做一次重分布（5 萬條記錄），每個 segment 得到的是 hash 分布到自身的記錄。
可以看出，Mysql 在聚合上的效率要明顯低于 GreenPlum。
然后，子查詢結果會與現表做 join 操作，我們來繼續看下兩者在 join 上的區別：
Mysql：把子查詢結果作為臨時表（20 萬條記錄）與現表 lineitem(600 萬條記錄）直接做了 join，將產生 600 萬×20 萬 =1.2 萬億的數據量 …….
GreenPlum：首先對 sql 進行了優化，先執行了 where 條件，減少了 part 表的數據到 260 條（單個 segment 的量，總量為 4×260 條，接下來的數據量都為單個 segment 的）。
采用了更高效的 join 方式 hash join。
如果使用臨時表與 lineitem 表直接 hash join，會產生 50 萬左右的數據量，但 GreenPlum 并沒有這么做，而是利用 part 表來進行 join，因為 part 表經過 where 過濾后數據量非常小，和 part 表做 hash join，數據量也相對較小。總共做了兩次 hash join：
part 表與臨時表 part_agg，產生數據量 246 條；
part 表與 lineitem 表，產生數據量 2598 條；
兩者一對比，GreenPlum 做 join 的數據量為 (246+2598)×4=11376 條，遠小于 Mysql 的 1.2 萬億條，兩者的性能不言而喻。
綜上，在執行 Q17 時，Mysql 和 GreenPlum 的效率差別除了 GreenPlum 具有并行計算能力外，還體現在聚合和關聯這兩個操作的優化上面。
到此，相信大家對“GreenPlum 簡單性能測試方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
