数据库OceanBase创始人阳振坤：通关TPC-C到底有多难？

自从蚂蚁金服自研数据库OceanBase得到TPC-C测试第一名后，引发了行业内外大量关注，咱们衷心的感谢你们对OceanBase的支持与厚爱，也虚心听取外界的意见和建议。为了让你们更好的了解测试的技术细节，咱们特地邀请了OceanBase的核心研发人员对本次测试作专业的技术解读，本文为第一篇，后续文章也将于近日对外发布。

OceanBase于2010年立项，九年来，研发人员一步一个脚印，不断的对OceanBase作出改进以及增长新的功能。OceanBase也从服务于支付宝开始，逐渐对外开放，为广大的各行业客户提供服务。在这个过程当中，咱们但愿外界对OceanBase的实力有更直观的了解，让客户对咱们的产品更有信心，TPC-C测试为咱们提供了一个绝佳的舞台。

经过本次测试，咱们发现了OceanBase的一些不足之处，好比，以前的单机数据库只能经过增长CPU、内存等来提升处理能力，OceanBase经过分布式架构，可让大量的普通硬件设备像一台电脑同样处理数据，想提升性能只需增长设备便可，可是，OceanBase在每台设备上的性能还有很多提高空间；另外，OceanBase支持的功能、易用性、数据库生态相比业界标杆还有一些差距。

接下来，OceanBase将在两个重点方向上发力，一个是兼容Oracle数据库提供的各类功能，方便客户切换使用不一样的数据库，另外一个是提高OLAP处理能力，也就是数据分析挖掘等方面的能力，用同一套引擎同时支持OLAP与OLTP，完善OceanBase在大数据处理方面的能力。

后续，咱们还将开源本次TPC-C测试工具，但愿与业界同行多多交流，共同探讨数据库技术的发展与将来。

正文

网络上有不少介绍TPC-C benchmark的文章，并且某些数据库厂商还声称本身进行了TPC-C测试，还得到了单机百万级tpmC、分布式千万级tpmC等等。真实状况到底是怎样呢？

就像不少人知道的，国际事务性能委员会（TPC）组织是数十家会员公司建立的非盈利组织，TPC-C是TPC组织制定的关于商品销售的订单建立和订单支付等的基准测试标准，是数据库联机交易处理系统（OLTP）的权威基准测试标准。TPC-C有5种事务，每种事务有规定的比例，分别订单支付不低于43%，订单查询、订单发货和库存查询各不低于4%，其他则为订单建立(不高于45%)，tpmC值是订单建立事务每分钟执行的数量。

TPC-C benchmark测试必须经过TPC组织的审计（准确地讲是TPC-C组织承认的审计员的审计），经过审计的TPC-C的结果，其完整详实的测试报告（包括测试厂家、数据库版本、详细的软硬件配置、测试过程等）将公布在TPC组织的网站（ www.tpc.org ）上。没有经过TPC的审计而擅自声称本身经过了TPC-C测试、得到XXX tpmC，不只是侵权，也是不合法的。除了OceanBase，目前在TPC网站上尚未看到任何一个国产数据库的TPC-C benchmark的测试报告，不管是彻底自主研发的，仍是在开源基础上修改的。

为何TPC-C benchmark测试必需要经过TPC组织的审计呢？这还得从TPC组织的诞生提及。1980年代数据库联机交易处理系统即OLTP（Online Transactional Processing）出现后，极大地推进了诸如自动提款机（Automated teller transaction，ATM）等联机交易处理系统的发展。每一个数据库厂商都试图向客户证实本身的系统性能最好、处理能力最强，但因为没有统一的性能测试标准，更没有谁来监督性能测试的执行和结果发布，一方面客户没法在不一样系统之间进行比较，另外一方面数据库厂商各自的性能测试数据也没有足够的说服力。

1985年初，Jim Gray联合24位来自学术界和工业界的同仁发表了名为“A Measure of Transaction Processing Power”的文章，提出了一种在线事务处理能力的测试方法DebitCredit。DebitCredit定义了数据库性能benchmark的一些关键特征（ http://www.tpc.org/informatio... ）：

• 定义了被测系统的功能要求而不是软件硬件自己
• 规定了被测系统的扩展准则，即性能与数据量相匹配
• 规定被测系统的事务须要在指定时间内完成（好比95%事务在1s内完成）
• 把被测系统的总体成本归入性能benchmark

DebitCredit为数据库的联机交易处理系统性能创建了统一的、科学的衡量标准，后续相关的benchmark基本都以此为基础发展而来。然而一些厂商却删掉DebitCredit标准中的一些关键要求后进行测试以便得到更好的性能值（这种作法如今也被一些国内数据库厂商用在TPC-C benchmark测试上），这致使数据库的联机交易处理系统性能的衡量标准并无真正统一：若是说Jim Gray等人为数据库的联机交易处理系统benchmark制定的一个法律（DebitCredit），但却没有执法队伍来保障法律的执行。1988年TPC组织的创始人Omri Serlin（ http://www.tpc.org/informatio... ）成功地说服8家公司成立了非盈利的TPC组织，统一制定和发布benchmark标准并监督和审计数据库benchmark测试，状况才发生了根本的改变。

通过三十多年的发展，TPC组织的成员超过了20个，诞生和完善了数据库性能的多个benchmark标准，并被全世界接受。好比TPC-C的第一个版本是在1992年发布的，以后经历了屡次修订，以适应需求和技术的变化。为了防止厂商按本身的意愿篡改TPC-C标准进行测试以获得更高的性能值，TPC组织要求全部的TPC测试结果都要通过TPC组织承认的审计员的审计，审计员对测试的过程和结果进行详细的审核，审计经过后，审计结果连同完整的测试报告提交给TPC组织的Technical Advisory Board（TAB），TAB审核无异议后还将进行60天的公示，公示期间若有异议厂商须要证实本身的测试符合相应的TPC标准（必要时还须要再次运行benchmark测试程序）。

TPC-C是对商品销售支付等实际业务系统很好的抽象。在准备TPC-C测试的过程当中，咱们发现了OceanBase许多性能不优的地方，在对这些地方进行了优化和完善后，咱们发现OceanBase已经达到了今年（2019年）双11的性能优化目标：事实上，TPC-C五种事务中，占比最高的两种，订单建立（new order，占比45%）和订单支付（payment，占比43%），其实就对应了生产系统中的订单建立和订单支付。所以TPC-C模型看起来很简单，偏偏是这个模型对实际的联机交易处理作了很是好的抽象。

做为一个普遍接受的标准，TPC-C很是严谨，极大地杜绝了做弊：

首先，做为一个OLTP联机交易处理系统的benchmark，TPC-C要求被测数据库必须知足数据库事务的ACID，即原子性、一致性、隔离性和持久性，其中隔离性为可串行化隔离级别，持久性要求可以抵御任何单点故障等。很显然，这是对一个OLTP数据库的基本要求。在分布式环境下，TPC-C的两种主要事务，订单建立（new order）和订单支付（payment），分别有10%和15%的分布式事务（最多可能分布在15个节点上），事务的ACID对于分布式数据库是很大的挑战，尤为是可串行化的隔离级别，这也是至今鲜少分布式数据库经过TPC-C测试的主要缘由之一。国内有些厂商混淆分布式数据库的概念，把多个单机数据库堆在一块儿而号称分布式数据库，事实上，尽管每一个单机数据库都知足ACID，但这些堆放在一块儿的多个单机数据库做为一个总体并不知足ACID。

其次，TPC-C规定被测数据库的性能（tpmC）与数据量成正比，事实上真实业务场景也是如此。TPC-C的基本数据单元是仓库（warehouse），每一个仓库的数据量一般在70MB左右（与具体实现相关），TPC-C要求终端用户在选择事务类型时，须要按照规定的比例选择五种事务，终端用户每一个事务都有必定的输入时间（对每种事务分别固定）和必定范围的随机的思考时间（一个对数函数），根据这些要求，每一个仓库所能得到的tpmC上限是12.86（假设数据库的响应时间为0）。假设某系统得到150万tpmC，大约对应12万个仓库，按70MB/仓库计算，数据量约8.4TB，而TPC-C同时要求系统具有60天、天天压测8小时的存储容量，所以系统的存储容量可能要30TB或更多，而某些厂商用几百或几千个仓库所有装入内存，无视单个仓库的最大tpmC上限，而后号称得到百万tpmC，不只不符合大多数真实业务场景，并且明显违反了TPC-C规范，就像当年TPC组织成立以前一些公司的所做所为同样。

第三，TPC-C要求被测数据库可以以平稳的性能长期地运行。测试时，去掉启动预热（ramp up）和结束降速（ramp down）时间后，被测数据库至少要性能平稳地（steady state）运行8小时，其中性能采集时段（很多于2小时）内的性能累积波动不得超过2%。众所周知，各类计算机系统在极限压力下性能会产生较大的波动并可能被压垮而崩溃，为了不被压垮，实际生产环境历来不会让系统处于极限压力，TPC-C这个规定正是从实际生产需求出发的。此外，TPC-C要求被测数据库长时间运行，一样是实际生产系统的要求。某些数据库厂商让数据库在很短期内冲击性能的一个尖峰值，既没有保证数据库在较长时间内稳定运行，更谈不上性能波动不超过2%，但却声称本身的数据库达到了这个尖峰性能。本次benchmark测试中，OceanBase作到了8小时性能波动低于0.5%。

第四，TPC-C要求被测数据库的写事务的结果必须在必定时间内数据落盘（指数据库数据，不是日志，事实上redo log在事务提交前就落盘了），对于具有checkpoint功能的数据库，checkpoint的间隔不得超过30分钟，checkpoint数据持久化的时间不得超过checkpoint间隔。咱们理解这是为了保证数据库系统在掉电等异常状况下有较短的故障恢复时间。传统数据库的数据以数据块(例如4KB/8KB的page/block)为基本单位，作到这个是把脏页刷盘。但OceanBase并不是如此，这是由于，第一OceanBase是多副本（本次测试是3副本）的跨机器部署，单机器异常的状况下都可以当即恢复（RTO=30s）且数据无损（RPO=0），并不依赖于写事务的数据落盘；第二个缘由：OceanBase是“基线数据在硬盘+修改增量数据在内存”的结构，设计上是修改增量数据一天落盘一次（即每日合并，可根据业务量的增长而自动增长每日合并次数），实际生产系统不须要也不依赖数据在较短期（好比30分钟）内落盘。在TPC-C benchmark测试中，OceanBase设置了checkpointing，保证全部checkpoint的间隔小于30分钟，并使得checkpoint数据持久化的时间小于checkpoint间隔，以符合TPC-C规范。

第五，业务定向优化（profile-directed optimization，PDO）能够提高软件的性能，TPC-C也容许使用PDO，但有一些限制，好比采用PDO优化的版本须要在客户使用，数据库厂家须要对PDO优化的版本提供技术支持等。为了不可能出现的异议，OceanBase没有使用PDO。

最后，TPC-C规范虽然十分严格，但依然鼓励新技术和新方法的使用，好比本次OceanBase的TPC-C benchmark测试，就没有像以前的TPC-C benchmark同样购买物理服务器和存储，而是租用了阿里云公有云的ECS虚拟机，这不只使得扩容/缩容垂手可得，还可按需租赁而极大下降实际测试成本。