GreenPlum 简单性能测试与分析(续)

作者介绍:黄辉,16年毕业于电子科技大学并加入腾讯。目前在腾讯云存储产品团队从事云数据库开发工作,喜欢研究分布式数据库相关技术(如:分布式事务,高可用性等)。

之前对 GreenPlum 与 Mysql 进行了 TPC-H 类的对比测试,发现同等资源配比条件下,GreenPlum 的性能远好于 Mysql ,有部分原因是得益于 GreenPlum 本身采用了更高效的算法,比如说做多表 join 时,采用的是 hash join 方式。如果采用同样高效的算法,两者的性能又如何?由于 GreenPlum 是由 PostgreSQL 演变而来,完全采用了 PostgreSQL 的优化算法,这次,我们将 GreenPlum 与 PostgreSQL 进行对比测试,在同等资源配比条件下,查看 GreenPlum (分布式 PostgreSQL )和单机版 PostgreSQL 的性能表现。

一.目的

  1. 比较在同等资源条件下具有分布式属性的 GreenPlum 与 PostgreSQ L在进行 TPC-H 类测试的性能区别。
  2. 分析和总结两种 DB 造成性能区别的原因。

二.测试环境与配置信息

测试环境:腾讯云

测试对象:GreenPlum、PostgreSQL,两者的配置信息统计如下:

表1 GreenPlum集群服务器

Master Host

Segment Host

Segment Host

操作系统

CentOS 6.7 64位

CentOS 6.7 64位

CentOS 6.7 64位

CPU

Intel(R) Xeon(R) CPU E5-26xx v3 2核

Intel(R) Xeon(R) CPU E5-26xx v3 2核

Intel(R) Xeon(R) CPU E5-26xx v3 2核

内存

8GB

8GB

8GB

公网带宽

100Mbps

100Mbps

100Mbps

IP

123.207.228.40

123.207.228.21

123.207.85.105

Segment数量

0

2

2

版本

greenplum-db-4.3.8.1-build-1-RHEL5-x86_64

greenplum-db-4.3.8.1-build-1-RHEL5-x86_64

greenplum-db-4.3.8.1-build-1-RHEL5-x86_64

表2 PostgreSQL服务器

指标

参数

操作系统

CentOS 6.7 64位

cpu

Intel(R) Xeon(R) CPU E5-26xx v3 8核

内存

24GB

公网带宽

100Mbps

IP

119.29.229.209

版本

PostgreSQL 9.5.4

三.测试结果与分析

1.总测试数据量为1G时

结果统计信息如下:

表3 总量为1GB时各测试表数据量统计

表名称

数据条数

customer

150000

lineitem

6001215

nation

25

orders

1500000

part

200000

partsupp

800000

region

5

supplier

10000

表4 总量为1GB时22条sql执行时间统计

执行的sql

GeenPlum执行时间(单位:秒)

PostgreSQL执行时间(单位:秒)

Q1

4.01

12.93

Q2

0.50

0.62

Q3

1.35

1.29

Q4

0.11

0.52

Q5

0.19

0.72

Q6

0.01

0.79

Q7

6.06

1.84

Q8

1.46

0.59

Q9

4.00

7.04

Q10

0.14

2.19

Q11

0.30

0.18

Q12

0.08

2.15

Q13

1.04

4.05

Q14

0.04

0.42

Q15

0.07

1.66

Q16

0.51

0.80

Q17

3.21

23.07

Q18

14.23

5.86

Q19

0.95

0.17

Q20

0.16

3.10

Q21

7.23

2.22

Q22

0.96

0.28

分析:从以上的表4可以看出,PostgreSQL 在22条 sql 中有8条 sql 的执行时间比 GreenPlum 少,接近一半的比例,我们直接放大10倍的测试数据量进行下一步测试。

2.总测试数据量为10G时

结果统计如下:

表5 总量为10GB时各测试表数据量统计

表名称

数据条数

customer

1500000

lineitem

59986052

nation

25

orders

15000000

part

2000000

partsupp

8000000

region

5

supplier

100000

表6 总量为10GB时22条sql执行时间统计

执行的sql

GeenPlum执行时间(单位:秒)

PostgreSQL执行时间(单位:秒)

Q1

36.98

130.61

Q2

3.10

17.08

Q3

14.39

117.83

Q4

0.11

6.81

Q5

0.20

114.46

Q6

0.01

11.08

Q7

80.12

42.96

Q8

6.61

45.13

Q9

49.72

118.36

Q10

0.16

40.51

Q11

2.28

3.06

Q12

0.08

21.47

Q13

19.29

68.83

Q14

0.05

36.28

Q15

0.09

23.16

Q16

6.30

12.77

Q17

134.22

127.79

Q18

168.03

199.48

Q19

6.25

1.96

Q20

0.54

52.10

Q21

84.68

190.59

Q22

17.93

2.98

分析:放大数据量到10G后可以明显看出,PostgreSQL 执行测试 sql 的时间大幅度增多,性能下降比较厉害,但仍有3条测试 sql 快于 GreenPlum ,我们选取其中一条对比查看下两者的性能区别原因。

这里我们以 Q7 为例,Greenplum 的执行时间大约是 PostgreSQL 的两倍,Q7 如下:

图1 Q7表示的sql语句

在PostgreSQL上执行explain Q7,得到结果如下(如果看不清楚可以右键另存为图片查看):

图2 数据量为10G时PostgreSQL上执行explain Q7的结果

对执行进行分析,可以看出,整个过程最耗时的部分如上图红色框部分标识,对应的条件查询操作分别是:

1).在lineitem表上对l_shipdata字段按条件查询,因为在字段有索引,采用了高效的Bitmap索引查询(Bitmap索引查询分两步:1.建位图;2.扫表。详细了解可看Bitmap的秘密)。

2).lineitem和orders表hash join操作。

为了方便进一步分析,我们加上analyze参数,获取详细的执行时间,由于内容过多,这里只截取部分重要信息如下:

图3 数据量为10G时PostgreSQL上执行explain analyze Q7的部分结果

根据以上信息,我们可以得出这两部分操作的具体执行时间,但由于PostgreSQL采取多任务并行,因此,我们需要对每步操作计算出一个滞留时间(该时间段内系统只执行该步操作),缩短滞留时间可直接提升执行速度,每步的滞留时间为前步的结束时间与该步结束时间之差。两部分的滞留时间分别为:

1).Bitmap Heap Scan:20197-2233=17964ms

2).Hash join:42889-26200=16689ms

PostgreSQL执行Q7的总时间为42963ms,因此,可以印证系统的耗时主要集中在上述两步操作上。

接下来,我们在GreenPlum上执行explain Q7,结果如下:

图4 数据量为10G时GreenPlum上执行explain Q7的结果

与PostgreSQL不同的是,GreenPlum的耗时多了数据重分布部分。同样,我们通过analyze参数得到详细的执行时间如下:

图5 数据量为10G时GreenPlum上执行explain analyze Q7的部分结果

根据执行计划信息,选出耗时最长的三步操作,计算出在一个segment(耗时最长的)上这三部分的滞留时间为:

1).Scan lineitem: 6216ms

2).Redistribute: 36273ms

3).Hash join: 29885ms

GreenPlum执行Q7的总时间为80121ms,可见数据重分布的时间占据了整个执行时间的一半,进行Hash join操作的时间占比也较多,主要是segment的内存不足,引起了磁盘的IO。

小结:对比PostgreSQL和GreenPlum在Q7的执行计划,GreenPlum的耗时较多的原因主要是数据重分布的大量时间消耗和hash join时超出内存引起磁盘IO。虽然GreenPlum各segment并行扫lineitem表节省了时间,但占比较小,对总时间的消耗影响较小。

基于此,是否可以减少数据重分布操作的耗时占比?我们尝试进一步增加测试的数据量,比较10G的测试数据对于真实的OLAP场景还是过少,扩大5倍的测试量,继续查看耗时情况是否有所改变。

3. 总测试数据量为50G时

表7 总量为50GB时各测试表数据量统计

表名称

数据条数

customer

7500000

lineitem

300005811

nation

25

orders

75000000

part

10000000

partsupp

40000000

region

5

supplier

500000

表8 总量为50GB时22条sql执行时间统计

执行的sql

GeenPlum执行时间(单位:秒)

PostgreSQL执行时间(单位:秒)

Q1

212.27

802.24

Q2

16.53

164.20

Q3

156.31

2142.18

Q4

0.13

2934.76

Q5

0.23

2322.92

Q6

0.01

6439.26

Q7

535.66

11906.74

Q8

76.76

9171.83

Q9

313.91

26060.36

Q10

0.41

1905.13

Q11

7.71

17.65

Q12

0.19

3948.07

Q13

108.05

354.59

Q14

0.05

8054.72

Q15

0.07

2036.03

Q16

34.74

221.49

Q17

862.90

9010.56

Q18

913.97

3174.24

Q19

129.14

8666.38

Q20

2.28

9389.21

Q21

1064.67

26868.31

Q22

90.90

1066.44

分析:从结果表可明显看出,在22条SQL中,GreenPlum的执行效率都比PostgreSQL高出很多,我们还是以Q7为例,查看两种数据量下执行效率不一致的直接原因。

经过对执行计划的分析,发现区别还是集中在步骤2提到的几个部分,这里就不再重复给出整体的查询计划,直接查看耗时较多的部分如下:

图6 数据量为50G时PostgreSQL上执行explain analyze Q7的部分结果

图7 数据量为50G时GreenPlum上执行explain analyze Q7的部分结果

PostgreSQL的主要滞留时间有:

1).Bitmap Heap Scan: 9290197ms

2).Hash join: 713138ms

总执行时间为10219009ms,可见主要的耗时集中在Bitmap Heap Scan上

GreenPlum的主要滞留时间有:

1).Scan lineitem: 130397ms

2).Redistribute: 140685ms

3).Hash join: 211456ms

总的执行时间为537134ms,相比步骤2的10G测试数据量,数据重分布的耗时占比明显下降,主要耗时已集中在hash join操作上。

GreenPlum和PostgreSQL在执行同样的wheret条件时,扫表的方式不一样,原因在于GreenPlum里的lineitem表为列存储,直接扫表更方便更快。

对比PostgreSQL两次的测试结果,发现Bitmao Heap Scan操作的性能下降比较明显,第一次扫18188314 行用时17秒,而第二次扫90522811行用时9190秒。

小结:增大数据量,会减少数据重分布耗时对整体执行时间的影响比重,主要耗时集中在内部数据的计算上。由于扫表涉及到磁盘IO,GreenPlum将扫表任务分割给多个segment同时进行,减少了单个节点要执行的扫表量,相当于并行IO操作,对整体的性能提升较大。

四.总结

通过对不同数据量(1G,10G,50G)的测试对比以及分析,可以看出,在 TPC-H 类的测试时,数据量越大, GreenPlum 性能越好于单机版的 PostgreSQL 。由于 GreenPlum 采用分布式架构,为了实现各节点并行计算能力,需要在节点间进行广播或者数据重分布,对整体的性能有一定影响,当数据量较小时,计算量小,广播或者重分布耗时占总耗时比例大,影响整体的执行效率,可能会出现 GreenPlum 不如单机版 PostgreSQL 效率高;当数据量较大时,整体计算的量很大,广播或者重分布耗时不再是影响性能的关键因素,分布式属性的GreenPlum在关于复杂语句执行查询效率较高,原因在于,一是多节点同时进行计算(hash join、sort等),提升计算速度,且可以充分利用系统 CPU 资源;二是扫表时,将任务分派到多节点,减少了单个节点的 IO 次数,达到并行 IO 的目的,更适用于 OLAP 场景。

五.其他事项

  1. 由于原生的TPC-H的测试用例不直接支持GreenPlum和PostgreSQL,因此需要修改测试脚本,生成新的建表语句如附件中<附录一:建表语句> 所示,测试sql如<附录二:查询语句>。
  2. GreenPlum的数据导入可以使用GreenPlum自带的gpfdist工具,搭建多个gpfdsit文件服务器并行导入,segment的个数最好是gpfdist服务器的倍数,因为seg是轮询连接到gpfdist。

附件:

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏智慧教育

以语音评测的PC端demo代码为例,讲解口语评测如何实现

腾讯云智聆口语评测(英文版)(Smart Oral Evaluation-English,SOE-E)是腾讯云推出的语音评测产品,是基于英语口语类教育培训场景和...

1K30
来自专栏SDNLAB

数据中心内负载均衡-ECMP的使用分析

数据中心的网络拓扑通常采用CLOS结构,主机之间常存在多条路径。数据中心为满足吞吐量敏感型流量的需求会提供大量的带宽资源。那么利用数据中心这种网络拓扑已知,路径...

68260
来自专栏java一日一条

干货!如何正确使用Git Flow

我们已经从SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用。

17240
来自专栏Android干货园

Reading:一款不错的Material Desgin风格的Kotlin版本的开源APP

版权声明:本文为博主原创文章,转载请标明出处。 https://blog.csdn.net/lyhhj/article/details/81...

14630
来自专栏玄魂工作室

Python黑帽编程3.0 第三章 网络接口层攻击基础知识

首先还是要提醒各位同学,在学习本章之前,请认真的学习TCP/IP体系结构的相关知识,本系列教程在这方面只会浅尝辄止。 本节简单概述下OSI七层模型和TCP/I...

33680
来自专栏磨磨谈

Ceph实现数据的'不拆分'

之前看过一个朋友一篇文章,讲述的是Vsan为什么使用的是两副本,而ceph则大多数情况下需要三副本,当时个人观点是这个并不是关键点,但是在仔细考虑了问题的出发点...

8720
来自专栏pangguoming

AngularJS 中文资料+工具+库+Demo 大搜集

中文学习资料: 中文资料且成系统的就这么多,优酷上有个中文视频。 http://www.cnblogs.com/lcllao/archive/2012/10/1...

39060
来自专栏IMWeb前端团队

[flash相关]crossBridge生成的库文件体积优化

本文作者:IMWeb 黄龙 原文出处:IMWeb社区 未经同意,禁止转载 不明白crossBridge是什么的可以看下这里 http://imweb....

22860
来自专栏FreeBuf

藏匿在邮件里的“坏小子”

不知从什么时候开始,我的垃圾邮件开始暴增,而且主题千奇百怪,有“再也不用去澳门赌博”、“免保人、免抵押”…等推广主题;有“南北方压岁钱差距有多大?”、“爱过才知...

15980
来自专栏IT派

Django | CoolBlog开发笔记第1课:项目分析

CoolBlog开发笔记第1课:项目分析 首先说一下CoolBlog开发笔记是我制作的《Django实战项目》系列教程基础篇的内容,使用Django来开发一个...

40940

扫码关注云+社区

领取腾讯云代金券