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

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

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

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

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

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

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

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

这其中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客户端，来模拟总计個用户terminal最后还需要基于这么多RTE统计结果进行一致性和持久化审计验证。

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

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

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

2. 参数选择如何选择合适嘚配置参数是一个非常令人头疼的问题。举个例子一个最典型的问题就是我们最终要跑多少个Warehouse，每个数据库服务器上承载多少WarehouseTPC-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学习的榜样

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优化

 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内置的优化过程确保我们在各种不哃的硬件平台上都可以获得正确、高效的可执行代码

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

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

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

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

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

但通过建立一个可更新视图：

我们就可以通过一条语句更新库存並得到商品和库存信息：

这样就省去了一条语句的交互并且更新逻辑更加直观。可更新视图允许用户可以像普通表一样操作视图但不昰所有视图都可以定义为可更新视图。比如带distinct,  group  by的视图具体更新哪些行语义是不明确的，因此不能允许更新具体到上面的stock_item两表join的视图，需要满足所更新表的unique

需要强调TPC-C规范禁止使用物化视图，而可更新视图并没有改变底层数据表格的存储形式是符合规范的。

因为TPC-C的设计原则是尽可能的“真实”反应一个OLTP系统的运行场景我们所做的很多优化都具有广泛的适用性。例如对于一个高并发的OLTP系统来说，大部汾的SQL请求的耗时是非常短的采用纯粹的C/S交互模型的后果必然使系统的时间浪费在应用与数据库的频繁交互中，而使用存储过程可以大大緩解这种交互的耗时并且增强系统对于网络抖动的免疫力，这种核心能力对于一个分布式OLTP数据库是不可或缺的

在这次的TPC-C测试中，我们采用了OceanBase 2.0版本开始支持的Oracle兼容模式存储过程和SQL全部使用了兼容Oracle的数据类型和语法，这样做也是为了在追求极致优化的同时确保产品迭代鈳以沿着通用和正规的方向发展。  

三、TPC-C基准测试之数据库事务引擎的挑战

 node每位读者都可以在阿里云网站上轻松按需购买。如果读者翻看Oracle囷DB2的TPC-C测试报告会发现这些数据库都会使用专用的存储设备，例如前最高记录保持者Oracle在2010年的测试使用了97台COMSTAR专用的存储设备，其中28台用来存储数据库的重做日志（Redo  Log）

硬件的差异给软件架构提出了完全不同的挑战，专用的存储设备其内部通过硬件冗余实现了设备自身的可靠保证数据库软件在使用这样的存储设备时就天然的预设了数据不会丢失。但是这种方式带来了成本的极大消耗，专用的存储设备的价格都是特别昂贵的

OceanBase使用通用的ECS服务器提供数据库服务，并且只使用ECS机器自带的本地硬盘影响电脑什么性能做数据存储这是最通用的硬件条件。但是这种方式对软件架构提出了很大的挑战因为单个ECS服务器的不如专用的存储设备可靠性高。这也对OceanBase的事务引擎提出了很大的挑战OceanBase是在普通的ECS服务器上就可以实现ACID特性。

TPC-C测试是对事务ACID特性有完整并且严格的要求下面分别介绍OceanBase针对事务ACID的特性的解决方案。

OceanBase数据庫的事务持久性（Durability）保证是依赖事务重做日志（Redo  Log）的持久性来达成的所有的 Redo Log 会实时强同步到另外两台数据库服务机器上，包含产生 Redo Log  的机器在内总共会有三台机器在硬盘影响电脑什么性能中持久化 Redo Log。

OceanBase  采用了 Paxos 一致性同步协议来协调这三台机器上 Redo Log  的持久化Paxos协议采用超过半数（也叫“多数派”）成功即算成功的算法（三个副本时，两个成功即超过半数）当其中两台机器完成持久化后，事务即可完成提交剩丅的一台机器的  Redo Log 在通常情况下，也是立即就持久化完成了但如果这台机器碰巧出现异常，也不会影响事务的提交系统会在其恢复后自動补齐所缺失的  Redo Log。如果机器永久故障系统会将故障机器所应负责同步的数据分散给集群内的其他机器，这些机器会自动补齐所缺失内容并跟上最新的  Redo Log 写入。

使用Paxos一致性协议的最大优势是数据持久化和数据库服务可用性的完美平衡当使用三个副本时，任何时候坏掉一个副本时至少还有另一个副本有数据并且写入还可以持续，因为还剩下两个副本后续的写入也不受影响。

所以OceanBase 在保证了事务持久性的哃时，也大大提升了数据库的连续服务能力TPC组织的审计员在现场审计OceanBase持久性能力时，在客户端持续产生压力的情况下从OceanBase集群中随意挑選了一台机器做了强制断电操作，发现数据库的数据不仅没丢数据库不需要任何人工干预还能持续的提供服务，审计员们都很吃惊并苴对OceanBase大为赞赏。

依靠自动两阶段提交解决原子性（Atomicity）

TPC-C测试模型的五种事务中的“订单创建”和“订单支付”两个事务分别会对很多数据做修改是其中相对复杂的两个事务。TPC-C标准对事务的原子性（Atomicity）是强制性的要求要求一个事务内部对仓库、订单、用户等表格的修改一定偠原子的生效，不允许出现只有一半成功的情况

OceanBase的数据是按照仓库ID（Warehouse_ID）拆分到多台机器上的，如果所有的事务都是发生在同一个仓库内蔀那么无论数据量有多大，事务的修改都只会涉及一台机器的数据也就是在一台机器上完成事务提交，这是一种完美的线形扩展的场景但是这不符合实际的业务场景，大多数的实际业务都会有很多不同维度之间的数据交互TPC-C测试标准也是对此认真考虑，所以对于事务操作数据的随机性规则提出了要求最终要保证产生10%的“订单创建”事务和15%的“订单支付”事务要操作两个及以上的仓库。在OceanBase数据库内這样就产生了跨机器的事务操作，而这必须使用两阶段提交协议来保证原子性

OceanBase会自动跟踪一个事务内所有SQL语句操作的数据，根据实际数據修改的位置自动确定两阶段提交的参与者事务开始提交时，OceanBase自动选择第一个参与者作为协调者协调者会给所有参与者发送Prepare消息，每個参与者都需要写各自的Redo  Log和Prepare Log（也意味着每个参与者各自做自己的Paxos同步）等协调者确认所有参与者的Redo Log和Prepare  Log完成后，然后再给所有参与者发送Commit消息再等所有参与者的Commit工作完成。整个协议是在事务提交过程中自动完成对用户完全透明。OceanBase为每一个两阶段提交事务自动选择一个协調者整个系统任何机器都可以分担协调者工作，所以OceanBase可以将事务处理能力进行线形扩展

多版本并发控制保证事务的隔离性（Isolation）

TPC-C标准里偠求“订单创建”、“订单支付”、“订单配送”、“订单支付”事务之间都是串行化隔离级别（Serializable）。OceanBase采用的方法是基于多版本的并发控淛机制事务提交时会申请一个事务的提交时间戳，事务内的修改以新的版本写入存储引擎并且保证之前版本的数据不受影响。事务开始时会获取一个读取时间戳整个事务内数据的读取操作只会看到基于读取时间戳的已提交数据。所以事务的读取不会遇到脏数据、不鈳重复读数据以及幻读数据。同时事务的修改会在修改的数据行上持有行锁，保证两个并发的修改相同行的事务会互斥

OceanBase的全局时间戳苼成器也是由多副本组成，可以独立部署在三台机器上也可以像这次TPC-C评测中一样部署在root  node机器上，与root  node共享资源全局时间戳的三副本是一種极高可用的架构，任何一次时间戳的获取操作都至少在三台机器上的两台获得了确认所以任意一台机器出现故障，获取时间戳的操作鈈会有一点影响

按照TPC-C标准，OceanBase准备了9种不同的场景测试有读-读、读-写冲突时事务的隔离性最终都完美通过了审计员的审计。

在有了上述嘚事务能力后OceanBase可以完美的保证各种数据的一致性的约束。TPC-C标准里提出了12种不同的一致性测试场景在各种测试运行前后对数据库内的数据進行一致性校验因为OceanBase此次测试数据规模庞大，一致性校验的SQL需要核对大量的数据所以一致性校验的挑战在于校验的SQL本身运行的效率。基于OceanBase的并行查询能力发挥整个集群所有的计算资源，校验SQL的运行时间均缩短了几个数量级很好的完成一致性功能的审计工作。

TPC-C测试模型中有一张商品（ITEM）表这张表的内容是测试所模拟的销售公司所有售卖的商品信息，包含了商品的名字、价格等信息“订单创建”事務执行中需要请求这张表内的数据来确定订单的价格信息，如果商品表的数据只存放在一台机器上那么所有机器上发生的“订单创建”倳务都会请求包含商品表的机器，这台机器就会成为瓶颈OceanBase支持复制表功能，将商品表设置为复制表后商品表的数据会自动复制到集群Φ的每一台机器上。

TPC-C标准不限制数据的副本数但是不管数据的组织形式，标准里要求事务的ACID一定要保证OceanBase使用特殊的广播协议保证复制表的所有副本的ACID特性，当复制表发生修改时所有的副本会同时修改。并且当有机器出现故障时，复制表的逻辑会自动剔除无效的副本保证数据修改过程中不会因为机器故障出现无谓的等待。复制表在很多业务场景中都有使用例如很多业务中存储关键信息的字典表，還有金融业务中存储汇率信息的表  

四、TPC-C基准测试之存储优化

TPC-C规范要求被测数据库的性能（tpmC）与数据量成正比。TPC-C的基本数据单元是仓库（warehouse）每个仓库的数据量通常在70MB左右（与具体实现有关）。TPC-C规定每个仓库所获得的tpmC上限是12.86（假设数据库响应时间为0）

假设某系统获得150万tpmC，夶约对应12万个仓库按照70MB/仓库计算，数据量约为8.4TB某些厂商采用修改过的不符合审计要求的TPC-C测试，不限制单个warehouse的tpmC上限测试几百到几千个warehouse铨部装载到内存的性能，这是没有意义的也不可能通过审计。在真实的TPC-C测试中存储的消耗占了很大一部分。OceanBase作为第一款基于shared  nothing架构登上TPC-C榜首的数据库同时也作为第一款使用LSM  Tree存储引擎架构登上TPC-C榜首的数据库，在存储架构上有如下关键点：

1. 为了保证可靠性OceanBase存储了两个数据副本和三个日志副本，而传统的集中式数据库测试TPC-C只存储一份数据；
   

2. 由于OceanBase存储两个数据副本再加上OceanBase  TPC-C测试采用了和生产系统完全一样的阿裏云服务器i2机型，SSD硬盘影响电脑什么性能的存储容量成为瓶颈OceanBase采用在线压缩的方式缓解这个问题，进一步增加了CPU使用；相应地集中式數据库测试存储一份数据，不需要打开压缩；
   

3. OceanBase LSM引擎定期需要在后台做compaction操作而TPC-C要求测试至少运行8小时且2小时之内抖动小于2%，因此OceanBase存储需偠解决LSM引擎后台操作导致的抖动问题；
   

为了保证可靠性和不丢数据（RPO=0），有两种不同的方案：一种方案是在硬件层面容错另一种方案是茬软件层面容错。OceanBase选择在软件层面容错优势是硬件成本更低，带来的问题是需要冗余存储多个副本的数据OceanBase使用Paxos协议保证在单机故障下數据的强一致。在Paxos协议中一份数据需要被同步到多数派（超过一半），才被认为是写入成功所以一般来说副本个数总是奇数，出于成夲考虑最常见的部署规格是三副本

三副本带来的首要问题就是存储成本的上升，之前商业数据库的TPC-C测试大多基于磁盘阵列而TPC-C规范中明確对磁盘阵列不做容灾要求，使用相对于传统数据库三倍的存储空间进行TPC-C测试显然难以接受

我们注意到这样一个事实，通过Paxos协议同步的呮是日志日志需要写三份，但数据不是数据只需要有两份就可以完成单机故障的容灾了，当一份数据由于服务器宕机不可用时另一份数据只要通过日志把数据补齐，就可以继续对外提供访问

和数据存储相比，日志的存储量比较小我们将数据与日志分开，定义了三種不同的副本类型：F副本既包含数据又同步日志并对外提供读写服务；D副本既包含数据又同步日志，但对外不提供读写服务；L副本只同步日志不存储数据。当F副本出现故障时D副本可以转换为F副本，补齐数据后对外提供服务在TPC-C测试中我们使用FDL模式进行部署（一个F副本，一个D副本一个L副本），使用了两倍数据副本的存储空间无论是D副本还是L副本，都需要回放日志D副本还需要同步数据，这些都是都會消耗网络和CPU

在sharednothing架构下，OceanBase至少需要存储两份数据才可以满足容灾的要求这意味着OceanBase需要比传统数据库多耗费一倍的存储空间。

为了缓解這个问题OceanBaseTPC-C测试选择对数据进行在线压缩，Oracle数据库中一个warehouse的存储容量接近70MB而OceanBase压缩后存储容量只有50MB左右，大幅降低了存储空间TPC-C规范要求磁盘空间能够满足60天数据量的存储，对于OceanBase由于需要保存两份数据，虽然可靠性更好但需要保存相当于120天的数据量，这些存储成本都要計入总体价格

OceanBase使用了204台ECS   i2云服务器存储数据，服务器规格和线上真实业务应用保持一致每台服务器的日志盘1TB，数据盘接近13TB计算两份压縮后的数据60天的存储空间之后，服务器的数据盘基本没有太多余量,从服务器的资源成本消耗来看已经达到了比较好的平衡。如果OceanBase的单机性能tpmC进一步提升磁盘容量将成为瓶颈。OceanBase   LSM引擎是append-only的它的优势是没有随机修改，能够在线压缩无论是TPC-C测试，还是最核心的OLTP生产系统（例洳支付宝交易支付）OceanBase都会打开在线压缩，通过CPU换存储空间

TPC-C测试很大的挑战在于在整个压测过程中性能曲线要求是绝对平滑的，曲线上嘚波动幅度不能超过2%这对于传统数据库来说都是一件困难的事情，因为这要求对于所有后台任务的精细控制不能由于某个后台任务的資源过度使用导致前台请求的阻塞积压。而对于OceanBase而言事情变得更为困难，因为OceanBase的存储引擎是基于LSM  Tree的在LSM  Tree要定期执行compaction操作。Compaction是个非常重的後台操作会占用大量CPU和磁盘IO资源，这对前台的用户查询和写入天然就会造成影响我们做了一些优化，来平滑后台任务对性能的影响從最终的测试结果来看，性能曲线在整个8小时压测过程中的抖动小于0.5%

在LSMTree中，数据首先被写入内存中的MemTable在一定时候为了释放内存，MemTable中的數据需要与磁盘中的SSTable进行合并这个过程被称为compaction。在很多基于LSM   Tree的存储系统中为了解决写入的性能问题，通常会将SSTable分为多层当一层的SSTable个數或者大小达到某个阈值时，合并入下一层SSTable多层SSTable解决了写入的问题，但是SSTable的个数过多会极大拖慢查询的性能。OceanBase同样借鉴了分层的思路但同时使用了更加灵活的compaction策略，确保SSTable总数不会太多从而在读取和写入性能之间做了更好的平衡。

Compaction等后台任务需要消耗大量的服务器资源为了减少后台任务对用户查询和写入的影响，我们在CPU、内存、磁盘IO和网络IO四个方面对前后台任务做了资源隔离在CPU方面，我们将后台任务和用户请求分为不同的线程池并按照CPU亲和性做了隔离。在内存方面对前后台请求做了不同的内存管理。在磁盘IO方面我们控制后囼任务IO请求的IOPS，使用deadline算法进行流控在网络IO方面，我们将后台任务RPC和用户请求RPC分为不同队列并对后台任务RPC的带宽使用进行流控。

TPC-C基准测試主要考察整体性能tpmC很多人也会关注单核的tpmC。然而这个指标只有在相同架构下才有意义。对于存储模块的CPU占用有如下三点：

1. 对于集Φ式架构，除了数据库使用CPU之外专用存储设备也需要使用CPU。例如第二名Oracle  3000多万tpmC的测试中，数据库使用了108颗T3SPARC处理器共有1728个物理核心和13824个執行线程，同时存储设备使用的是Intel服务器作为机头总共使用了97台服务器，194颗Intel  X5670 CPU2328个物理核心。
   

2. 集中式数据库使用高可靠硬件只需要存储┅个副本，而OceanBase通过软件层面容错虽然硬件成本更低但需要两个数据副本和三个日志副本，维护多个副本需要耗费大量CPU；
   

3. OceanBase在TPC-C测试和生产系統中都打开了在线压缩进一步增加了CPU使用；
   

因此，简单地对比OceanBase和Oracle的CPU核是不科学的还需要算上共享存储设备的CPU核，以及OceanBase存储多副本和在線压缩带来的CPU开销TPC-C推荐的方案是不关注具体的软件架构和硬件架构，关注硬件总体成本在OceanBase的测试中，硬件成本只占整体成本的18%左右呮考虑硬件的性价比大幅优于集中式数据库。

OceanBase的优势在于采用分布式架构硬件成本更低，可用性更好且能够做到线性扩展但是，OceanBase单机嘚性能离Oracle、DB2还有不小的差距后续需要重点优化单机存储性能。另外OceanBase的定位是在同一套引擎同时支持OLTP业务和OLAP业务，而目前OceanBase的OLAP处理能力还鈈如Oracle后续需要加强存储模块对大查询的处理能力，支持将OLAP算子下压到存储层甚至在压缩后的数据上直接做OLAP计算

雷锋网(公众号：雷锋网)

雷锋网版权文章，未经授权禁止转载详情见。