数据库性能压测之TPC-C基准测试

Posted 2023-03-28 基础技术研究

如果大家平时对数据库新闻比较关注的话，相信对上面的图片可能会有些印象，去年10月有个震惊业界的新闻是蚂蚁金服OceanBase数据库刷新了TPC-C纪录，打破了尘封已久的记录问鼎第一名。

这对国产数据库来讲是一件振奋人心的事情。

最近刚好有个契机需要对多款数据库进行性能压测，虽然业界做压测的工具很多，如：Sysbench、YCSB、TPC-C等，但是从行业使用的广泛程度、开源工具是否完善、是否支持多种数据库、压测负载是否更贴近真实业务等多方面却是差异很大。

经过对上述差异的多方面考虑，我们最后决定使用TPC-C负载模型。

TPC-C是用商品批发业务混合了只读和读写等复杂事务来模拟OLTP场景。

本文的目的是梳理TPC-C的特点以及工具使用，希望对同学们做TPC-C基准压测有所帮助。

话说TPCC

【 TPCC概念 】

Transaction Processing Performance Council (TPC) 事务处理性能委员会，是一家非盈利IT组织，他们的目的是定义数据库基准并且向产业界推广可验证的数据库性能测试。

而TPC-C最后一个C代表的是压测模型的版本，在这之前还有TPC-A、TPC-B。

A / B 两个版本模拟的是银行转账业务，相对业务模型比较简单，这里就不做过多说明，有感兴趣的朋友可以去TPC官网查找相关资料。

TPC-C自92年初发布，在过去20多年，不管是在业界还是学术界都是应用最为广泛的OLTP压测工具。

TPC-C具有以下特点：

1）多个复杂类型事务并发执行

2）具有在线和离线交易执行模式

3）多个会话终端模拟多用户访问

4）适中的系统运行时间和应用程序运行时间

5）整个操作有大量的磁盘IO读写操作

6）交易的事务具有完整的ACID特性

7）通过主键和二级索引对分布不均匀的数据进行访问

8）整个TPC-C的库是由许多包含不同字段属性和字段宽度的表组成

9）存在较多数据访问和更新之间的资源争夺

通过模拟批发供应商对客户的销售活动，TPC-C并不仅是体现了某个具体业务，而是代表了大部分销售活动，包含：管理、出售、分发产品和服务。

举个例子：可以模拟汽车租赁、食品批发、零部件供应等具体业务。

TPC-C压测作为一项基准测试，它并不能完整的展现生产上业务的多样性，而是做了很好的抽象只保留了此类活动的基本特征：如系统利用率和操作复杂程度，它的各种操作是成比例的。

整个基准测试描述的是一家批发供应商，其分布的多个销售区和相关仓库。

随着公司业务的扩展，需要创建新的仓库和相关销售区。

每个区域仓库覆盖10个销售地区。

每个地区为3,000位客户提供服务。

所有仓库保留公司出售的100,000件商品的库存。

下图说明了TPC-C业务环境的仓库，区域和客户层次结构。

 TPC-C压测交易组合中包含五种交易类型及其比例：

1）NewOrder 45% 属于中量级事务会有1%失败率（由于无效输入）

2）Payment 43% 属于短事务，为已存在的订单做支付动作

3）OrderStatus 4% 属于只读事务用于计算运输装状态和订单line item

4）Delivery 4% 查询每个仓库中没有交付的订单更新为交付状态

5）StockLevel 4% 属于只读事务，加入平均200 Order Line（相当于订单详情）及相应的库存用以生成报告

TPC-C五种交易类型中StockLevel和OrderStatus这两种交易属于只读事务，NewOrder 、Payment、Delivery属于读写事务，这五种请求是互相独立运行的，在交易组合中读写操作占92%，只读操作占8%。

下图显示模拟用户在终端每次发起交易的循环过程：

1）在五种交易类型选择一种

2）在终端显示发起的交易内容，提交文本完成输入

3）模拟用户接收到输出内容的时间这是事务执行的响应时间。

4）继续下一个循环

在③中TPC-C要求每种交易的响应时间必须小于等于5秒，但是StockLevel要求的响应时间则是小于等于20秒，其他measure menu 响应时间（包含选择交易类型时间和模拟屏幕输出时间）、Keying time（模拟用户输入时间）、Thinking time（思考等待时间）都有一定响应时间要求。

所以整个事务执行的循环时间是： 

 例如：

类别	响应时间	输入时间	事务执行	思考时间	循环时间
耗时	0.3	9.6	2.1	11.4	23.4

TPC-C整个过程保证事务的ACID。

1）原子性：通过验证事务提交或者失败后修改数据的记录

2）一致性：通过12个条件去验证数据的一致性，这里就不再列举所有条件了，有感兴趣的可自行查询官方文档，例如：W_YTD = sum(D_YTD) 仓库表和地区表要满足这个要求

3）隔离性：通过检查订单状态和新订单生成的读写冲突来检验隔离性，用来检测脏写、脏读、不可重复读、幻读等异常情况

4）持久化：在保证一致性的前提下，在系统crash后能够恢复，持久化主要依赖数据库本身的持久化能力

【 表业务意义 】

TPC-C模型是批发供应商OLTP场景，包含客户创建订单，派送订单，支付。

TPC-C的库由9张表组成如下图所示：

1）item（商品表）表是固定大小不变为10万warehouse（仓库表）、district（区域表）、customer（用户表）、stock（库存表）表和仓库数量大小而按比增加或者减小order（订单表）、new-order（新订单表）、order-line（订单行）、history（历史表）表会由于运行表的记录数会不断地增长。

客户会致电公司下达新订单或请求现有订单的状态。

订单由平均10个订单行（即订单项order-line）。

所有订单行中有百分之一是针对该地区没有库存的商品仓库，并且必须由另一个仓库提供。

下图箭头上所标注的数字为以仓库数为基数其他表数据量扩展关系。

 【 关注测试指标 】

在TPC-C有两个评测指标来评价系统，每分钟完成的事务数（tpmC）与完成每个tpmC的硬件价格price/tpmC。

咱们不是数据库厂商这里就不讨论后者了。

TPC-C用于去衡量业务吞吐量的性能指标是每分钟处理的订单数即tpmC。

按照官方手册定义，是指系统执行其它四种事务如类型支付、订单状态、库存、派送的同时每分钟生成新增订单数据量。

所有交易的90%以上满足响应时间时，tpmC越大，系统性能越强。

在通过调整Terminal终端数量（并发线程数）观察tpmC和操作系统的IO、网卡流量、CPU负载、内存使用等指标综合判断压测系统的性能水平。

玩转TPC-C     

【 工具选型 】 

目前做TPC-C压测的开源工具很多，如mysql-tpcc / HammerDB / Benchmarksql 等。

这三种是在做TPC-C压测使用最多的，也是资料比较丰富的工具。

由于我们在工作使用的数据库种类会比较多，mysql-tpcc只能用在MySQL或者兼容MySQL的数据库。

HammerDB使用方便，图形化界面可测DB2、PG、Oracle、MySQL等但是对于NewSQL类数据库兼容不是很友好。

基于以上多种原因我们采用BenchmarkSQL可用于以上所有数据库，可生成可视化数据图片。

加之BenchmarkSQL是Java编写，我们的技术栈也可以解决兼容等问题。

【 BenchmarkSQL使用攻略 】

接下来的内容，我会介绍怎么样部署使用BenchmarkSQL压测Oracle。

话不多说，直接上步骤：

1）Java环境安装，我这里就省略了（百度一下就知道）

2）下载安装BenchmarkSQL

3）编译源码包

4）修改配置文件，要注意的是：

a. 仓库数量建议设置1000以上，这里只做演示，并未设置太多，以免导入数据时间较长

b. Loadworkers 参数根据自己CPU核心数做决定

c. terminals参数即为并发线程数，根据自己的测试过程每轮测试做替换

d. runMins运行时间设置，至少不低于10mins

e. osCollectorDevices参数根据自己网卡信息设置

5）在压测数据库内创建账号和表空间

 6）导入压测数据，执行压测

7）把压测的结果数据生成可视化图表     

下面所展示即是经过处理后的数据，不仅如此还可以生成磁盘、内存、CPU、网卡流量、事务延迟的数据可视化图片，这里就不再展示，如果感兴趣您可以在自己的环境试试。 

备注：只需关注tpmC指标，代表的是新订单数，这是体现数据库性能的指标。 

总结

在过去20年，TPC-C不管是在产业界还是学术界都是应用最为广泛的OLTP测试模型。

当然好处也是很明显：

1）建立了压测标准

2）性能指标可比较性

3）结果可审计

4）模拟真实业务的标准工作负载。

缺点也是可见的：

1）完全按照官方手册标准测试成本是比较高的

2）需要一些测试技巧

3）作为购买产品的测试指标多为厂商会主导测试

4）面对如此越来越复杂的系统和大量分布式系统难以适用了。

在实际使用过程，针对压测数据库涉及硬件、操作系统、数据库、访问客户端、数据库参数变量要确定好自己的测试目标，控制好各项变量，会更准确体现出性能趋势。

最后，基准压测并不能体现真实业务性能，但是基准测试在生产中有很好的参考意义。

参考资料

[1] www.tpc.org

破记录！国产数据库KunDB 单节点TPC-C事务性能超180万tpmC

近日，星环科技KunDB在TPC-C事务性能测试中，采用常规国产服务器，实现了单节点tpmC超180万，体现其世界级领先的事务处理能力。

TPC-C是全球 OLTP 数据库最权威的性能测试基准，由TPC组织（国际事务性能委员会）制定的关于商品销售的订单创建和订单支付等的基准测试标准，是数据库联机交易处理系统的权威基准测试标准。

TPC-C测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)，C指TPC中的C基准程序。系统的总体价格(单位为美元)除以TPC-C值,就可以衡量出系统的性价比，性价比值越大，系统的性价比越高，所以一定程度上，TPC-C值可以反映出系统的性能价格比。

KunDB是星环科技基于分布式技术自主研发的国产分布式交易型数据库，提供完整的关系型数据库的能力，高度兼容MySQL和Oracle，具备可扩展、高并发、高可用、数据灾备等特性，满足企业关键业务处理、高并发查询、业务分布式改造、交易分析混合的数据中台等复杂场景。

自研内存数据库引擎，单节点事务性能超180万tpmC，是MySQL的4倍以上

KunDB自研了面向内存的数据库存储引擎，采用适合内存的数据管理模型和新型索引结构MassTree实现低延迟、大数据量的直接读写，配合MVTO并发控制策略保证和事务日志优化等保证事务ACID，为高并发同时要求强一致的关键业务场景提供高性能数据库解决方案。在常规配置国产服务器上，单节点TPCC超180万tpmC，相对于Oracle提升了67%，是MySQL的4倍以上。

KunDB采用Shared Nothing的分布式数据库架构，通过分布式层的能力与底层数据库能力高效协同以及通信链路的优化，实现了性能上的卓越优势，并且分布式与集中式架构统一，可以从高可用模式直接扩容为分布式模式，增加节点的线性扩展比超过90%。基于分布式架构特性，KunDB计算和存储能力可以进行线性扩展，满足企业事务处理高性能要求。

基于TSO的事务引擎，单集群事务处理超300万TPS，较GTM方案提升5倍以上

在分布式事务处理上，KunDB使用基于全局时间戳（TSO）的事务处理框架，集群的事务处理能力相较于GTM方案提升了5-6倍，达到300万TPS，完全满足头部互联网业务场景等超大型在线业务对高并发事务处理性能的需求。

自研SQL引擎，满足百GB数据规模的复杂分析，较MySQL最高提升80倍

KunDB采用业内最新的分布式查询优化技术，面向分布式存储丰富了查询优化的规则，结合全自研的分布式计算引擎和向量化执行引擎，满足100GB数据规模的复杂查询和统计分析。同样的数据规模下以TPC-H测试为参考，KunDB分析性能较MySQL有大幅度提升，22个Query最高性能提升可达到MySQL的近80倍。

 

支持百亿行级数据的高并发查询与检索，上万QPS

KunDB在精确查询和模糊查询等方面达到上万QPS，可满足百亿级数据的高并发查询与检索需求。并且基于其分布式架构特性，可根据业务需求扩缩容，轻松处理高并发、大流量的访问。

多项权威机构测试，性能表现优异

除了此次TPC-C测试取得突破外，KunDB还以优异的成绩通过了工信部、央行、信通院等多项数据库权威测试认证，如在央行金融分布式数据库标准检测中KunDB事务性能表现出众，并完成了 500GB 和 1TB 的 OLAP 的加项测试，展现了作为 HTAP 数据库的性能优势。

此外，KunDB同时兼容Oralce PL/SQL和MySQL方言，大幅降低国产化迁移和替代成本，并且与国内主流软硬件信创厂商完成了兼容适配互认证，满足信创验收要求。基于容器的混合部署技术，KunDB可支持X86架构和各种国产芯片架构的混合架构，能够运行在异构CPU架构以及多种操作系统混合部署的集群环境中，最大化利用硬件资源，让用户逐步实现国产化平滑替代。

目前，KunDB被连续收录Gartner、IDC、信通院等权威机构数据库报告，在金融、政务、能源、医疗、交通、教育等多个行业应用，满足企业关键业务处理、高并发查询等业务场景。未来，星环科技将继续深耕数据库领域，通过不断的技术创新和应用创新，为用户提供更高性能、更稳定可靠、更经济实用的国产化数据库产品。