揭秘 OceanBase 勇夺 TPC 榜首的王者攻略

作者 | 马超

责编 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

前一段时间阿里的OceanBase拿下TPC-C排行榜的冠军消息传来，随即就在圈内引发热议，由于位列第二名的甲骨文实际的测试时间是在2011年。

而且两者的性价比还差不多，所以不少网友认为这只国产数据库在硬件设备方面的一次胜利，而并非从核心技术方面打败了甲骨文、IBM等老牌数据库公司。

笔者本着“Talk is cheap,show me the code”的精神，在第一时间撰文从代码角度说明阿里的技术优势（详见《200行代码告诉你OceanBase的速度源头》），而近日笔者通过对于测试报告的仔细研究，发现在TPC的通关过程中绝非仅靠简单的硬件堆积就能达成，需要总结的地方很多。

爱因斯坦曾经说过“如果你不能用最简单的语言描述清楚一件事，那么你还没有真正了解他”所以接下来笔者争取继续使用最通俗的语言向大家解释一下阿里OceanBase的TPC通关之路。

速度VS整体：从基本概念说起

TPC是国际事务处理性能委员会的简称，其中TPC-C是其中一个认证标准，这个标准要求非常严格，大到性能、功能、数据一致性和容灾能力，小到测试过程中使用过的鼠标键盘价格，都需要严格披露，确保测试可复现且与真实业务场景保持一致。

其测试模拟商品交易，包含五种事务：NewOrder 创建新订单（占比 n/a）、Payment 支付订单（占比>=43%）、OrderStatus 查询最近订单（占比>=4%）、Delivery 批量配送订单（占比>=4%）和 StockLevel 库存状态分析（占比>=4%）；

并且要求最终要保证产生 10% 的“订单创建”事务和 15% 的“订单支付”事务要操作两个及以上的仓库。

如果用赛车的方式类比，那么TPC就是赛车拉力委员会，TPC-C就是一级方程式锦标赛。除了比拼速度之外，还要对赛车的转弯（整体协同能力）、换胎（故障恢复性能）、故障概率等等方面进行比拼，绝不是简单的直线竞速。

传统数据库厂商VS互联网新贵：赛车都有自己的策略

为了保证赛车的弯道性能（整体的协同能力）并尽量减少换胎次数（高可用性）传统厂商往往倾向于使用单台强劲发动机的竞争策略，不过单发赛车的劣势也非常明显他们非常容易被发动机的瓶颈所限制。

因以阿里为首的互联网选手更倾向于推销他们极致的速度体验，所以他们更倾向于使用多台发动机联动的方式，不过多发也必然会损失部分协调性，所谓韩信点兵，多多益善，能把各方捏合成整体，是兵神才能达到的境界，管理节点的增加会把复杂任务的协调难度以几何级数增长。

所以正如咱们前文所说TPC-C的这样一个复杂的赛道上，单纯进行硬件的累积，其实起不到太大作用。那么下面就我们就来详尽分析一下各方选手的情况。

Oracle VS OceanBase:软、硬件平台优势几何

一、硬件平台各有优势

之前有不少网友吐槽使用今天的硬件和11年的硬件做比拼本身就不公平。不过笔者在仔细了解了相关情况后有以下情况需要说明：

1.OceanBase的硬件投入不高：很多网友可能注意到Oracle与OceanBase的性价比其实差不太多，但是仔细分析分析报告会发现，此性价比并不是硬件性价比。TPC的测试投入会发现，它分为软件与硬件两部分。

其中硬件价格代表数据库的测试硬件成本，软件价格代表商业数据库的利润。据测试报告显示OceanBase本轮测试的硬件价格占比还不到 18%，远低于Oracle的65%。

2. Oracle使用顶配的专用设备，OceanBase则使用普通的通用平台：Oracle对于TPC的硬件平台可谓下足了功夫，共动用了108 颗 T3 SPARC 处理器，共有 1728 个物理核心和 13824 个执行线程，同时使用了97 台 COMSTAR 专用存储设备，这些存储设备都经过专门的优化，使用Intel 服务器作为存储机头，共有194 颗 Intel X5670 CPU，2328 个物理核心。而反观OceanBase则直接使用204 台 ECS i2 阿里云服务器，而并未使用专门存储。

因此我们了解到OceanBase的总体硬件成本其实不高，而且也起用专用的存储设备来满足高可用及性能需求。所以通俗来讲使用的是11年顶配的专用发动机组成的精英赛车，而OceanBase仅使用最新的通用发动机组成的普通赛车，在硬件方面可谓各有优劣。

二、软件方面OceanBase确有独到之处

由于Oracle并未开源，所以仅从结果而言OceanBase的确是做到了远超Oracle速度。我们之前《200行代码告诉你OceanBase的速度源头》也曾经解读过OceanBase的缓存机制与过滤器机制。这里我再来谈谈其它的点：

优秀的一致性协议Paxos

直白的讲，Paxo就是少数服从多数的协议，即超过半数成功即算成功的算法，这与之前传统厂商要求的所有节点强一致的算法有较大不同。

在三台节点组成集群时，当其中两台机器完成后，事务即可完成提交，剩下的一台机器通常情况下，也是立即就持久化完成了。但如果这台机器碰巧出现异常，也不会影响事务的提交，系统会在其恢复后自动补齐所缺失的 Redo Log。

如果机器永久故障，系统会将故障机器所应负责同步的数据分散给集群内的其他机器，这些机器会自动补齐所缺失内容，并跟上最新的 Redo Log 写入。

精确的时间同步服务

OceanBase使用了GTS(Globe Timestamp Service)，来对所有节点提供集中式服务，我们知道在行军打仗的过程中大家进行对表是不必可少的步骤，如果各节点之间的时间不一致，就造成命令执行的顺序出现问题，而OceanBase的GTS是使用上文提到的Paxos协议组提供服务的，这样既避免的单点风险，又提升了整体的响应速度。

后记

通过本文相信各位读者们可以看到如果把TPC-C比做一级方程式，那么OCEANBASE则相当于一台普通的多发赛车，虽然比高富帅的老爷车新一些，但也谈不上占了多大便宜，不过它的驾驶员技术非凡，在多发协同操控等方面做出了很多突破性的工作。

我们也可以看到目前除了国产的操作系统，国产的优秀数据库如TDengine和OceanBase也迎来一波热潮，其中很多技术上的创新是非常值得称赞，愿我们的国产基础平台越做越好，笔者也会继续为各位读者带来理性解读。

作者简介：本文为CSDN博主马超（ID：beyondma）的原创约稿文章。

【END】