漫谈“数据库基准测试”

近期因工作原因，对多种数据库进行了数据库基准测试。工作之余，特意关于了一下数据库基准测试内容，特分享出来。

1. 基准测试关注点

。。。基准测试需要做吗？

。。。如何选择一种基准测试？

。。。如何看待基准测试的结果？

想来这些问题，也是很多朋友提到过的。下面就总结下，基准测试应关注哪些方面？

• 业务关联性 基准测试的业务场景是否与企业的实际业务场景类似，是最为重要的关注点之一。不相关的基准，测试结果再好，也没有实际意义。此外，还要关注基准测试使用的数据模型是什么？例如有些数仓测试模型是使用星型模型建模，而你当前的数仓是使用关系模型构建的，显然此类基准测试参考意义不大。有些行业领导型企业会定期发布自己产品的基准测试，因其面对用户各异，很难做到差异性，因此一般会采用权威的基准测试模型，用户参考时也要注意是否与自身业务契合。一种比较好的方式，是企业构建自己的业务模型，基于此进行测试，后面会谈到这种方式。
• 度量指标选择

基准测试一般都有多个度量指标，这些指标是否容易被客户理解，是否能真实反映客户关注点，这些很重要。举个例子，我们是关注一个系统整体的吞吐量，还是关注它平均的响应时间，这些是要从具体业务场景出来，找到真正能反映自己诉求的指标。

• 数据真实性 真实的环境，数据都是非规格化的、有瑕疵的、有倾斜的。人为制造出的数据往往比较规则，容易测试出较高的指标。有的基准测试是有完备的数据准备工具，可尽量模拟出贴近真实应用场景的数据。
• 负载可扩展性 评测基准是否适用于不同规模的计算机系统，许多评测基准会使用标度因子来决定模拟数据的规模，通过调整标度因子来得到不同规模的工作负载。要尽量选择参考贴近自己负载下的结果，更具有参考意义。
• 客观性与公正性 众所周知，在竞技比赛中，一个人不能既是运动员又是裁判员。测试基准好比竞技比赛中的裁判员，应该由中立的第三方机构制定。事实也证明，在各个领域最受欢迎的测试基准都是由第三方机构设计的。过去20多年的经历证明TPC系列基准是数据库领域最为广泛接受的基准。除此之外，第三方机构的审计也是保证证评测结果的客观性与公正性的重要手段。
• 健壮性 测试基准要足够健壮，不能轻易被“hack”，这对测试结果的公平性非常重要。测试基准应该设计之初就尽量保证其公正性，规避可能的作弊手段，这样才更加具有说服力。

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)。

• 新订单(New-Order) 客户输入一笔新的订货交易。操作上在任一客户端发起，从固定仓库随机选取 5-15 件商品，创建新订单。其中 1%的订单要由假想的用户操作失败而回滚。 主要特点：中量级、读写频繁、要求响应快。
• 支付操作(Payment) 更新客户帐户余额以反映其支付状况。操作上从任一客户端发起，从固定的仓库随机选取一个辖区及其内用户，采用随机的金额支付一笔订单，并作相应历史记录。 主要特点：轻量级，读写频繁，要求响应快。
• 订单状态查询(Order-Status) 查询客户最近交易的状态。操作上从任一客户端发起，从固定的仓库随机选取一个辖区及其内用户，读取其最后一条订单，显示订单内每件商品的状态。

主要特点：中量级，只读频率低，要求响应快。

• 发货(Delivery) 发货(模拟批处理交易)。操作上，对于任意客户端，随机选取一个发货包，更新被处理订单的用户余额，并把该订单从新订单中删除。

主要特点：1-10个批量，读写频率低，较宽松响应时间。

• 库存状态查询(Stock-Level)

查询仓库库存状况，以便能够及时补货。对于任意客户端，从固定的仓库和辖区随机选取最后20条订单，查看订单中所有的货物的库存，计算并显示所有库存低于随机生成域值的商品数量。

主要特点：重量级，只读频率低，较宽松的响应时间.

3).测试指标

TPC-C测试的结果主要有两个指标，即流量指标(简称tpmC)和性价比(简称Price/tpmC)。

• 流量指标 按照TPC组织的定义，流量指标描述了系统在执行支付操作、订单状态查询、发货和库存状态查询这4种交易的同时，每分钟可以处理多少个新订单交易。所有交易的响应时间必须满足TPC-C测试规范的要求，且各种交易数量所占的比例也应该满足TPC-C测试规范的要求。在这种情况下，流量指标值越大说明系统的联机事务处理能力越高。
• 性价比 即测试系统的整体价格与流量指标的比值，在获得相同的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)。

• tpsE 性能指标是指系统在执行多种交易时，每秒钟可以处理多少交易(tpmC是以分钟为单位)，其指标值越大越好，最终测试成绩tpsE=交易执行事务总数/ Measurement Interval(测量区间)。
• 美元/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).工作负载

• 查询类 TPC- H测试围绕22个SELECT语句展开，每个SELECT严格定义，遵守SQL-92语法，并且不允许用户修改。标准中从4个方面定义每个SELECT语句，即商业问题、SELECT 的语法、参数和查询确认。这些SELECT语句的复杂程度超过大多数实际的OLTP应用。为了保证每次查询的结果不同，SELECT语句都带有变量。为了防止缓冲功能被放大，22个SELECT语句随机编排成一个查询流后，再逐个执行。
• 更新类 为了逼真地模拟数据仓库的实际应用环境，在22个查询执行的同时，还有一对更新操作RF1和RF2并发地执行。RF1向Order表和Lineitem表中插入原行数的0.1%的新行，模拟新销售业务的数据加入到数据库中；RF2从Order 表和Lineitem表中删除等量与RF1增加的数据，模拟旧的销售数据被淘汰。RF1和RF2的执行必须保证数据库的ACID约束，并保持测试前后的数据库中的数据量不变。更新操作除输出成功或失败信息外，不产生其它输出信息。
• 测试分解 TPC-H测试分解为3个子测试：数据装载测试、Power测试和Throughput测试。 * 建立测试数据库的过程被称为装载数据，装载测试是为测试DBMS装载数据的能力。装载测试是第一项测试，测试装载数据的时间，这项操作非常耗时。 * Power测试是在数据装载测试完成后，数据库处于初始状态，未进行其它任何操作，特别是缓冲区还没有被测试数据库的数据，被称为raw查询。Power 测试要求22个查询顺序执行1遍，同时执行一对RF1和RF2操作。 * 最后进行Throughput测试，也是最核心和最复杂的测试，它更接近于实际应用环境，与Power测试比对SUT系统的压力有非常大的增加，有多个查询语句组，同时有一对RF1和RF2更新流。

3).测试指标

测试中测量的基础数据都与执行时间有关，这些时间又可分为：装载数据的每一步操作时间、每个查询执行时间和每个更新操作执行时间，由这些时间可计算出：数

据装载时间、Power@Size、Throughput@Size、QphH@Size

和$/QphH@Size。

• 装载数据时间 装载数据的全过程有记时操作和不记时操作之分，记时操作必须测量所用时间，并计入到数据装载时间中。一般情况下，需要记时的操作有建表、插入数据和建立索引。
• 查询和更新时间 在Power 测试和Throughput 测试中所有查询和更新流的时间必须被测量和记录，每个查询时间的计时是从被提交查询的第一个字符开始到获得查询结果最后一个字符的时间为止。更新时间要分别测量RF1和RF2的时间，是从提交操作开始到完成操作结束的时间。
• Power@Size Power@Size是Power测试的结果，被定义为查询时间和更改时间的几何平均值的倒数。
• Throughput@Size Throughput@Size是Throughput测试的结果，被定义为所有查询执行时间平均值的倒数。

4).最新评测

6. 颇有难度的AP测试标准：TPC-DS

受限于TPC-H，无法反应出数据流转的全流程，且新兴的数据仓库开始采用新的模型，如星型模型、雪花模型。TPC-H已经不能精准反映当今数据库系统的真实性能。为此，TPC组织推出了新一代的面向决策应用的TPC-DS基准。TPC-DS基准意图提供一个公平和诚实的业务和数据模型，以衡量DBMS系统的整体性能，如CPU与内存使用，I/O负载特征以及操作系统和DBMS完成海量数据复杂计算等。这个基准测试有以下几个主要特点：

• 共99个测试案例，遵循SQL99和SQL2003的语法标准，SQL案例比较复杂。
• 分析的数据量大，并且测试案例是在回答真实的商业问题。
• 测试案例中包含各种业务模型(如分析报告型，迭代式的联机分析型，数据挖掘型等)。
• 几乎所有的测试案例都有很高的IO负载和CPU计算需求。

1).测试模型

TPC-DS基准提供了两种重要的业务模型: 用户查询和数据维护。查询是把操作性的事实转化为商业情报，而数据维护操作是将数据仓库数据与操作数据库进行同步。

TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张维度表平均每张表含有18列。测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。

2).工作负载

TPC-DS 测试分为: 测试数据加载、查询顺序执行(Power)和并行执行(Throughput) 测试。

• 测试数据加载 主要包括: 被测系统准备、数据文件生成、测试数据库创建、基础表创建、数据加载、约束验证、辅助数据结构( 如索引) 创建、表和辅助数据统计分析等。
• Power测试 用于评测数据库对单个查询流的处理能力。
• Throughput测试 用于测试DBMS对多个查询流并发查询和操作的处理能力，分为数据查询和数据维护各两个子步骤。

数据查询是TPC-DS基准测试的核心，包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用。在Power测试中，99个数据查询形成的查询流只执行一次，用于评测数据库对单个查询流的处理能力。在Throughput测试中，数据查询执行两次，每次执行至少20个以上的并行查询流，模拟多个用户同时对数据库的查询操作。为了适应多查询流，数据库优化组件必须依据数据规模进行规划，每个用户也要有足够的临时空间来保存大量的中间结果集。这样DBMS 能找出并行用户的最佳执行计划。下表展示了TPC-DS 基准查询所使用的SQL 特征及数量。

3).测试指标

TPC-DS基准定义了两个评价指标:

• QphDS@SF 每秒的有效查询数据量的性能指标。
• $/QphDS@SF 反映每秒查询数据量的性价比指标，值越小说明性价比越高。

4).最新评测

7. 构建自己的基准测试

上述这些数据基准测试，都是权威机构根据某业务模型抽象而来，并不能反映所有企业的真实场景。企业可根据业务特征，建立自己业务压力模型。简单理解就是将业务模拟抽象出来，便于后面进行压力放大测试。要做到这一步，需要对业务有着充分的了解和评估。例如下表就是笔者之前在一家电商平台抽象的业务模型。

这个表格模拟了某个类电商的业务，其包含的主要模块及模块中的主要操作。针对不同的操作其交易复杂度不同(交易复杂度可理解为执行SQL语句的个数)。根据不同的读写情况，区分是数据读还是数据写。在估算了业务总量(交易量)的情况下，很容易推算出数据操作的量。通过这种方式将业务压力模型转化为数据压力模型。此处的难点在于对业务逻辑的抽象能力及对模块业务量的比例评估。

有了上述概览的表格后，针对每一种业务操作，可细化其操作。最终将其抽象成SQL语句及对应的访问特征。其伪代码可描述为

可依据上述伪代码，编制压力测试代码。通过一些工具调用测试，产生模拟测试的压力。例如我经常使用的oradbtest/mydbtest或sysbench等，都是不错的压力测试工具。建议企业根据自身情况，整理出自己的业务压力模型。这在系统改造、升级、扩容评估、新硬件选型等多种场合都很有用处。它要比厂商提供的类似TPCC测试报告，更有意义。据我了解，很多规模较大的公司都有比较成熟的压力模型。