数据库性能压测之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
数据库性能压测之TPC-C基准测试相关推荐
- sysbench数据库性能压测详解
文章目录 0.参考资料&适用范围 1.安装 2.压测 2.1.CPU压测 2.2.MySQL数据库压测 2.2.1.选项说明 2.2.2.压测步骤 0.参考资料&适用范围 参考资料: ...
- Oracle的学习心得和知识总结（十八）|Oracle数据库性能压测工具swingbench的安装和使用及AWR ASH ADDM报告生成
目录结构 注:提前言明 本文借鉴了以下博主.书籍或网站的内容,其列表如下: 1.参考书籍:<Oracle Database SQL Language Reference> 2.参考书籍:& ...
- sysbench性能压测以及mysql性能压测
sysbench性能压测以及mysql性能压测 一.Sysbench是一个模块化的.跨平台.多线程基准测试工具,主要用于各种不同系统的参数下的数据库负载情况. 主要测试方式 cpu性能 磁盘io性能 ...
- 压测接口线程数设置_ZAT掌门性能压测巡检系统实战和落地
项目背景 随着业务拓展,对于接口性能的要求也在上升,各部门也开始针对部分慢接口进行优化,从测试角度针对这些优化需求进行测试时不仅要保证对应接口的功能正常使用同时也要验证接口优化成果.在日常的开发工作中 ...
- 后端服务性能压测实践
转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 ...
- 性能压测，SQL查询异常
早上测试对性能压测,发现取sequence服务大量超时报错,查询线上的监控SQL: 大量这个查询,我在DeviceID和Isdelete上建有复合索引,应该很快,而且我测试了一下,取值,执行效率很高, ...
- 如何做好性能压测(一)丨压测环境设计和搭建
简介:如何做好性能压测(一)丨压测环境设计和搭建 一般来说,保证执行性能压测的环境和生产环境高度一致是执行一次有效性能压测的首要原则.有时候,即便是压测环境和生产环境有很细微的差别,都有可能导致整个压 ...
- Mycat对于导入和扩容迁移性能压测
Mycat对于导入和扩容迁移性能压测 1. 测试环境 1.1. 硬件环境 机器ip OS CPU CPU Processors 内存 172.16.54.135 CentOS Linu ...
- tcp压测工具_【解决方案】性能压测及分析调优实践
[关键导读]结合一次重保活动的性能压测需求,详解了整体的性能测试策略及性能分析思路,并在实施过程中有效利用了网易易测的NPT性能测试平台一站式完成了压测场景设计.执行.业务指标监控.性能指标分析等活动 ...
最新文章
- 简单几行程序轻松分析Excel
- CSV在制药企业中的应用
- opencv-python（PIL）图像处理之训练模型前的几种图预处理
- 《构建之法》阅读笔记07
- runtime官方文档
- ntce服务器不稳定,当心！你的教师资格证成绩失效了！| 服务
- 从零开始学Pytorch（十四）之优化算法进阶
- 飞书上线“程序员友好”功能 迎接1024程序员节
- 橱柜高度与身高对照表_厨房台面高度是多少 厨房台面如何选购
- 关系模型的完整性约束
- BulkRen文件批量改名工具的一点点使用心得
- 分布式CAP是什么？
- 初级程序员晋升中级程序员，只差这7个技能
- Word文档进行XXE攻击
- 高阶无穷小量和低阶无穷小量 洛必达的使用条件 三阶导数的几何意义 阶乘的意义，0的阶乘为什么等于1 泰勒公式简单理解，麦克劳林级数 带拉格朗日余项的泰勒公式和带皮亚诺余项的泰勒公式区别
- 实现单链表的就地逆置
- 把ipa包上传入AppStore
- 给所有男人和女人的人生忠告
- 生物老师（搞笑）鼻子和手
- ChatGPT 简介