阿里核心技术成员解读自研数据库 OceanBase

本文作者是 OceanBase创始人阳振坤、OceanBase技术专家曹晖、OceanBase资深技术专家陈萌萌、OceanBase资深技术专家潘毅、OceanBase资深技术专家韩富晟、OceanBase高级技术专家赵裕众。本文原载于阿里技术微信公众号（ali_tech），AI开发者获授权转载。

前言

蚂蚁金服自主研发的金融级分布式关系数据库 OceanBase，不久前在被誉为“数据库领域世界杯”的 TPC-C 基准测试中打破了由美国公司 Oracle（甲骨文）保持了 9 年之久的世界记录，成为首个登顶该榜单的中国数据库产品。

很多人都好奇 OceanBase 究竟有何能耐取得这个结果，这篇文章也许能够告诉我们答案。

阿里妹导读：TPC-C是TPC组织（国际事务性能委员会）制定的关于商品销售的订单创建和订单支付等的基准测试标准，是数据库联机交易处理系统的权威基准测试标准。

蚂蚁金服自研的分布式关系数据库OceanBase获得TPC-C测试第一名后，引起了大量关注，今天，我们邀请了OceanBase的核心研发人员对本次测试做专业的技术解读。

一、OceanBase如何做TPC-C测试

有机会挑战TPC-C测试相信是所有数据库内核开发人员的梦想，但TPC-C测试标准非常复杂。由于这是国产数据库同时也是分布式数据库第一次冲击这个榜单，为了完成这次挑战，OceanBase团队前后准备时间超过一年。

前期准备

TPC-C测试首先需要找到官方唯一认证的审计员来对测试进行审计监察，他们对这次OceanBase的审计也相当重视，全世界仅有的三个审计员这次就有两个参与到测试审计工作中。

测试系统

目前市面上基本找不到一个能够开箱即用的符合TPC-C标准的测试工具。以目前各个厂商PoC环境最常遇到的benchmarksql为例，可以说只是模拟TPC-C压力模型的压测工具，连最基本的数据导入都不合规，大量的字符串生成未保证全局随机，缺乏压测阶段最基本的think time、keying time这些基本配置导致极小的数据量就能跑出很高的tpmC，最关键的是它将测试模型大大简化为工具直连DB测试，完全没有遵守TPC-C测试标准规范。

在标准定义中，测试系统可以分为RTE（Remote Terminal Emulator）和SUT两部分，但实际上从角色上看SUT可以进一步拆分为两部分：WAS(web application server)和DB Server。

这其中DB Server是每个测试厂商的数据库服务；RTE扮演的角色是测试模型中的客户终端，事务的触发、RT的统计等都在这里完成；标准明确要求每一个用户terminal都必须保持一个长连接，显然在海量Warehouse时DB是无法承受这么多连接的，WAS就是RTE和DB之间桥梁，标准定义可以使用连接池，在保证对应用透明的情况下它可以做所有请求的管理。

这三个角色中，WAS和DB是必须商业化可购买且提供支付服务的，OceanBase这次是使用了OpenResty作为WAS供应商。而RTE则一般由各个参测厂商自行根据标准实现，但所有实现代码必须经过审计的严格审计，OceanBase这次完整的实现了一整套完全合规的RTE，并且支持在大规模测试系统中部署。要知道在实际的TPC-C测试流程中，不只是对DB端能力的考验，RTE端同样存在极大的资源消耗和压力。以这次6088w tpmC测试结果看，我们一共在64台64c128G的云服务器上运行了960个RTE客户端，来模拟总计47942400个用户terminal，最后还需要基于这么多RTE统计结果进行一致性和持久化审计验证。

虽然只是测试客户端，但RTE的中同样有大量的可能导致最后测试失败的小细节，比如大家可能注意不到的所有事务都因为用了web端模拟终端后需要增加的100毫秒rt，又比如为了模拟用户终端输出显示的100毫秒延时。

测试规划

TPC-C从来都不是一个简单的测试，它很科学并没有给出强制的软硬件配置，只是给出测试规范和各种审计检查限制标准，所有数据库厂商可以根据自己的特性充分调优来拿到一个最好的性能或性价比。但这同时也对所有参测厂商提出了一个巨大的难题，如何对已有的资源进行合理规划来保证顺利完成一次对TPC-C榜单的冲击。

1. 硬件选型，这里不仅要对数据库服务器选型，还需要对RTE以及WAS服务器选型。这之前需要先期进行大量的测试和调优，来摸出在保证性价比的前提下每个角色服务器的资源配置是多少刚好。这次OceanBase测试最大的优势就是全部使用了云化资源，我们不需要再关注最底层机房、机柜、布线这些细节，只需要通过快速的规格调整来拿到我们需要的机型。

2. 参数选择，如何选择合适的配置参数是一个非常令人头疼的问题。举个例子，一个最典型的问题就是我们最终要跑多少个Warehouse，每个数据库服务器上承载多少Warehouse。TPC-C标准为了尽可能模拟真实业务场景，通过每个事务限定不同的think time和keying time保证了一个warehouse的数据最多能够提供12.86tpmC值，因此数据库厂商想要拿到更高的成绩就必须装载更多的warehouse，但是另一方面单机的存储空间又有预计80%（经验值）需要预留给60天增量存储。在分布式数据库架构下，为了能让每个数据库服务器跑满又能充分利用本地存储空间，让每个服务器的CPU、内存、IO能力、存储空间的资源最大化利用，我们前后调整优化了近一个月时间。

性能压测

最受关注的性能压测部分在TPC-C标准中规定了以下三个状态：

1. Ramp-up，标准允许每个数据库进行一定时间的预热来达到稳定状态，但是ramp-up阶段的所有配置必须和最终报告配置保持一致。

2. Steady state，保证ACID及可串行化隔离级别前提下，数据库需要能够以最终报告tpmC值在稳定状态无任何人工干预前提下保持运行8小时以上，每隔半小时需要完成一次checkpoint。

3. Measurement Interval，标准规定了需要能够支持8小时稳定运行，但性能采集阶段只需要保设置2小时以上即可。这个阶段还需要保证累计tpmC波动不能超过2%，并且必须完成至少4个以上的checkpoint。

所以之前一般数据库进行性能压测一般是以下的流程，先进行一段时间的预热到达稳态，等待稳定运行一段时间并完成一个checkpoint后开始进入2小时的性能采集阶段。

而OceanBase这次是使用了TPC-C测试迄今以来最严苛的一个流程来完成这个性能测试的，我们首先使用了10分钟进行预热，然后在6088w tpmC稳态保持运行25分钟并完成一个检查点，再继续跑了完整的8小时性能压测采集阶段，总耗时超过8个半小时，中间性能最大波动不到0.5%，最终结果也让审计员异常兴奋。

整个性能测试前后，审计员还需要进行数据及事务随机分布检查，简单说来就是大量全表扫描和统计sql，最大的一条sql需要访问超过万亿行的order_line表结果，可以算是TPC-C里的“TPC-H测试”。现场审计第一次遇到这些sql时我们也大量的出现sql执行超时情况，但后续基于OceanBase2.2版本最新的并行执行框架我们还是很快搞定了这些大sql，所以要顺利完成TPC-C测试并不能只是一个偏科生，保持自身没有短板才是真正意义上的通用关系数据库，从这点上说Oracle仍是OceanBase学习的榜样。

ACID

1. A测试，通过提交和回滚payment事务来确认数据库对原子性支持，和I测试一样，OceanBase的A测试跑了两遍，分别应对分布式事务和本地事务。

2. C测试，标准里的C测试一共包含12个case，前四个是必须要完成验证的，每个case其实都可以认为是一个复杂的大sql，而对于分布式数据库来说重点是需要始终保证全局一致。

3. I测试，标准要求TPC-C模型里5个事务除了StockLevel事务都需要满足最高的可串行化隔离级别，并构造了9个case来验证隔离性。对于分布式数据库而言，这个要求并没有那么容易实现，所幸OceanBase在2.x版本中提供了全局时间戳的支持，所以的I测试都在审计员的特别要求下跑完了全本地和全分布式两种模式的两轮测试，这也应该是TPC-C测试中首次有数据库厂商需要做两轮I测试跑18个case的，也许在不久后TPC-C标准定义也会因为OceanBase的这次测试而带来针对分布式数据库的相关更新。

4. D测试，OceanBase在这个场景其实相对传统数据库是有较大天生优势的，OceanBase每个Warehouse数据有两份数据三份日志，通过paxos强同步，保证RPO=0的前提下只有秒级RTO。

面对D测试标准中最严格的一项-部分存储介质永久故障，OceanBase还使用了最严苛的测试场景，在使用超出标准要求的全量6000W tpmC压力下，我们强行销毁了一个云服务器节点，整体tpmC在两分钟内恢复到6000w并持续跑到测试时间结束，这些表现都是远远超过TPC-C规范要求的，相比较而言其它传统数据库基本面对有日志的存储介质故障D测试场景都是依赖磁盘RAID来恢复，OceanBase应该算是首个没有raid完全依赖数据库自身恢复机制完成全部D测试的数据库厂商了。

同时我们在D测试中是连续杀掉了两台服务器节点，首先杀掉一个数据节点，等待tpmC恢复且稳定5分钟后，再次杀掉了rootserver leader节点，tpmC仍然快速恢复。

二、TPC-C基准测试之SQL优化

对TPC-C有所了解人都知道，TPC-C是一个典型的OLTP (On-Line Transaction Processing) 场景测试，考察的是数据库在高并发压力场景下的事务处理能力，最终的性能指标以tpmC(transaction per minute，也即每分钟系统处理TPC-C模型中的new order事务的数量)和平均到每tpmC的系统成本作为衡量标准。在OLTP场景中，每条请求的响应时间都是极短的。因此，各个数据库厂商在进行TPC-C测试时，都会尽一切可能将每一个操作时间压缩到最短，不夸张的说，在TPC-C的测试中，一些关键操作的优化往往需要细化到CPU指令级。

在进入我们的主题前，我们先来谈谈TPC-C中的事务模型，主要分为五种事务，订单创建、订单支付、订单查询、订单发货以及库存查询，这五种事务按照一定的比例发生，测试最终衡量的是每分钟订单创建事务的执行个数。大家知道，每一个数据库的事务，其实就是由一定逻辑关系关联的若干条SQL语句组成，他们在一个事务中，要么全部成功，要么全部失败，这个在数据库中称为“原子性”，也就是ACID中的“A”。那么TPC-C中的一个事务的耗时大约是多久呢？看一下报告就很清楚了——只有十几个毫秒。考虑到一个事务由多条SQL构成，那么每一条SQL的平均耗时都不到1毫秒！

在C/S（client-server）模型中，一条SQL语句从发起到执行完成需要经历从客户端输入、网络传输、SQL优化、执行、结果返回到客户端这样一个流程。而具体每一条SQL的执行可能只是做一个字段的更新，所需要的执行时间是非常短暂的，从整个链路的角度来看，大量的时间会花费在与客户端的交互过程中，造成资源的浪费和耗时的增加。那么如何解决这个问题的呢？答案就是使用存储过程。

存储过程

所谓“存储过程”就是数据库为用户提供的一种面向过程的编程语言。基于这种语言，用户可以将应用程序的逻辑封装为一个可调用的过程（procedure）存放在数据库中并随时进行调用。通过这种方式，用户可以将本来需要与数据库进行多次交互才能完成的工作通过一次交互完成，省去了中间网络的传输和等待时间（参见图1）。假如一条事务的网络开销平均是30%，也就是说30%的CPU都花在了网络的收发和解析上。那么在6千万规模tpmC测试中节省下来30%的CPU资源换算成系统处理能力是惊人的。使用存储过程还可以带来事务响应时间的下降，导致数据库内核中事务锁的临界区缩短，间接的提升了系统CPU利用率，整个吞吐量也随之提高。存储过程在缩短应用端的等待耗时上同样有很大作用。

图1 传统的C/S模型与使用存储过程的执行方式对比

在TPC-C中，存储过程对于整个系统的执行效率提升是至关重要的。OceanBase 的2.2版本不仅全面支持了存储过程，而且对存储过程的执行效率做了大量极致的优化。

编译执行

存储过程作为一种面向过程的高级语言，需要转换成机器码才能够执行。这个过程一般可以分为“编译执行”和“解释执行”两种，一般来说，编译执行相比解释执行有代码优化充分、执行效率高等特点。OceanBase利用近两年逐渐成熟的LLVM编译器框架实现了一个支持存储过程的编译器，通过动态编译（Just-in-Time Compilation）的方式将存储过程翻译成高效的二进制可执行代码，在执行效率上获得了数量级的提升。同时，过程中LLVM框架将存储过程转换为与机器无关的中间代码，使得存储过程也自然而然地获得了跨平台的编译执行能力，LLVM内置的优化过程确保我们在各种不同的硬件平台上都可以获得正确、高效的可执行代码。

Array Binding

另外一个在TPC-C测试中发挥了重要作用的功能就是对DML语句进行批量处理的能力，在Oracle中该功能也称为“Array Binding”。一条SQL在数据库中的执行过程大致上可以分为“计划生成”和“执行”两个阶段。尽管我们对SQL的执行计划做了高速缓存，但找到一个合适的执行计划在整个执行过程中仍然是比较耗时的一个部分。那有没有办法省去这个时间呢？当一组SQL的执行计划完全一样而只有执行参数不同时，在存储过程中我们可以通过特定的语法将他们的执行做成一个批量处理的过程，此时“计划生成”只需要做一次即可，这就是所谓的“Array Binding”。

在Array Binding中，数据库会首先找到需要使用的计划，然后执行该计划，并在每次执行完毕后，重新执行参数绑定（binding）的过程。打个比方，这就像是在一个C语言的for循环中，反复赋值而不是重新定义一个数据结构。Array Binding的使用受用户控制，需要在存储过程中使用FORALL关键字来触发这一功能，在TPC-C的测试过程中，我们多次使用了Array Binding来提升系统的处理能力，效果非常明显。

Prepared Statement与执行计划缓存

Prepared Statement是一种二进制的请求交互协议，可以大大降低系统的交互成本。OceanBase不仅支持用户程序与数据库间使用Prepared Statement, 也支持在存储过程引擎调用SQL引擎执行时使用这种交互方式。存储过程在对SQL进行一次Prepare操作并获取唯一id后, 后续的每次执行仅需要传入该id和对应的参数,系统可以通过高速缓存找到对应的存储过程或SQL计划开始执行。该过程相比使用SQL文本的交互方式，省去了大量请求文本解析的CPU开销。

OceanBase内部实现了高速缓存来缓存存储过程的可执行代码及SQL执行计划,不同参数的存储过程和SQL可以通过这一高速缓存快速获取需要的执行对象, 耗时一般在几十微秒以内, 有效避免了重新编译带来的毫秒级的延迟和CPU消耗。

可更新视图

在OLTP场景中，通过减少应用与数据库的交互次数来实现性能提升的例子很多，可更新视图就是其中之一。我们常见的数据库视图通常是只读的，通过定义视图，用户可以定义自己感兴趣的数据以及其获取接口，但视图同时也可以作为更新操作的入口，比如在TPC-C的new order创建场景中，应用需要得到商品信息，更新库存并得到更新后的值。一般可以通过两条SQL实现这一过程：

select i_price,i_name, i_data from item where i_id = ?;

UPDATE stock

SET s_order_cnt = s_order_cnt + 1,

s_ytd = s_ytd + ?,

s_remote_cnt = s_remote_cnt + ?,

s_quantity = (CASE WHEN s_quantity< ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?

WHERE s_i_id = ?

AND s_w_id = ?

RETURNING s_quantity, s_dist_01,

CASE WHEN i_data NOT LIKE'%ORIGINAL%' THEN 'G' ELSE

(

CASE WHEN s_data NOT LIKE '%ORIGINAL%' THEN 'G'ELSE 'B' END