共计 4213 个字符，预计需要花费 11 分钟才能阅读完成。
本篇内容主要讲解“GreenPlum 简单性能测试方法是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“GreenPlum 简单性能测试方法是什么”吧!
一.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 位 cpuIntel(R) Xeon(R) CPU E5-26xx v3 8 核内存 24GB 公网带宽 100MbpsIP123.207.228.51 版本 MySql5.6
表 2 Mysql 服务器
四. 测试数据量统计表名称数据条数 customer150000lineitem6001215nation25orders1500000part200000partsupp800000region5supplier10000
表 3 各测试表数据量统计
五. 执行时间统计执行的 sqlGeenPlum 执行时间（单位：秒）Mysql 执行时间（单位：秒）Q14.0112.66Q20.503.27Q31.355.06Q40.110.01Q50.1927.29Q60.012.50Q76.0610.79Q81.4639.78Q94.00 12 小时 Q100.144.74Q110.307.90Q120.082.35Q131.04 12 小时 Q140.049.37Q150.074.76Q160.512.90Q173.2148697.95Q1814.23 12 小时 Q190.9523.12Q200.16 12 小时 Q217.23 12 小时 Q220.968540.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 上的执行步骤主要有：
在所有 segment（这里为 4 个）同时进行条件查询 Filter；
两表做关联时，会进行数据广播，每个 segment 将查询到的结果广播到其他所有 segment，每个 segment 得到该表 Filter 后的所有结果（全量数据），后会进行一次 hash；
在所有 segment 上同时做 hash join，因为还要和其他表做 join，会继续将结果广播到所有 segment 上；
进行 group by 聚合操作。首先在所有 segment 上根据 group by 条件进行一次 HashAggregate 聚合（目的是减少重分布的数据量），然后将结果数据按 group by 字段进行重分布，最后，每个 segment 再按条件聚合一次得到最终结果；
根据 order by 条件，在所有 segment 上同时进行 sort，根据 Limit 条件选取数据，这里是 Limit 10，每个 segment 都选取 10 条数据汇总到 master 上，由 master 再选取前 10 条；
进行 Merge，所有 segment 将结果发给 master，由 master 进行一次归并，根据 Limit 条件选取结果的前 10 条数据，返回。
整个过程耗时的点主要有：
做了两次广播，总量为（30178+144314=174492）17 万条；
根据 group by 的条件 Redistribute 一次，数量约为 8 万条；
hash join 两次，都是在两个表之间进行的 hash join，在单个 segment 上，两表之间的 hash join 量分别大约是 18 万与 3 万、84 万与 14 万；
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 条；
两者一对比，GreenPlum 做 join 的数据量为 (246+2598)×4=11376 条，远小于 Mysql 的 1.2 万亿条，两者的性能不言而喻。
综上，在执行 Q17 时，Mysql 和 GreenPlum 的效率差别除了 GreenPlum 具有并行计算能力外，还体现在聚合和关联这两个操作的优化上面。
到此，相信大家对“GreenPlum 简单性能测试方法是什么”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
