Greenplum 简单性能测试与分析

如今,多样的交易模式以及大众消费观念的改变使得数据库应用领域不断扩大,现代的大型分布式应用系统的数据膨胀也对数据库的海量数据处理能力和并行处理能力提出了更高的要求,如何在数据呈现海量扩张的同时提高处理速度和应用系统的可用性,使客户能同时得到更高的处理速度、更高的数据可用性和更大的数据集,是数据库系统面临的一个挑战。

通过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,得到的结果如图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条;

八.其他事项

  1. 由于原生的TPC-H的测试用例不直接支持Greenplum和MySQL,因此需要修改测试脚本,生成新的建表语句如《附录一》所示,测试sql如《附录二》。
  2. Greenplum各节点间的带宽要尽可能大,一般查询中会涉及到广播或者重分布动作,需要在节点间传输数据,如果带宽过小,易在此造成性能瓶颈。
  3. 测试语句不要过于简单,并且测试数据量不要太少,否则Greenplum在做数据传输的时间会远高于计算时间。

更多数据库文章,请关注腾讯云数据库公众号: QcloudCDB

附件:

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏owent

Blog切换到Hugo

其实很早就想把Blog迁移到静态化的博客系统了。不过一直没花时间来搞,当然主要原因还是懒。

39310
来自专栏程序员的SOD蜜

求连续操作(登录)数量(次数)最大的记录(用户)

昨晚上老同事聚会,一个同事说道一个面试问题没有一个人做出来,就是求连续日期登录次数最大的用户,同事说借助 rownumber即可求解,由于是喝酒聊天,也没有说详...

50170
来自专栏CSDN技术头条

详解 NoSQL 数据库的分布式算法

系统的可扩展性是推动NoSQL运动发展的的主要理由,包含了分布式系统协调,故障转移,资源管理和许多其他特性。这么讲使得NoSQL听起来像是一个大筐,什么都能塞进...

24890
来自专栏杨建荣的学习笔记

海量数据迁移之分区表批量insert性能改进(r2笔记67天)

在平时的工作中接触到的分区表一般都比较大,而且分区也少则几十,多则几百,上千。 在数据迁移的时候,分区表的迁移更是块大骨头,因为数据量太大,而且有些分区表中还有...

22750
来自专栏沃趣科技

容器化RDS|调度策略

导 语 前文数据库容器化|未来已来我们介绍了基于Kubernetes实现的下一代私有 RDS。其中,调度策略是具体实现时至关重要的一环,它关系到RDS 集群的服...

532100
来自专栏LET

谈谈3D Tiles(1):渲染调度

51060
来自专栏杨建荣的学习笔记

海量数据迁移之通过shell估算数据量 (r2笔记93天)

在数据迁移的时候,需要根据用户量来评估需要在表空间理添加的空间大小。比如迁移5百万的用户和迁移200万,两者需要添加的数据量差别很大,在资源有限的情况下,需要一...

27120
来自专栏zhisheng

机器常见需要关注的监控指标

做运维,不怕出问题,怕的是出了问题,抓不到现场,两眼摸黑。所以,依靠强大的监控系统,收集尽可能多的指标,意义重大。但哪些指标才是有意义的呢,本着从实践中来的思想...

34010
来自专栏铭毅天下

干货 | Elasticsearch通用优化建议

Elasticsearch开发实战的后期会遇到性能问题,包括:创建索引性能、写入数据性能、检索性能等。网上有很多结合自己实际应用场景的相关优化建议,但“对症下药...

38220
来自专栏吉浦迅科技

放下王者农药这锅,玩一把Tensorflow吧

暑期开始了!对于Lady姐来说,如何安排儿子的暑期生活是一件大事,显然是不能沉迷于王者农药, ? 于是Lady姐随手扔了一个教程给他:按照这份教程,在家里Win...

410100

扫码关注云+社区

领取腾讯云代金券