本篇內(nèi)容主要講解“GreenPlum簡(jiǎn)單性能測(cè)試方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“GreenPlum簡(jiǎn)單性能測(cè)試方法是什么”吧!

創(chuàng)新互聯(lián)建站堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的新邱網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

一.TPC-H原理簡(jiǎn)介

TPC-H是由TPC(Transaction Processing Performance Council)事務(wù)處理性能委員會(huì)公布的一套針對(duì)數(shù)據(jù)庫決策支持能力的測(cè)試基準(zhǔn)，通過模擬數(shù)據(jù)庫中與業(yè)務(wù)相關(guān)的復(fù)雜查詢和并行的數(shù)據(jù)修改操作考察數(shù)據(jù)庫的綜合處理能力，獲取數(shù)據(jù)庫操作的響應(yīng)時(shí)間和每小時(shí)執(zhí)行的查詢數(shù)指標(biāo)(QphH@Size)。
TPC-H基準(zhǔn)模型中定義了一個(gè)數(shù)據(jù)庫模型，容量可以在1GB~10000GB的8個(gè)級(jí)別中進(jìn)行選擇。數(shù)據(jù)庫模型包括CUSTOMER、LINEITEM、NATION、ORDERS、PART、PARTSUPP、REGION和SUPPLIER 8張數(shù)據(jù)表，涉及22條復(fù)雜的select查詢流語句和2條帶有insert和delete程序段的更新流語句。

二.目的

1.比較在同等資源條件下具有分布式屬性的GreenPlum與單機(jī)版MySQL在進(jìn)行TPC-H類測(cè)試的性能區(qū)別。
2.分析兩種DB造成性能區(qū)別的原因。

三.測(cè)試環(huán)境與配置信息

測(cè)試環(huán)境：騰訊云
測(cè)試對(duì)象：GreenPlum、Mysql，兩者的配置信息統(tǒng)計(jì)如下：

指標(biāo)	參數(shù)
文本1	文本2
操作系統(tǒng)	CentOS 6.7 64位
cpu	Intel(R) Xeon(R) CPU E5-26xx v3 8核
內(nèi)存	24GB
公網(wǎng)帶寬	100Mbps
IP	123.207.228.51
版本	MySql5.6

表2 Mysql服務(wù)器

四.測(cè)試數(shù)據(jù)量統(tǒng)計(jì)

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

表3 各測(cè)試表數(shù)據(jù)量統(tǒng)計(jì)

五.執(zhí)行時(shí)間統(tǒng)計(jì)

執(zhí)行的sql	GeenPlum執(zhí)行時(shí)間（單位：秒）	Mysql執(zhí)行時(shí)間（單位：秒）
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小時(shí)
Q10	0.14	4.74
Q11	0.30	7.90
Q12	0.08	2.35
Q13	1.04	>12小時(shí)
Q14	0.04	9.37
Q15	0.07	4.76
Q16	0.51	2.90
Q17	3.21	48697.95
Q18	14.23	>12小時(shí)
Q19	0.95	23.12
Q20	0.16	>12小時(shí)
Q21	7.23	>12小時(shí)
Q22	0.96	8540.22

表4 22條sql執(zhí)行時(shí)間統(tǒng)計(jì)

六.性能對(duì)比分析

根據(jù)執(zhí)行時(shí)間的統(tǒng)計(jì)，我們可以看出兩種數(shù)據(jù)庫在進(jìn)行TPC-H類測(cè)試有著較大差異，下面我們將選取兩個(gè)典型的事例SQL，分析GreenPlum與Mysql在執(zhí)行該類SQL的性能差異原因。

示例一

我們選取Q3，從執(zhí)行時(shí)間統(tǒng)計(jì)可以看出GreenPlum的執(zhí)行速度大概是Mysql的4倍左右。首先，查看下Q3語句，如下圖1所示。

圖1 Q3語句

然后，explain下Q3，得到結(jié)果分別如圖2和圖3。

圖2 GreenPlum執(zhí)行explain Q3的結(jié)果

圖3 Mysql執(zhí)行explain Q3的結(jié)果

從以上的執(zhí)行過程解釋可以看出，GreenPlum上的執(zhí)行步驟主要有：

1. 在所有segment（這里為4個(gè)）同時(shí)進(jìn)行條件查詢Filter；

2. 兩表做關(guān)聯(lián)時(shí)，會(huì)進(jìn)行數(shù)據(jù)廣播，每個(gè)segment將查詢到的結(jié)果廣播到其他所有segment，每個(gè)segment得到該表Filter后的所有結(jié)果（全量數(shù)據(jù)），后會(huì)進(jìn)行一次hash；

3. 在所有segment上同時(shí)做hash join，因?yàn)檫€要和其他表做join，會(huì)繼續(xù)將結(jié)果廣播到所有segment上；

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

5. 根據(jù)order by條件，在所有segment上同時(shí)進(jìn)行sort，根據(jù)Limit條件選取數(shù)據(jù)，這里是Limit 10，每個(gè)segment都選取10條數(shù)據(jù)匯總到master上，由master再選取前10條；

6. 進(jìn)行Merge，所有segment將結(jié)果發(fā)給master，由master進(jìn)行一次歸并，根據(jù)Limit條件選取結(jié)果的前10條數(shù)據(jù)，返回。

整個(gè)過程耗時(shí)的點(diǎn)主要有：

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

2. 根據(jù)group by的條件redistribute一次，數(shù)量約為8萬條；

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

4. sort一次，單個(gè)segment的sort從8萬條數(shù)據(jù)中取出前10條記錄。

Mysql的執(zhí)行過程比較簡(jiǎn)單，首先是在lineitem表做一次where過濾，獲取結(jié)果計(jì)算出revenue值，由于order by的值是revenue，因此，需要一次非關(guān)鍵字（revenue）排序，排序的量為3271974（約320萬），這里非常耗時(shí)。然后在order表和customer表做一些where過濾。

從以上執(zhí)行過程可以看出，主要的耗時(shí)點(diǎn)應(yīng)該在sort操作上，GreenPlum是在所有segment上同時(shí)進(jìn)行一次8萬條記錄的sort，而Mysql則是直接進(jìn)行一次320萬記錄的sort。由于Mysql是在單個(gè)服務(wù)器上搭建的，該服務(wù)器的性能（8核CPU、24GB內(nèi)存）遠(yuǎn)高于GreenPlum的單個(gè)segment（1核CPU、4GB內(nèi)存），因此，如果充分利用服務(wù)器的性能，兩者的sort時(shí)間應(yīng)該相差不大，可是事實(shí)如此嗎？接下來我們查看下Mysql所在服務(wù)器的CPU使用情況，得到執(zhí)行Q3前后的結(jié)果如圖4所示：

圖4 Mysql執(zhí)行Q3前后其所在服務(wù)器的CPU使用時(shí)間情況

可以看出，執(zhí)行Q3前后，只有CPU6的使用時(shí)間有較大變化，變化時(shí)間大概為500jiffies即5秒，與總的sql執(zhí)行時(shí)間（5.06秒）基本吻合，因此，執(zhí)行Q3 過程中，mysql所在的服務(wù)器只使用了一個(gè)CPU來進(jìn)行計(jì)算。
綜上，Mysql和GreenPlum的耗時(shí)區(qū)別主要體現(xiàn)在sort操作上，Mysql對(duì)320萬條記錄做了一次sort，但只能使用單個(gè)CPU計(jì)算，沒有發(fā)揮服務(wù)器本身多核CPU的性能優(yōu)勢(shì)，整體執(zhí)行時(shí)間較長。而GreenPlum由于采用了分布式的結(jié)構(gòu)，每個(gè)segment對(duì)應(yīng)一個(gè)CPU，數(shù)據(jù)均勻分布到各個(gè)segment，在各節(jié)點(diǎn)并行執(zhí)行Filter、hash join、group by，sort等操作，充分利用了每個(gè)CPU的計(jì)算能力，然后將結(jié)果進(jìn)行廣播，或?qū)φw數(shù)據(jù)進(jìn)行重分布再進(jìn)行計(jì)算，最后由master歸并各segment的結(jié)果數(shù)據(jù)。在進(jìn)行廣播或者重分布時(shí)，會(huì)在segment節(jié)點(diǎn)間進(jìn)行數(shù)據(jù)傳輸，消耗了一定的時(shí)間，但由于GreenPlum對(duì)sql的優(yōu)化更好，以及并行計(jì)算的能力，因此，相比于Mysql，總的執(zhí)行時(shí)間更短。

示例二

我們?cè)龠x取一個(gè)典型的事例——Q17，根據(jù)執(zhí)行時(shí)間統(tǒng)計(jì)，Mysql的執(zhí)行時(shí)間是GreenPlum的1.5萬倍，這是一個(gè)相當(dāng)大的差距！究竟是什么原因會(huì)導(dǎo)致如此大的區(qū)別，我們首先查看Q17的sql語句如下圖5所示。

圖5 Q17語句

與Q3不同的是Q17涉及到了子查詢，依舊，我們?cè)趍ysql和GreenPlum上explain下sql，得到的結(jié)果如圖6、圖7所示。

圖6 GreenPlum執(zhí)行explain Q17的結(jié)果

圖7 Mysql執(zhí)行explain Q17的結(jié)果

子查詢sql（select l_partkey as agg_partkey, 0.2 * avg(l_quantity) as avg_quantity from lineitem group by l_partkey）里面涉及group by，我們來看一下兩者在聚合上的區(qū)別：

Mysql：由于group by的是非索引關(guān)鍵字，所以直接進(jìn)行了filesort lineitem(600萬條記錄)。

GreenPlum：首先在每個(gè)segment（有該表150萬條記錄）做一次group by l_partkey，采用了更高效的HashAggregate聚合方式。為了所有segment可以并行做join，會(huì)將lineitem表的數(shù)據(jù)做一次重分布（5萬條記錄），每個(gè)segment得到的是hash分布到自身的記錄。

可以看出，Mysql在聚合上的效率要明顯低于GreenPlum。
然后，子查詢結(jié)果會(huì)與現(xiàn)表做join操作，我們來繼續(xù)看下兩者在join上的區(qū)別：
Mysql：把子查詢結(jié)果作為臨時(shí)表（20萬條記錄）與現(xiàn)表lineitem(600萬條記錄）直接做了join，將產(chǎn)生600萬×20萬=1.2萬億的數(shù)據(jù)量.......

GreenPlum：首先對(duì)sql進(jìn)行了優(yōu)化，先執(zhí)行了where條件，減少了part表的數(shù)據(jù)到260條（單個(gè)segment的量，總量為4×260條，接下來的數(shù)據(jù)量都為單個(gè)segment的）。

采用了更高效的join方式hash join。
如果使用臨時(shí)表與lineitem表直接hash join，會(huì)產(chǎn)生50萬左右的數(shù)據(jù)量，但GreenPlum并沒有這么做，而是利用part表來進(jìn)行join，因?yàn)閜art表經(jīng)過where過濾后數(shù)據(jù)量非常小，和part表做hash join，數(shù)據(jù)量也相對(duì)較小?？偣沧隽藘纱蝖ash join：

• part表與臨時(shí)表part_agg，產(chǎn)生數(shù)據(jù)量246條；

• part表與lineitem表，產(chǎn)生數(shù)據(jù)量2598條；

兩者一對(duì)比，GreenPlum做join的數(shù)據(jù)量為(246+2598)×4=11376條，遠(yuǎn)小于Mysql的1.2萬億條，兩者的性能不言而喻。
綜上，在執(zhí)行Q17時(shí)，Mysql和GreenPlum的效率差別除了GreenPlum具有并行計(jì)算能力外，還體現(xiàn)在聚合和關(guān)聯(lián)這兩個(gè)操作的優(yōu)化上面。

到此，相信大家對(duì)“GreenPlum簡(jiǎn)單性能測(cè)試方法是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

網(wǎng)頁標(biāo)題：GreenPlum簡(jiǎn)單性能測(cè)試方法是什么
轉(zhuǎn)載源于：http://aaarwkj.com/article14/ispoge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、商城網(wǎng)站、網(wǎng)站營銷、建站公司、動(dòng)態(tài)網(wǎng)站、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)