本文主要是介绍Postgresql集群解决方案测试报告,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
1 测试主体
本次测试的主体有3个,分别为:
- GreenPlum集群,下文简称为GP
- Postgres-XC集群,下文简称为XC
- Postgresql单数据库实例,下文简称为pgsql
GP和XC都选用目前在互联网上可以下载到的最新版本。不同集群所基于的postgresql数据库版本不同,并且,postgis的版本也不相同。版本说明见下表:
测试主体 | 版本 | Postgresql版本 | Postgis版本 |
GP | 4.3.8.2 | 8.2.15 | 2.0 |
XC | 1.0.4 | 9.1.13 | 2.1 |
pgsql | 9.1.13 | 9.1.13 | 2.1 |
所有的环境均搭建在7层机房6台(编号1-6)1U的服务器上,各台服务器的配置如下:
参数项 | 配置 |
CPU | 32核 |
内存 | 64G |
磁盘 | 4块7200转SATA,未做RAID |
网络 | 4块千兆网卡,1和2作MODE=2的绑定,3和4各连一个交换机,各组一个局域网 |
GP集群采用1个master(运行在编号1的服务器/dev/sda上),6个segment host(对应编号1-6的服务器)的组织方式,每个segment host启动3个实例,分别位于不同的物理磁盘上(/dev/sdb 、/dev/sdc 、/dev/sdd)。
XC集群采用1个gtm(运行在编号1的服务器上),1个gtm_standy(运行在编号1的服务器上),4个gtm_proxy(对应编号3-6的服务器),4个coordinator(对应编号3-6的服务器),4个datanode(对应编号3-6的服务器)的组织方式。coordinator运行于/dev/sda,datanode运行于/dev/sdb。
Pgsql采用XC集群中编号3服务器上运行的datanode。
2测试目标
测试并对比三个测试主体的入库、查询性能。
3测试方法
本次测试使用了三个测试工具:
- 使用pgbench测试不同压力条件下,复杂面状要素的入库效率
- 使用org2ogr测试不同客户端连接数条件下,fgdb文件的入库效率。fgdb有要素1178840条,820M。
- 使用tpc-H测试固定大小非空间数据的入库效率
- 使用tpc-H测试复杂查询的查询效率
4测试结果
4.1 pgbench测试结果
测试主体 | 连接数 | 3分钟插入记录数 | 每秒事务数 |
XC | 1 | 7581 | 42 |
4 | 15535 | 86 | |
12 | 27371 | 152 | |
24 | 43422 | 241 | |
2*24 | 70588 | 195 | |
4*24 | 84000 | 118 | |
GP | 1 | 1050 | 6 |
4 | 2757 | 15 | |
12 | 3740 | 20 | |
24 | 4040 | 22 | |
48 | 4039 | 22 | |
pgsql | 1 | 13140 | 73 |
4 | 21537 | 119 | |
12 | 20944 | 116 | |
24 | 21366 | 117 |
4.2 ogr2ogr测试结果
测试主体 | org2ogr进程数 | 总耗时(unit=m) |
XC | 2 | 34 |
4 | 34 | |
8 | 32 | |
16 | 32 | |
32 | 35 | |
40 | 36 | |
40+32+32 | 50 | |
40+30+30+30 | 61 | |
pgsql | 2 | 25 |
4 | 25 | |
8 | 23 | |
16 | 23 | |
32 | 35 | |
40 | 55 | |
GP | 4 | 57 |
8 | 61 | |
20 | 120 | |
40 | 150 |
4.3 tpc-H入库测试结果
使用tpc-H将8张总大小为200G,总记录数约1.7亿的数据入库。耗时情况如下:
XC(unit=m) | GP(m) | Pgsql(m) | |
耗时 | 8.05 | 6.8 | 21.9 |
4.4 tpc-H 查询测试结果
查询SQL编号 | XC(unit=s) | GP(s) | pgsql(s) |
1 | timeout | 14 | timeout |
3 | 123 | 18 | 57 |
4 | 144 | 1 | 17 |
6 | 3 | 1 | 12 |
7 | 228 | 18 | 64 |
8 | 110 | 5 | 39 |
10 | timeout | 1 | 76 |
11 | 27 | 1 | 22 |
12 | 22 | 1 | 38 |
14 | timeout | 1 | 13 |
15 | 1 | 1 | 28 |
16 | 21 | 5 | 37 |
17 | 23 | 51 | 1 |
18 | 18 | 5 | 191 |
19 | timeout | 6 | 40 |
20 | 3 | 1 | timeout |
5测试结论
- 可能是postgis版本较低的原因,GP处理空间数据的效率不高。正如4.1与4.2中所反映,入矢量数据效率较低。XC处理空间数据的性能要优于GP。
- 对于小事务的扩展能力,XC的性能最好。这得宜于它的架构支持多个coordinator,使得将客户连接负载均衡到不同的协调器中;
- GP作为决策支持型数据库,对于大数据量的查询分析,效率很高;
- 如果事务数非常少(以本例来看,在小于20-30的情况下),集群的性能不如单机的性能;
这篇关于Postgresql集群解决方案测试报告的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!