Greenplum、TiDB、CockroachDB 谁是？【用户实测HTAP数据库性能】

传统数据库领域包含两大业务场景：OLTP和OLAP。过去，两大业务场景需要依赖不同的数据库产品，数据在不同数据库之间融通的过程中往往容易产生数据孤岛、数据的时效性、数据的一致性等问题。因此，近年来支持HTAP混合负载的数据库产品正在受到越来越多的关注。如何实现一款的HTAP数据库，业界有不同的声音。

一方面，以TiDB为代表的新兴数据库厂商选择从头做起，搭建一款HTAP原生数据库。另一方面，以Greenplum为代表的成熟数据库厂商选择在自己的优势产品中引入对HTAP的支持。其中，Greenplum6.0通过引入全局死锁检测、优化全局事务、升级PG内核等优化，实现了在OLTP上性能的飞跃。那么，这些HTAP数据库的性能究竟如何呢？

下面对三款数据库：Greenplum、CockroachDB和TiDB 进行了相关场景的性能测试。下面，让我们来看一下测试结果。

此次性能测试场景分为OLTP的TPC-C和TPC-B测试以及简单的OLAP统计聚合场景（作为一款OLAP数据库，Greenplum对复杂场景支持优异，而大多数新兴HTAP数据库还不能很好的支持复杂场景，所以本测试只测试简单OLAP场景），所有测试都是通过186代理节点进行测试，CockroachDB（后文简称CRDB）和Greenplum使用相同的节点进行分段测试，由于是使用的虚拟机性能对三个分布式来说不会太高，废话不多说直接上测试数据，我们先看下整体的对比情况：

1.基础环境

1.1硬件环境：

1.2软件环境：

2.整体的LTP测试情况对比

sysbench测试脚本是为PostgreSQL设计，其中用到了SELECT FOR UPDATE。Greenplum 6.x还不支持 SELECT FOR UPDATE，所以通过pgbench对Greenplum再进行一轮测试。（Greenplum 7将支持SELECT FOR UPDATE）

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

3.OLAP简单场景统计性能对比

t1、t2表各生成1亿记录：包含id、int类型、字符类型、时间类型、浮点型。由于TiDB和CRDB对复杂的统计分析场景支持不好（如窗口函数、CTE等），所以采取简单场景测试：

准备测试表：

由于CRDB、TiDB一个事务中生成1亿记录未能完成（CRDB异常、TiDB异常缓慢），所以通过程序实现分段提交实现：

1.insert into t1 select id, random()*1000, md5(random()::text), clock_timestamp(), random()*1000 from generate_series(1,100000000) t(id);

2.insert into t2 select id, random()*1000, md5(random()::text), clock_timestamp(), random()*1000 from generate_series(1,100000000) t(id);