Greenplum6 JDBC insert 性能百倍提升 之踩坑之路
状态描述:大多数人在使用jdbc的方式时会发现,jdbc的写入方式远达不到官方给出的测试性能,Greenplum6对比Greenplum5提升了很多性能,特别是对OLTP 做了大量优化,一下是官方社区的测试报告
但是发现自己搭建的环境速度远远慢于应有的效率(30 条/秒)
机器性能:
节点版本:
greenplum-db-6.7.0 (商业测试版,非社区版)
测试系统:
centos 7.6
测试表:
日分区表
字段100个
测试报告:
顺序 | 结果 |
---|---|
第一次调整后测试速度 | 30 条/秒 |
第二次调整后测试速度 | 100 条/秒 |
这就郁闷了,BUT,兄弟不要慌,也有人遇到问题说用gpkafka等方式,到时本人喜欢用JDBC,喜欢钻牛角尖,下面我们就开始踏上踩坑之路
大致原因有如下三点:
A、网络问题
B、机器配置问题
C、客户端及代码问题
网络问题:(排除)
建议大家在搭建完greenplum集群后做矩阵测试,此处不累赘,附官方网页及方法
https://gpdb.docs.pivotal.io/6-7/utility_guide/ref/gpcheckperf.html
gpcheckperf -f hostlist -d /data0/gpdata/test -d /data1/gpdata/test -r dsM -D -v
机器配置问题:(有效果,但是提升不明显)
附两篇文章参考
https://segmentfault.com/a/1190000022131758
https://segmentfault.com/a/1190000022113014
客户端及代码问题:(排除法)
1、将表字段减少
2、取消表的索引、字段约束、取消分区表(建立普通表)
3、将批量SQL语句 放Navicat Premium或者其它客户端直接运行
1、2可作为优化思路
3发现Navicat Premium的运行速度和java的不在一个数量级;
Navicat Premium 批量写入(2000条/秒)
经过进一步排查发现:不使用spring 的sql参数预处理模式,直接将sql组装然后运行,得出得结果和Navicat Premium一致
本文到次结束,有不对之处还请各位大神指正,后续将根据以上经验结果做继续优化优化