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

5次阅读

共计 5331 个字符，预计需要花费 14 分钟才能阅读完成。

作者介绍：黄辉，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

IP

123.207.228.40

123.207.228.21

Segment 数量

0

2

版本

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. 扫表。具体理解可看 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

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

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

Greenplum 简略性能测试与剖析