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集群服务器

表2 PostgreSQL服务器

三.测试结果与分析

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

结果统计信息如下：

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

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

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

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

结果统计如下：

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

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

分析：放大数据量到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时各测试表数据量统计

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

分析：从结果表可明显看出，在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。

附件：