GreenPlum簡單性能測試方法是什么

本篇內容主要講解“GreenPlum簡單性能測試方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“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，兩者的配置信息統計如下：

表2 Mysql服務器

四.測試數據量統計

表3 各測試表數據量統計

五.執行時間統計

表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上的執行步驟主要有：

1. 在所有segment（這里為4個）同時進行條件查詢Filter；

2. 兩表做關聯時，會進行數據廣播，每個segment將查詢到的結果廣播到其他所有segment，每個segment得到該表Filter后的所有結果（全量數據），后會進行一次hash；

3. 在所有segment上同時做hash join，因為還要和其他表做join，會繼續將結果廣播到所有segment上；

4. 進行group by聚合操作。首先在所有segment上根據group by條件進行一次HashAggregate聚合（目的是減少重分布的數據量），然后將結果數據按group by字段進行重分布，最后，每個segment再按條件聚合一次得到最終結果；

5. 根據order by條件，在所有segment上同時進行sort，根據Limit條件選取數據，這里是Limit 10，每個segment都選取10條數據匯總到master上，由master再選取前10條；

6. 進行Merge，所有segment將結果發給master，由master進行一次歸并，根據Limit條件選取結果的前10條數據，返回。

整個過程耗時的點主要有：

1. 做了兩次廣播，總量為（30178+144314=174492）17萬條；

2. 根據group by的條件Redistribute一次，數量約為8萬條；

3. hash join兩次，都是在兩個表之間進行的hash join，在單個segment上，兩表之間的hash join量分別大約是18萬與3萬、84萬與14萬；

4. 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簡單性能測試方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！