自己慢慢积累。
分类: Mysql/postgreSQL
2016-02-03 15:05:31
测试项目 |
Oracle11G |
GreenPlum Master 节点 |
GreenPlum Segment 4节点 |
GreenPlum Segment 8节点 |
主机节点数 |
2 |
2 |
4 |
8 |
CPU |
2*4 intel 2.83GHz |
2*6 intel 3.0GHZ |
2*6 intel 2.93GHZ |
2*6 intel 2.93GHZ |
内存 |
16G |
|
|
|
磁盘 |
146G*2(Raid1) SAS 10K |
6*300GB SAS(Raid5) |
12*600GB SAS(Raid5) |
12*600GB SAS(Raid5) |
存储 |
DELL MD3200 6Gbps SAS 36*2T(2Hotspace) 2T*8+10T( Raid5) |
N/A |
N/A |
N/A |
网络 |
2*1Gb千兆网口 |
4*1 Gb千兆网口 2*1 10GB 万兆网口 |
2*1 Gb 千兆网口 2*1 10GB 万兆网口 |
2*1 Gb 千兆网口 2*1 10GB 万兆网口 |
交换机 |
3560千兆交换机 |
万兆交换机2台,千兆交换机1台 |
|
Oracle |
Green Plum |
操作系统&版本 |
Oracle Linux5.6 |
Linux5.5 |
数据库&版本 |
Oracle 11g 11.2.0.2.0 |
Greenplum-db-4.1.1.3 |
测试项目 |
具体项目 |
Oracle 11G |
GreenPlum 4节点 |
GreenPlum 8节点 |
Copy VS SQL loader |
6400万 |
900秒 |
N/A |
N/A |
外部表 VS 外部表 |
6400万 |
N/A |
63秒 |
50秒 |
6400万*3 |
N/A |
130秒 |
76秒 |
|
Insert方式VS Insert方式 |
6400万 |
1800~9000秒 |
|
|
6400万*4 |
N/A |
74秒 |
39秒 |
|
6400万*8 |
N/A |
360秒 |
90秒 |
|
6400万*16 |
N/A |
356秒 |
209秒 |
从4节点与8节点的加载性能来看,性能和节点数量基本呈线性关系。
Green Plum与Oracle相比,数据加载的性能提高20倍~100倍不等。
标准查询语句性能测试
测试项目 |
具体项目 |
Oracle 11G |
GreenPlum 4节点 |
GreenPlum 8节点 |
单分区分组 (参见相关语句) |
Select |
120秒 |
—— |
40 |
CTAS |
33秒 |
17.5秒 |
12秒 |
|
Insert |
—— |
11.9秒 |
5.3秒 |
|
八分区分组 (参见相关语句) |
Select |
500秒 |
—— |
77.6秒 |
CTAS |
232秒 |
—— |
—— |
|
Insert |
—— |
—— |
40.5秒 |
|
三十个分区分组 (参见相关语句) |
CTAS |
—— |
—— |
207.3秒 |
单分区与八个分区分组统计 (参见相关语句) |
Select |
437秒 |
67.1秒 |
56.1秒 |
CTAS |
—— |
35.8秒 |
27.7秒 |
|
Insert |
—— |
32.4秒 |
21.9秒 |
|
单分区与三十个分区分组统计 (参见相关语句) |
Select |
—— |
230.0秒 |
—— |
IP查询语句性能测试
测试项目 |
Oracle 11G |
GreenPlum 4节点 |
GreenPlum 8节点 |
IP范围查询—by 转换后 (参见相关语句) |
约1800秒 |
—— |
约2537秒 |
IP范围查询—by函数 (参见相关语句) |
约18000秒 |
—— |
约36000秒 |
IP查询 (参见相关语句) |
—— |
21秒 |
32~98秒 |
从以上的测试数据来看,大批量的数据处理,都能够在所期望的时间内以很短的时间完成执行。通过4个节点与8个节点响应的SQL测试时间的比较来看,性能与节点数量基本上呈线性关系。
GreenPlum与Oracle相比,数据查询的性能提高3倍~20倍不等。(Oracle的测试结果已做过优化,GP则为无索引状态)
基于IP范围查询的结果见补充说明
对于IP范围查询(包括数字和函数比较),Green Plum和Oracle的执行性能均一般,GreenPlum还要更差一些。
为了解决这个性能问题,Green Plum对IP表做了特殊处理,即把10999行的IP表拆分成1亿多条的IP明细表,采用等关联处理,即避开nestloop方式的join而使用更为快速的hash join。修正效果显著,相同的数据关联从之前的约2500秒的处理时间降低到约20秒,有了100倍左右的提升。
测试项目 |
Oracle 11G |
GreenPlum 4节点 |
GreenPlum 8节点 |
Update(30个分区) |
—— |
—— |
130.7秒 |
Delete |
—— |
—— |
12秒 |
对于大批量数据的更新和删除,Green Plum的优势更加明显,Oracle还需要加以特殊处理(即分段处理)才能进行更新和删除。
Green Plum的Update有个小问题,批量增加字段会导致整个表的大小翻倍,可以通过表的在线分析进行压缩。