Deepgreen与Greenplum TPC-H性能测试对比（使用德哥脚本）

Deepgreen数据库基于开源MPP数据库Greenplum而来，那么他的优越性几何？今天给大家分享数据仓库测试TPC-H的结果让大家加以比较：

本次对比需要注意的几点：

测试参照德哥2015年发的【Greenplum的TPC-H】测试，只做了压缩类型的简单修改
由于测试机器性能问题，可能无法最大化展示二者性能（greenplum部分测试timeout）

一、测试环境：

服务器         IP              节点
Master          192.168.100.107 1 Master
Segment1        192.168.100.108 2 instance
Segment2        192.168.100.109 2 instance
软件版本：
Greenplum 4.3.12
Deepgreen 16.16

二、TPC-H测试结果

Greenplum：

2017-05-19 13:59:16 [1495173556] : preparing TPC-H database
2017-05-19 13:59:16 [1495173556] :   loading data
2017-05-19 13:59:39 [1495173579] :   creating primary keys
2017-05-19 13:59:39 [1495173579] :   creating foreign keys
2017-05-19 13:59:39 [1495173579] :   creating indexes
2017-05-19 13:59:57 [1495173597] :   analyzing
2017-05-19 14:00:10 [1495173610] : running TPC-H benchmark
2017-05-19 14:00:10 [1495173610] : running queries defined in TPC-H benchmark
2017-05-19 14:00:10 [1495173610] :   running query 1
2017-05-19 14:00:21 [1495173621] :     query 1 finished OK (6 seconds)
2017-05-19 14:00:21 [1495173621] :   running query 2
2017-05-19 14:08:37 [1495174117] :     query 2 finished OK (250 seconds)
2017-05-19 14:08:37 [1495174117] :   running query 3
2017-05-19 14:53:15 [1495176795] :     query 3 finished OK (1363 seconds)
2017-05-19 14:53:15 [1495176795] :   running query 4
2017-05-19 14:53:17 [1495176797] :     query 4 finished OK (1 seconds)
2017-05-19 14:53:17 [1495176797] :   running query 5
2017-05-19 14:53:18 [1495176798] :     query 5 finished OK (1 seconds)
2017-05-19 14:53:18 [1495176798] :   running query 6
2017-05-19 14:53:19 [1495176799] :     query 6 finished OK (1 seconds)
2017-05-19 14:53:19 [1495176799] :   running query 7
2017-05-19 15:28:32 [1495178912] :     query 7 finished OK (1057 seconds)
2017-05-19 15:28:32 [1495178912] :   running query 8
2017-05-19 15:54:09 [1495180449] :     query 8 finished OK (777 seconds)
2017-05-19 15:54:09 [1495180449] :   running query 9
2017-05-19 21:52:26 [1495201946] :     killing query 9 (timeout)
2017-05-19 21:52:36 [1495201956] :   running query 10
2017-05-19 21:52:37 [1495201957] :     query 10 finished OK (1 seconds)
2017-05-19 21:52:37 [1495201957] :   running query 11
2017-05-19 21:55:26 [1495202126] :     query 11 finished OK (85 seconds)
2017-05-19 21:55:26 [1495202126] :   running query 12
2017-05-19 21:55:27 [1495202127] :     query 12 finished OK (1 seconds)
2017-05-19 21:55:27 [1495202127] :   running query 13
2017-05-20 00:45:29 [1495212329] :     killing query 13 (timeout)
2017-05-20 00:45:39 [1495212339] :   running query 14
2017-05-20 00:45:40 [1495212340] :     query 14 finished OK (1 seconds)
2017-05-20 00:45:40 [1495212340] :   running query 15
2017-05-20 00:45:42 [1495212342] :     query 15 finished OK (1 seconds)
2017-05-20 00:45:42 [1495212342] :   running query 16
2017-05-20 00:48:30 [1495212510] :     query 16 finished OK (84 seconds)
2017-05-20 00:48:30 [1495212510] :   running query 17
2017-05-20 00:48:46 [1495212526] :     query 17 finished OK (8 seconds)
2017-05-20 00:48:46 [1495212526] :   running query 18
2017-05-20 02:06:47 [1495217207] :     killing query 18 (timeout)
2017-05-20 02:06:58 [1495217218] :   running query 19
2017-05-20 07:11:50 [1495235510] :     killing query 19 (timeout)
2017-05-20 07:12:00 [1495235520] :   running query 20
2017-05-20 07:12:02 [1495235522] :     query 20 finished OK (1 seconds)
2017-05-20 07:12:02 [1495235522] :   running query 21
2017-05-20 09:57:36 [1495245456] :     killing query 21 (timeout)
2017-05-20 09:57:46 [1495245466] :   running query 22
2017-05-20 10:12:01 [1495246321] :     query 22 finished OK (428 seconds)
2017-05-20 10:12:01 [1495246321] : finished TPC-H benchmark

Deepgreen：

[dgadmin@linux1 results]$ cat bench.log
2017-05-19 11:44:56 [1495165496] : preparing TPC-H database
2017-05-19 11:44:56 [1495165496] :   loading data
2017-05-19 11:45:14 [1495165514] :   creating primary keys
2017-05-19 11:45:14 [1495165514] :   creating foreign keys
2017-05-19 11:45:14 [1495165514] :   creating indexes
2017-05-19 11:45:29 [1495165529] :   analyzing
2017-05-19 11:45:32 [1495165532] : running TPC-H benchmark
2017-05-19 11:45:32 [1495165532] : running queries defined in TPC-H benchmark
2017-05-19 11:45:32 [1495165532] :   running query 1
2017-05-19 11:45:40 [1495165540] :     query 1 finished OK (4 seconds)
2017-05-19 11:45:40 [1495165540] :   running query 2
2017-05-19 11:52:23 [1495165943] :     query 2 finished OK (199 seconds)
2017-05-19 11:52:23 [1495165943] :   running query 3
2017-05-19 11:52:27 [1495165947] :     query 3 finished OK (3 seconds)
2017-05-19 11:52:27 [1495165947] :   running query 4
2017-05-19 11:52:28 [1495165948] :     query 4 finished OK (1 seconds)
2017-05-19 11:52:28 [1495165948] :   running query 5
2017-05-19 11:52:29 [1495165949] :     query 5 finished OK (1 seconds)
2017-05-19 11:52:29 [1495165949] :   running query 6
2017-05-19 11:52:30 [1495165950] :     query 6 finished OK (1 seconds)
2017-05-19 11:52:30 [1495165950] :   running query 7
2017-05-19 11:52:34 [1495165954] :     query 7 finished OK (3 seconds)
2017-05-19 11:52:34 [1495165954] :   running query 8
2017-05-19 11:52:36 [1495165956] :     query 8 finished OK (1 seconds)
2017-05-19 11:52:36 [1495165956] :   running query 9
2017-05-19 12:26:01 [1495167961] :     query 9 finished OK (1002 seconds)
2017-05-19 12:26:01 [1495167961] :   running query 10
2017-05-19 12:26:02 [1495167962] :     query 10 finished OK (1 seconds)
2017-05-19 12:26:02 [1495167962] :   running query 11
2017-05-19 12:26:05 [1495167965] :     query 11 finished OK (3 seconds)
2017-05-19 12:26:05 [1495167965] :   running query 12
2017-05-19 12:26:07 [1495167967] :     query 12 finished OK (1 seconds)
2017-05-19 12:26:07 [1495167967] :   running query 13
2017-05-19 12:45:19 [1495169119] :     query 13 finished OK (588 seconds)
2017-05-19 12:45:19 [1495169119] :   running query 14
2017-05-19 12:45:20 [1495169120] :     query 14 finished OK (1 seconds)
2017-05-19 12:45:20 [1495169120] :   running query 15
2017-05-19 12:45:21 [1495169121] :     query 15 finished OK (1 seconds)
2017-05-19 12:45:21 [1495169121] :   running query 16
2017-05-19 12:45:25 [1495169125] :     query 16 finished OK (3 seconds)
2017-05-19 12:45:25 [1495169125] :   running query 17
2017-05-19 12:45:30 [1495169130] :     query 17 finished OK (3 seconds)
2017-05-19 12:45:30 [1495169130] :   running query 18
2017-05-19 12:45:32 [1495169132] :     query 18 finished OK (1 seconds)
2017-05-19 12:45:32 [1495169132] :   running query 19
2017-05-19 12:45:34 [1495169134] :     query 19 finished OK (1 seconds)
2017-05-19 12:45:34 [1495169134] :   running query 20
2017-05-19 12:45:35 [1495169135] :     query 20 finished OK (1 seconds)
2017-05-19 12:45:35 [1495169135] :   running query 21
2017-05-19 12:45:36 [1495169136] :     query 21 finished OK (1 seconds)
2017-05-19 12:45:36 [1495169136] :   running query 22
2017-05-19 12:57:30 [1495169850] :     query 22 finished OK (357 seconds)
2017-05-19 12:57:30 [1495169850] : finished TPC-H benchmark

三、结果对比

总的来说，Deepgreen在整个测试中整体优于Greenplum。在22轮测试中，有8轮持平，其余14轮Deepgreen均优于Greenplum。其中Q3、Q7、Q8、Q11、Q16查询比Greenplum快指数倍；Greenplum的Q9、Q13、Q18、Q19、Q21 timeout，而Deepgreen没有；Q4、Q5、Q6、Q10、Q12、Q14、Q15、Q20二者持平。

时间： 2024-08-31 14:26:49

Deepgreen与Greenplum TPC-H性能测试对比（使用德哥脚本）的相关文章

Deepgreen与Greenplum TPC-H性能测试对比（使用VitesseData脚本）

前两天发了一篇基于[德哥测试脚本]的测试对比文章<Deepgreen与Greenplum TPC-H性能测试对比(使用德哥脚本)>,由于测试数据量少,两个数据库有几轮测试都是1秒持平,但是大多数测试Deepgreen均优于Greenplum,有的甚至快至百倍,感兴趣的朋友可以再回头看看. 今天分享一下Deepgreen提供的TPC-H测试脚本,这个脚本分为浮点类型.数值类型两类进行22轮测试,更加细化,并且结果值更加中肯. 一.测试环境服务器 IP 节点 Master 192.168.100

cglib相关性能测试对比

背景: 继上一篇文章 cglib源码学习交流很多同学提出,因中文文档缺乏,导致对文章中的介绍看的不是很明白,更多的只是想了解具体的使用即可.所以趁势写了这篇博文,主要是将cglib中的几个工具类和常用的Reflect ,BeanUtils做一个对比,顺便也介绍一下cglib的相关用法,一举两得,望大家多多支持. 正题: 1. 首先定义一份Pojo Bean ,后续的测试主要围绕这个进行. 1.public static class CopyBean { 2. 3. private

Windows Server 2008 R2和SP2性能测试对比

之所以去安装SP1,是因为我的电脑有16G内存,虽然安装的是Windows 7 x64版本,但是每当内存使用超过了4G,鼠标反应就会很迟钝,很卡.尤其是在同时运行FLASH PRO 和 PHOTOSHOP . ECLIPSE的时候. 很郁闷,所以想安装SP1试试效果,测试结果虽然有了一点提升,但是问题依旧. 该卡还是卡,内存使用不能超过4G,超过就卡,完全浪费了我16G内存的配置.于是昨天晚上挨个尝试了WINDOWS 2008 R2 和 WINDOWS 2008 SP2. 经过测试,最终选择了

Deepgreen DB 是什么？

Deepgreen DB 全称 Vitesse Deepgreen DB,它是一个可扩展的大规模并行(通常称为MPP)数据仓库解决方案,起源于开源数据仓库项目Greenplum DB(通常称为GP或GPDB).所以已经熟悉了GP的朋友,可以无缝切换到Deepgreen. 它几乎拥有GP的所有功能,在保有GP所有优势的基础上,Deepgreen对原查询处理引擎进行了优化,新一代查询处理引擎扩展了: 优越的连接和聚合算法新的溢出处理子系统基于JIT的查询优化.矢量扫描和数据路径优化下面简单介绍

Deepgreen & Greenplum DBA小白普及课之一（一般问题解答）

不积跬步无以至千里,要想成为一名合格的数据库管理员,首先应该具备扎实的基础知识及问题处理能力.本文参考Pivotal官方FAQ,对一些在使用和管理Deepgreen & Greenplum时经常会遇到的普通问题进行解答.希望对大家有所帮助,如果有朋友有更多的问题分享,请留言,我将一并整理. 下面单刀直入,开始问题浏览及解决思路梳理: 1.如何检查一张表的分区策略? 测试表:region 表的详细描述信息可以展示其分区策略:Distributed by: (r_regionkey) tpch=#

Deepgreen & Greenplum DBA小白普及课之二（管理问题解答）

不积跬步无以至千里,要想成为一名合格的数据库管理员,首先应该具备扎实的基础知识及问题处理能力.本文参考Pivotal官方FAQ,对在管理Deepgreen & Greenplum时经常会遇到的问题提出解决思路/答案.希望对大家有所帮助,如果有朋友有更多的问题分享,请留言,我将一并整理. 下面单刀直入,开始问题浏览及解决思路梳理: 1.执行gpstart命令失败了,我该怎么办? 查看gpstart命令在Master执行失败后返回的错误原因: 检查gpstart的启动日志,这里可能存着更详细的信息,

Deepgreen & Greenplum DBA小白普及课之三（备份问题解答）

不积跬步无以至千里,要想成为一名合格的数据库管理员,首先应该具备扎实的基础知识及问题处理能力.本文参考Pivotal官方FAQ,对在管理Deepgreen & Greenplum时经常会遇到的问题提出解决思路/答案,本篇主要讲备份方面的问题.希望对大家有所帮助,如果有朋友有更多的问题分享,请留言,我将一并整理. 1.简单描述一下Deepgreen & Greenplum的备份架构? 当我们执行全库备份操作时,后台进行了如下操作: 检查备份命令语法检查备份目录是否存在,如果不存在便创建目录

Deepgreen & Greenplum 高可用（一） - Segment节点故障转移

尚书中云:惟事事,乃其有备,有备无患.这教导我们做事一定要有准备,做事尚且如此,在企事业单位发展中处于基础地位的数据仓库软件在运行过程中,何尝不需要有备无患呢? 今天别的不表,主要来谈谈企业级数据仓库软件Deepgreen和Greenplum的高可用特性之一:计算节点镜像. 一.首先从理论上来讲,正常Segment节点和他的Mirror是分布在不同主机上的,以防止单点故障导致的数据库访问异常.当正常Segment节点出现故障时,Mirror节点可以自动接管Segment节点的服务,数据库仍然可以

谈谈Deepgreen(Greenplum)中文编码

很多国内客户对中文编码要求比较苛刻,今天我们来聊聊中文编码问题. 概念 Deepgreen和Greenplum是基于PostgreSQL 8.2版本. PostgreSQL 8.2能够以各种字符集存储文本,比如 ISO-8859 系列和 EUC(扩展 Unix 编码).UTF-8 .Mule 国际编码.缺省的字符集是在使用 initdb 初始化数据库集群的时候选择的.在你创建数据库的时候是可以覆盖这个缺省的.因此,你可以有多个数据库,每个都有不同的字符集. PostgreSQL 8.2只支持以U