关于云服务:腾讯云数据库团队GreenPlum简单性能测试与分析续

作者介绍：黄辉，16年毕业于电子科技大学并退出腾讯。目前在腾讯云存储产品团队从事云数据库开发工作，喜爱钻研分布式数据库相干技术（如：分布式事务，高可用性等）。
浏览原文，更多技术干货，请拜访腾云阁。

之前对GreenPlum与Mysql进行了TPC-H类的比照测试，发现等同资源配比条件下，GreenPlum的性能远好于Mysql，有局部起因是得益于GreenPlum自身采纳了更高效的算法，比如说做多表join时，采纳的是hash join形式。如果采纳同样高效的算法，两者的性能又如何？因为GreenPlum是由PostgreSQL演变而来，齐全采纳了PostgreSQL的优化算法，这次，咱们将GreenPlum与PostgreSQL进行比照测试，在等同资源配比条件下，查看GreenPlum（分布式PostgreSQL）和单机版PostgreSQL的性能体现。

一.目标

比拟在等同资源条件下具备分布式属性的GreenPlum与PostgreSQL在进行TPC-H类测试的性能区别。
剖析和总结两种DB造成性能区别的起因。

二.测试环境与配置信息

测试环境：腾讯云
测试对象：GreenPlum、PostgreSQL，两者的配置信息统计如下：

表1 GreenPlum集群服务器

Master Host

Segment Host

操作系统

CentOS 6.7 64位

CPU

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

内存

8GB

公网带宽

100Mbps

123.207.228.40

123.207.228.21

Segment数量

版本

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

119.29.229.209

版本

PostgreSQL 9.5.4

三.测试后果与剖析

1.总测试数据量为1G时
后果统计信息如下：

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

表名称

数据条数

customer

150000

lineitem

6001215

nation

orders

1500000

part

200000

partsupp

800000

region

supplier

10000

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

执行的sql

GeenPlum执行工夫（单位：秒）

PostgreSQL执行工夫（单位：秒）

4.01

12.93

0.50

0.62

1.35

1.29

0.11

0.52

0.19

0.72

0.01

0.79

6.06

1.84

1.46

0.59

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

orders

15000000

part

2000000

partsupp

8000000

region

supplier

100000

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

执行的sql

GeenPlum执行工夫（单位：秒）

PostgreSQL执行工夫（单位：秒）

36.98

130.61

3.10

17.08

14.39

117.83

0.11

6.81

0.20

114.46

0.01

11.08

80.12

42.96

6.61

45.13

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.扫表。具体理解可看http://kb.cnblogs.com/page/515258/ ）。
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

orders

75000000

part

10000000

partsupp

40000000

region

supplier

500000

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

执行的sql

GeenPlum执行工夫（单位：秒）

PostgreSQL执行工夫（单位：秒）

212.27

802.24

16.53

164.20

156.31

2142.18

0.13

2934.76

0.23

2322.92

0.01

6439.26

535.66

11906.74

76.76

9171.83

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场景。

五.其余事项

因为原生的TPC-H的测试用例不间接反对GreenPlum和PostgreSQL，因而须要批改测试脚本，生成新的建表语句如附件中<附录一：建表语句> 所示，测试sql如<附录二：查问语句>。
GreenPlum的数据导入能够应用GreenPlum自带的gpfdist工具，搭建多个gpfdsit文件服务器并行导入，segment的个数最好是gpfdist服务器的倍数，因为seg是轮询连贯到gpfdist。

相干举荐

Greenplum 简略性能测试与剖析

浏览原文，更多技术干货，请拜访腾云阁。