最近对原生HTAP（cockroach db 和tidb）数据库同时以数仓为起点做HTAP数据库的greenplum 进行了相关场景性能测试，场景分为OLTP的TPC-C和TPC-B测试以及简单的OLAP统计聚合场景，所有测试都是通过186代理节点进行测试，crdb和greenplum使用相同的节点进行分段测试，由于是使用的虚拟机性能对三个分布式来说不会太高，废话不多说直接上测试数据，我们先看下整体的对比情况：、

一、 基础环境

二、 整体的OLTP测试情况对比

sysbench测试中由于for update 对greenplum的影响测试结果不太理想，所以通过pgbench对greenplum再进行一轮测试

greenplum 6.7.1pgbench测试，通过自己写的脚本实现的三个场景

三、 OLAP简单场景统计性能对比

t1、t2表各生成1亿记录：包含id、int类型、字符类型、时间类型、浮点型，由于HTAP对复杂的统计分析场景不支持（如窗口函数、高级sql），所以采取通用场景测试：

准备测试表：

-------------crdb-------------create table t1 (id int primary key, c1 float4, c2 text, c3 timestamp, c4 float4);create table t2 (id int primary key, c1 float4, c2 text, c3 timestamp, c4 float4);

------------TiDB--------------

create table t1 (id int, c1 float, c2 text, c3 timestamp, c4 float);

create table t2 (id int, c1 float, c2 text, c3 timestamp, c4 float);

------------GPDB--------------

create table t1 (id int, c1 float, c2 text, c3 timestamp, c4 float);

create table t2 (id int, c1 float, c2 text, c3 timestamp, c4 float);

由于crdb、tidb一个事务中生成1亿记录未能完成（crdb异常、tidb异常缓慢），所以通过程序实现分段提交实现：insert into t1 select id, random()*1000, md5(random()::text), clock_timestamp(), random()*1000 from generate_series(1,100000000) t(id);insert into t2 select id, random()*1000, md5(random()::text), clock_timestamp(), random()*1000 from generate_series(1,100000000) t(id);

-------------crdb-------------

20线程 每线程500万数据，双表同时写入，共耗时3200359毫秒

按开始-结束时间统计单事务耗时：总耗时=单个事务提交*（2亿/1000/20），反推出单个事务提交320毫秒，这320包含了生成数据时间。程序逻辑：生成1000条数据 ->t1→t2。

按日志输出统计单事务耗时：

#cat nohup.out |grep t1 |awk -F '1000条，耗时：' '{sum += $2} END {print "Average =",sum/NR}'Average = 225.017

# cat nohup.out |grep t2 |awk -F '1000条，耗时：' '{sum += $2} END {print "Average =",sum/NR}'Average = 249.99

------------TiDB--------------

#cat nohup.out |grep t1 |awk -F '1000条，耗时：' '{sum += $2} END {print "Average =",sum/NR}'

Average = 295.407

cat nohup.out |grep t2 |awk -F '1000条，耗时：' '{sum += $2} END {print "Average =",sum/NR}'Average = 350.562

四、 总结

综合来看greenplum的目前对oltp场景支持的已经足够好，但是greenplum在oltp场景目前存在Master单节点的性能瓶颈，后续希望greenplum做出突破，新型的htap分布式数据库，目前节点性能损耗还是比较严重的，htap 的优势应该是在节点足够多，能够成线性的增长，对特性这块的支持也是不尽相同，greenplum是对原生关系型数据库支持特性最好的（完全支持，如触发器需要单节点使用）。

注：本文涉及的测试用例内容过于繁杂，故没有在文中过多体现，如有兴趣的同学可以联系我们获取详情（可发送邮件到partner@postgresqlchina.com）。

作者：马晓亮 金风科技数据库工程师