近期因工作原因,对多种数据库进行了数据库基准测试。工作之余,特意关于了一下数据库基准测试内容,特分享出来。
1. 基准测试关注点
。。。基准测试需要做吗?
。。。如何选择一种基准测试?
。。。如何看待基准测试的结果?
想来这些问题,也是很多朋友提到过的。下面就总结下,基准测试应关注哪些方面?
基准测试一般都有多个度量指标,这些指标是否容易被客户理解,是否能真实反映客户关注点,这些很重要。举个例子,我们是关注一个系统整体的吞吐量,还是关注它平均的响应时间,这些是要从具体业务场景出来,找到真正能反映自己诉求的指标。
2. 数据库基准测试概览
上图是来自金澈清等人所著《数据管理系统评测基准:从传统数据库到新兴大数据》一文。其描述中数据库领域基准测试的发展。从早期主要关注与OLTP到OLAP类,再到后面的对象、空间、流及大数据,其测试标准也是在不断演化之中。这里面的大多数我都没有接触过,下面将介绍下接触过的且最为常见的几类测试。
TPC组织
在介绍之前,不得不谈一下TPC组织。事务性能管理委员会(TPC)是目前最知名的数据管理系统评测基准标准化组织。是由数十家会员公司创建的非盈利组织,总部设在美国。TPC的成员主要是计算机软硬件厂家,而非计算机用户,其功能是制定商务应用基准程序的标准规范、性能和价格度量,并管理测试结果的发布。在过去二十多年间,该机构发布了多款数据库评测基准,如TPC-A、TPC-D、TPC-H和TPC-DS,在业界得到了广泛应用。
3. 老当益壮的TP测试标准:TPC-C
TPC-C标准,是专门针对联机交易处理系统(OLTP系统)的规范,一般情况下我们也把这类系统称为业务处理系统。其创建于1992年7月,最后更新在2010年2月。是行业中公认的权威和最为复杂的在线事务处理基准测试。它通过模拟仓库和订单管理系统,测试广泛的数据库功能,包括查询、更新和小批量事务。
1).测试模型
TPC-C测试用到的模型是一个大型的商品批发销售公司,它拥有若干个分布在不同区域的商品仓库。当业务扩展的时候,公司将添加新的仓库。每个仓库负责为10个销售点供货,其中每个销售点为3000个客户提供服务,每个客户提交的订单中,平均每个订单有10项产品,所有订单中约1%的产品在其直接所属的仓库中没有存货,必须由其他区域的仓库来供货。同时,每个仓库都要维护公司销售的100000种商品的库存记录。
其中,表框里的数字表示该表将要存放多少条记录,仓库数W的调整在测试中能够体现数据库所能够支持的数据规模的能力;表间的数据关系数据的父子关系之间儿子的个数,比如一个Warehouse要对应10个District等,另外,“+”号表示这种对应关系可能会更多。
2).事务处理
TPC-C 标准测试模拟了5种事务处理,通过这些事务处理来模拟真实的用户操作,事务分别为新订单(New-Order)、支付操作(Payment)、订单状态查询(Order-Status)、发货(Delivery)、库存状态查询(Stock-Level)。
主要特点:中量级,只读频率低,要求响应快。
主要特点:1-10个批量,读写频率低,较宽松响应时间。
查询仓库库存状况,以便能够及时补货。对于任意客户端,从固定的仓库和辖区随机选取最后20条订单,查看订单中所有的货物的库存,计算并显示所有库存低于随机生成域值的商品数量。
主要特点:重量级,只读频率低,较宽松的响应时间.
3).测试指标
TPC-C测试的结果主要有两个指标,即流量指标(简称tpmC)和性价比(简称Price/tpmC)。
4).最新评测
4. 轻量敏捷的TP测试标准:TPC-E
TPC-C逼真的模拟了OLTP应用,在发布后逐渐得到广大用户的认可,但随着信息产业的不断发展,TPC-C的一些问题也慢慢暴露出来。首先,是随着B2B、B2C等新型应用逐渐兴起,TPC-C的业务模型距离当前OLTP用户应用越来越远;其次,大量测试设备投入使得TPC-C测试给厂商带来了较大的压力,TPC组织于2007年3月推出了全新的OLTP测试标准—TPC-E,意在用这个测试标准取代TPC-C测试。但取代过程不是一蹴而就的,目前状态是TPC-C与TPC-E测试并存。
1).测试模型
TPC-E是以美国纽约证券交易所为模型,该测试模拟了一系列后端处理数据以及证券公司前端客户在股票交易市场的典型行为:账户查询、在线交易和市场调研。
针对以上模型,TPC-E建立了比TPC-C更为复杂的条件。数据类型从原来的3种扩展到10种,事务类型从原来的5种增加到12种,数据表由原来的9个增加到了33个,数据库构成更加复杂,也更加符合实际应用。
2).事务类型
与TPC-C测量事务类型只有四种相比较,TPC-E的事务类型更加丰富,数量达到了十二种,其中包括交易查询事务、交易执行事务、交易结果更新事务等。前10种事务按照一定比例混合即成为最终测试事务合集。在这12种事务中数据维护事务、交易清理事务较为特殊,他们不是由客户端发起请求,而是数据库自身维护所要完成的工作,数据维护事务每秒钟执行一次,而交易清理事务每次测试开始时执行一次。每个事务对应数据库管理系统中的一个或多个带输入和输出参数的存储过程,单个存储过程称为一个事务帧。TPC-E测试标准要求每项事务中90%的响应时间要在某一个指定时间内完成,这是出于在实际环境中对客户真实应用情况的一个考虑。虽然不同的事务所要求的响应时间约束也不同,但基本上都是要求在3秒钟内完成。
3).测试指标
TPC-E的测试结果也主要有两个指标:性能指标(tpsE)和性价比(美元/tpsE)。
4).最新评测
5. 生命常青的AP测试标准:TPC-H
TPC-H,是在TPC-D上发展起来并取代TPC-D。TPC-H是一款面向商品零售业的决策支持系统测试基准,模拟决策支持系统中的数据库操作。主要目的是评价特定查询的决策支持能力,强调服务器在数据挖掘、分析处理方面的能力。查询是决策支持应用的最主要应用之一,数据仓库中的复杂查询可以分成两种类型:一种是预先知道的查询,如定期的业务报表;另一种则是事先未知的查询,称为动态查询(Ad-Hoc Query)。
1).测试模型
TPC- H 测试模型为数据库服务器连续7×24 小时工作,可能只有1次/月的维护;多用户并发执行复杂的动态查询,同时有并发执行表修改操作。TPC-H基准的数据库模式遵循第三范式。其数据库模型如下图,共有8张表,除Nation和Region表外,其它表与测试的数据量有关,即比例因子SF(Scale Factor)。由于数据量的大小对查询速度有直接的影响,TPC- H标准对数据库系统中的数据量有严格、明确的规定。用SF描述数据量,1SF对应1GB单位,SF由低到高依次是1、10、30、100、300、1000、3000、10000。需要强调,SF规定的数据量只是8个基本表的数据量,不包括索引和临时表。
2).工作负载
3).测试指标
测试中测量的基础数据都与执行时间有关,这些时间又可分为:装载数据的每一步操作时间、每个查询执行时间和每个更新操作执行时间,由这些时间可计算出:数
据装载时间、Power@Size、Throughput@Size、QphH@Size
和$/QphH@Size。
4).最新评测
6. 颇有难度的AP测试标准:TPC-DS
受限于TPC-H,无法反应出数据流转的全流程,且新兴的数据仓库开始采用新的模型,如星型模型、雪花模型。TPC-H已经不能精准反映当今数据库系统的真实性能。为此,TPC组织推出了新一代的面向决策应用的TPC-DS基准。TPC-DS基准意图提供一个公平和诚实的业务和数据模型,以衡量DBMS系统的整体性能,如CPU与内存使用,I/O负载特征以及操作系统和DBMS完成海量数据复杂计算等。这个基准测试有以下几个主要特点:
1).测试模型
TPC-DS基准提供了两种重要的业务模型: 用户查询和数据维护。查询是把操作性的事实转化为商业情报,而数据维护操作是将数据仓库数据与操作数据库进行同步。
TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表,17张维度表平均每张表含有18列。测试用的数据和值是有倾斜的,与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集,也是难度较大的一个测试集。
2).工作负载
TPC-DS 测试分为: 测试数据加载、查询顺序执行(Power)和并行执行(Throughput) 测试。
数据查询是TPC-DS基准测试的核心,包含99个SQL查询,覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用。在Power测试中,99个数据查询形成的查询流只执行一次,用于评测数据库对单个查询流的处理能力。在Throughput测试中,数据查询执行两次,每次执行至少20个以上的并行查询流,模拟多个用户同时对数据库的查询操作。为了适应多查询流,数据库优化组件必须依据数据规模进行规划,每个用户也要有足够的临时空间来保存大量的中间结果集。这样DBMS 能找出并行用户的最佳执行计划。下表展示了TPC-DS 基准查询所使用的SQL 特征及数量。
3).测试指标
TPC-DS基准定义了两个评价指标:
4).最新评测
7. 构建自己的基准测试
上述这些数据基准测试,都是权威机构根据某业务模型抽象而来,并不能反映所有企业的真实场景。企业可根据业务特征,建立自己业务压力模型。简单理解就是将业务模拟抽象出来,便于后面进行压力放大测试。要做到这一步,需要对业务有着充分的了解和评估。例如下表就是笔者之前在一家电商平台抽象的业务模型。
这个表格模拟了某个类电商的业务,其包含的主要模块及模块中的主要操作。针对不同的操作其交易复杂度不同(交易复杂度可理解为执行SQL语句的个数)。根据不同的读写情况,区分是数据读还是数据写。在估算了业务总量(交易量)的情况下,很容易推算出数据操作的量。通过这种方式将业务压力模型转化为数据压力模型。此处的难点在于对业务逻辑的抽象能力及对模块业务量的比例评估。
有了上述概览的表格后,针对每一种业务操作,可细化其操作。最终将其抽象成SQL语句及对应的访问特征。其伪代码可描述为
可依据上述伪代码,编制压力测试代码。通过一些工具调用测试,产生模拟测试的压力。例如我经常使用的oradbtest/mydbtest或sysbench等,都是不错的压力测试工具。建议企业根据自身情况,整理出自己的业务压力模型。这在系统改造、升级、扩容评估、新硬件选型等多种场合都很有用处。它要比厂商提供的类似TPCC测试报告,更有意义。据我了解,很多规模较大的公司都有比较成熟的压力模型。