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在作数据传输的时间会远高于计算时间。