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测试方法

本次测试使用了三个测试工具：

1. 使用pgbench测试不同压力条件下，复杂面状要素的入库效率
2. 使用org2ogr测试不同客户端连接数条件下，fgdb文件的入库效率。fgdb有要素1178840条，820M。
3. 使用tpc-H测试固定大小非空间数据的入库效率
4. 使用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测试结论

1. 可能是postgis版本较低的原因，GP处理空间数据的效率不高。正如4.1与4.2中所反映，入矢量数据效率较低。XC处理空间数据的性能要优于GP。

1. 对于小事务的扩展能力，XC的性能最好。这得宜于它的架构支持多个coordinator，使得将客户连接负载均衡到不同的协调器中；
2. GP作为决策支持型数据库，对于大数据量的查询分析，效率很高；
3. 如果事务数非常少（以本例来看，在小于20－30的情况下），集群的性能不如单机的性能；