GreenPlum簡單性能測試與分析

版權聲明：本文由黃輝原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/195

來源：騰雲閣 https://www.qcloud.com/community

 

現在，多樣的交易模式以及大衆消費觀念的改變使得數據庫應用領域不斷擴大，現代的大型分佈式應用系統的數據膨脹也對數據庫的海量數據處理能力和並行處理能力提出了更高的要求，如何在數據呈現海量擴張的同時提升處理速度和應用系統的可用性，使客戶能同時獲得更高的處理速度、更高的數據可用性和更大的數據集，是數據庫系統面臨的一個挑戰。
經過TPC-H基準測試，可得到數據庫單位時間內的性能處理能力，爲評估數據庫系統的現有性能服務水平提供有效依據，經過橫向對比促進數據庫系統的總體質量提高，能更好地在重大信息化工程中實現推廣。

一.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位
cpu	Intel(R) Xeon(R) CPU E5-26xx v3 8核
內存	24GB
公網帶寬	100Mbps
IP	123.207.228.51
版本	MySql5.6

表2 Mysql服務器

四.測試數據量統計

表名稱	數據條數
customer	150000
lineitem	6001215
nation	25
orders	1500000
part	200000
partsupp	800000
region	5
supplier	10000

表3 各測試表數據量統計

五.執行時間統計

執行的sql	GeenPlum執行時間（單位：秒）	Mysql執行時間（單位：秒）
Q1	4.01	12.66
Q2	0.50	3.27
Q3	1.35	5.06
Q4	0.11	0.01
Q5	0.19	27.29
Q6	0.01	2.50
Q7	6.06	10.79
Q8	1.46	39.78
Q9	4.00	>12小時
Q10	0.14	4.74
Q11	0.30	7.90
Q12	0.08	2.35
Q13	1.04	>12小時
Q14	0.04	9.37
Q15	0.07	4.76
Q16	0.51	2.90
Q17	3.21	48697.95
Q18	14.23	>12小時
Q19	0.95	23.12
Q20	0.16	>12小時
Q21	7.23	>12小時
Q22	0.96	8540.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上的執行步驟主要有：

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，獲得的結果如圖六、圖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在TPC-H類的測試性能會遠遠高於單機版的Mysql，說明具備分佈式屬性的GreenPlum在關於複雜語句（涉及到多表屬性查詢、group by、order by 、join、子查詢等）的查詢效率較高，且能夠充分利用系統CPU資源來提高查詢速度，更適用於OLAP。

八.其餘事項

1. 因爲原生的TPC-H的測試用例不直接支持GreenPlum和Mysql，所以須要修改測試腳本，生成新的建表語句如《附錄一》所示，測試sql如《附錄二》。
2. GreenPlum各節點間的帶寬要儘量大，通常查詢中會涉及到廣播或者重分佈動做，須要在節點間傳輸數據，若是帶寬太小，易在此形成性能瓶頸。
3. 測試語句不要過於簡單，而且測試數據量不要太少，不然GreenPlum在作數據傳輸的時間會遠高於計算時間。