【大数据之数据仓库】GreenPlum PK DeepGreen（TPCH）

1.背景

一张UML类图可以简单的说明GreenPlum和DeepGreen之间的关系：

GreenPlum：

• 主页：http://greenplum.org/
• 源码：开源，https://github.com/greenplum-db/gpdb，

DeepGreen：

• 主页：http://vitessedata.com/deepgreen-db
• 源码：不开源，安装包：http://vitessedata.com/deepgreen-db-download

DeepGreen官方宣传的优势：

事实是否如此呢？

2.测试

在10GB数据集下的测试结果如下：

 

DeepGreen比GreenPlum快，基本符合预期，至于快多少倍，我们暂不关心，毕竟10GB的容量对于数据仓库来讲太小了。

在
1TB数据集下的测试结果如下：

 

大部分sql都是DeepGreen比GreenPlum快，但是3、5、17都是GreenPlum快，
不符合预期！

3.分析

我在附件中贴上了第1和第3两个sql的explain以及DDL，大家感兴趣的话可以对比下，能发现一些有趣的东西：）

我们关心的是为什么DeepGreen会比GreenPlum慢！？我们以第3个sql来进行分析。

照着explain文件逐行分析比对数据总结成如下两个执行计划图，左边是GreenPlum的执行计划，右边是DeepGreen的执行计划：

 

整个执行计划扫描3张表，原始记录：lineitem表有5,999,989,709条记录，orders表有1,500,000,000条记录，customer表150,000,000条记录。

明显的，两个执行计划不一样，图中的数字是从explain文件中抽取出来的，表示的是每个节点执行完后的有效数据记录数量；每个执行计划的耗时主要集中在图中蓝色节点部分。

善于观察的同事应该已经看到右侧执行计划中的红色框框部分了:)

在custkey关联这个阶段：

左侧各节点的计算量：(149,630,385/72) x 29,998,152 = 2,078,199 x 29,998,152

右侧各节点的计算量：144,147,772 x (3,266,814,571/72) = 144,147,772 x 45,372,424

两个执行计划的关联计算任务不在一个量级，耗时也显而易见了，这就是为什么DeepGreen比GreenPlum执行慢的原因！而为什么DeepGreen会优化选择这个慢的方案，这就同他优化器的具体实现有关了。

附件：

attachment.zip

看这里：

《
【大数据之数据仓库】选型流水记
》

本文来自网易云社区，经作者何李夫授权发布。

原文地址：【大数据之数据仓库】GreenPlum PK DeepGreen（TPCH）

更多网易研发、产品、运营经验分享请访问网易云社区。