共计 2506 个字符，预计需要花费 7 分钟才能阅读完成。
传统数据库领域包含两大业务场景：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. 硬件环境：
2. 软件环境：
二、整体的 OLTP 测试情况对比
sysbench 测试脚本是为 PostgreSQL 设计，其中用到了 SELECT FOR UPDATE。Greenplum 6.x 还不支持 SELECT FOR UPDATE，所以通过 pgbench 对 Greenplum 再进行一轮测试。（Greenplum 7 将支持 SELECT FOR UPDATE）
Greenplum 6.7.1pgbench 测试，通过自己写的脚本实现的三个场景。
三、OLAP 简单场景统计性能对比
t1、t2 表各生成 1 亿记录：包含 id、int 类型、字符类型、时间类型、浮点型。由于 TiDB 和 CRDB 对复杂的统计分析场景支持不好（如窗口函数、CTE 等），所以采取简单场景测试：
准备测试表：
CRDB
create table t1 (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);Greenplum
create table t1 (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
由于 CRDB 主要针对 OLTP 优化，并不是一个真正意义上的 HTAP 数据库，下图我们将 Greenplum 与 TiDB 两款 HTAP 数据库 OLAP 性能数据进行对比。具体对比数据请参考上面的表格。
毫秒级的测试数据证明了 Greenplum 强大的 OLAP 性能
四、总结
综合来看 Greenplum 的 OLAP 能力卓越，OLTP 场景支持的已经足够好。Greenplum 在 OLTP 场景目前存在 Master 单节点的性能瓶颈，后续希望 Greenplum 做出突破。新型的 HTAP 分布式数据库，目前节点性能损耗还是比较严重的，HTAP 的优势应该是在节点足够多，能够成线性的增长，对特性这块的支持也是不尽相同，Greenplum 是对原生关系型数据库支持特性最好的（完全支持，如触发器需要单节点使用）。
编者记：除了单纯 OLAP 和 OLTP 的性能考量之外，一个优秀的 HTAP 还需要考虑在混合负载的情况下，如何合理分配计算资源，避免发生 AP 和 TP 查询之间的资源抢占。针对混合负载，Greenplum 的 Resource Group 特性基于 cgroup 技术，实现了 CPU 和内存资源在不同资源组之间的隔离，显著降低了 AP 负载和 TP 负载之间的相互影响。
希望了解测试过程的同学，欢迎扫码获取测试代码。
