本文主要是介绍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集群解决方案测试报告的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
