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

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测试工具,希望与业界同行多多交流,共同探讨数据库技术的发展与未来。

正文

2019 年 10 月,阿里巴巴 / 蚂蚁金服从零开始完全自主研发的 OceanBase 分布式关系数据库通过了国际事务性能委员会 (Transaction Processing Perfor- mance Council,TPC) 的联机交易处理系统的 TPC-C benchmark 的严格审计, 打破了由 Oracle 保持了九年之久的 TPC-C benchmark 的世界纪录,把 tpmC 值由 3 千多万提升一倍到了 6 千多万。中国数据库系统经历了几十年的发展和积 累,终于迎来了 OceanBase 登顶 TPC-C benchmark 这个关键的基准测试,参 见:http://www.tpc.org/tpcc/results/tpcc_results.asp?print=false&orderby=tp- m&sortby=desc。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 组织的网站(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 的一些关 键特征(tpc.org/information/abo):

  • 定义了被测系统的功能要求而不是软件硬件本身
  • 规定了被测系统的扩展准则,即性能与数据量相匹配
  • 规定被测系统的事务需要在指定时间内完成(比如 95% 事务在 1s 内完成)
  • 把被测系统的整体成本纳入性能 benchmark

DebitCredit 为数据库的联机交易处理系统性能建立了统一的、科学的衡量标 准,后续相关的 benchmark 基本都以此为基础发展而来。然而一些厂商却删掉 DebitCredit 标准中的一些关键要求后进行测试以便获得更好的性能值(这种做法现 在也被一些国内数据库厂商用在 TPC-C benchmark 测试上),这导致数据库的联 机交易处理系统性能的衡量标准并没有真正统一:如果说 Jim Gray 等人为数据库的 联机交易处理系统 benchmark 制定了一个法律(DebitCredit),但却没有执法队伍 来保障法律的执行。1988 年 TPC 组织的创始人 Omri Serlin(tpc.org/information/who)成功地说服 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 虚拟机,这不仅使得 扩容 / 缩容轻而易举,还可按需租赁而极大降低实际测试成本。

编辑于 2019-10-14