数据库性能压测之TPC-C基准测试
如果大家平时对数据库新闻比较关注的话，相信对上面的图片可能会有些印象，去年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