蚂蚁金服自研的分布式关系数据库OceanBase登顶TPC-C一个月后，便迎来了2019年双11大考，团队相信“TPC-C只是双11的虚拟预演，双11才是一次真实场景的TPC-C。”OceanBase在双11期间数据处理峰值达6100万次/秒，超过了TPC-C测试中的6088万次/秒的峰值，在实战中再次证明了自己。
台上十分钟，台下十年功。从2010年立项开始，OceanBase便伴随着阿里的业务以及双11的磨练成长，“数据库的数据不能出错，可是软件哪能没有BUG呢？所以一个做实时交易处理的数据库系统不只是研发出来的，更是用出来的。”OceanBase创始人阳振坤说。
“OceanBase是用出来的”
技术与商业相互成就。2009年，阿里巴巴集团首席架构师王坚提出“去IOE”，即摆脱业务系统对IBM小型机、Oracle数据库以及EMC存储的过度依赖。彼时，阿里巴巴举全公司之力投入到云计算的研发和使用中；2010年，在阳振坤带领下启动了OceanBase分布式关系数据库项目。
技术的发展要有业务的实战练兵场，不过即便是阿里巴巴有海量的业务场景，OceanBase一开始也只能在“边缘”的业务探索实践。2011年，OceanBase首次参与了双11，支持淘宝收藏夹业务。但是在随后的两年多时间一直没能走进阿里或者支付宝核心业务场景里，团队甚至随时面临解散的风险。
“我们算是天时地利人和都赶上，（做OceanBase）这件事情除非是被拍死掉，否则我们是肯定要把它做成的。”阳振坤在一篇文章中回忆当时做OceanBase的决心。
2014年，OceanBase迎来了重大转机，蚂蚁金服CTO鲁肃决定在当年的双11切10%的交易流量到OceanBase。彼时正值移动互联网爆发阶段，阿里巴巴的业务飞速发展，按照当时的业务量做全链路压测时Oracle数据库出现了抖动，“几分钟就要坏一个盘”，切到10%的流量才勉强扛住。那年双11最终把10%的交易流量切到了OceanBase，“Oracle也帮了我们（OceanBase）一把。”阳振坤感慨道。
数据库在交易业务里有了实践与验证后就有了能力的背书，之后的发展相对顺利。在2015年双11中，蚂蚁金服100%的交易流量和50%的支付流量迁移到OceanBase；2016年100%的交易流量、支付流量以及30%的花呗流量迁移到OceanBase；2017年蚂蚁金服所有的核心业务都迁移到了OceanBase，并在当年的双11创造了4200万次/秒数据处理峰值的世界纪录；在刚刚结束的2019双11中，OceanBase再次创造了6100万笔/秒数处理峰值的全新纪录。
OceanBase以低于传统数据库的成本、高性能，支持支付宝双11一次次的数据处理峰值纪录。在2016年5月，OceanBase核心团队成员获得了蚂蚁金服内部最高荣誉CEO大奖，戴上了“土豪金” 工牌带。同时，从 2016 年开始，团队着手将经过双11检验的OceanBase 对外输出，并于2017年正式对外商用。
目前，OceanBase除了支持蚂蚁金服自有业务、阿里巴巴集团双十一的流量考验以外，还支持着数十家商业银行、金融机构的业务。
从技术路线再谈OceanBase打榜TPC-C
OceanBase是分布式关系数据库，阳振坤介绍外界对OceanBase分布式系统可以满足交易处理一直存有质疑，这也是团队进行TPC-C测试的原因。
交易处理最重要的是能够满足事务的ACID特性，即原子性、一致性、隔离性、持久性，而这是集中式系统固有的优势，另一方面在线交易处理系统需要高可用性、高可靠性。而分布式系统在可靠性方面有天然缺陷，多台机器放在一起时其整体可靠性会指数级下降。这两个原因使得数据库经过半个多世纪发展，做交易处理一直都是集中式系统。
但是集中式系统也有“先天”的短板——扩展性差。蚂蚁金服研究员韩鸿源介绍，原来传统企业里不管是自己内部业务系统，还是对客前端柜台做业务系统，接入的终端数量都非常有限。基本上可以通过数据库服务器的垂直扩展满足业务需求。而随着互联网、移动互联网发展，海量的交易、数据使得传统集中式系统无法通过垂直扩展有效支撑客户访问请求。
OceanBase在一开始的时候就设定了两个重要的目标：一是系统能够水平扩展；二是即便使用普通硬件系统也必须高可用、高可靠。分布式系统具有很高的水平扩展性能，2014年到2016年间有OceanBase团队中有40多人All in OceanBase 1.0研发，主攻分布式事务难点。
后来，OceanBase在分布式数据库中实现了Paxos协议，将原来每一个物理节点换成一个Paxos组，相当于换成一个虚拟节点，这个虚拟节点背后有三/五个物理节点。根据多数派成功协议，三/五个节点里有两/三个节点写成功这个事务就被判定为成功，这样允许少数库故障而不丢失数据，解决了OceanBase分布式事务难点，实现了高可用与高可靠。
TPC-C作为一个OLTP联机交易处理系统的benchmark是世界最权威的测试基准，这些年TPC的benchmark也不断修订迭代，一方面适应业务的需求，另一方面跟上软、硬件的变化。“即使放在今天来看，不管是金融、交通、通讯等，它还是一个非常普遍适用的场景。”阳振坤强调。
打榜TPC-C证明了OceanBase分布式数据库完全具备接管核心的业务系统的能力。在双11中磨练成长，从TPC-C处证明了自己的能力，但是数据库作为最难迁移的软件技术之一，OceanBase的未来更多还是要实践中检验。
OceanBase的征程在哪里？
全球数据库市场空间巨大，根据Gartner的数据，2018年全球关系型数据库全球市场达到375亿美元，仍然以10%的速度增长，Oracle占据着较大比例。
今天，关系数据库在全球范围内的格局非常稳定，但海量数据高并发的挑战，以及云计算等新技术得发展为OceanBase等分布式数据库带来了新的机会，而且国内基础软件领域大势所趋——去“Oracle”热情高涨。
OceanBase在设计之初便不限于阿里内部而定位为一个通用数据库。蚂蚁金服最新发布得OceanBase 2.2版，内置MySQL以及Oracle两种模式，并在Oracle模式中引入了诸多功能，性能和稳定性上也相对2.0版本有大幅提升。比如，OLTP性能相比2.0版提升50%以上，部分复杂场景提升100%。
OceanBase 2.2版也被称为新一代HTAP数据库，OLTP与OLAP的融合已经成为数据库的一大发展趋势，原来OLTP由交易数据库来做，商业智能分析由数据仓库来处理。阳振坤介绍两个系统分开有较明显的缺点。
首先，数据仓库本身没有数据，需要架一个桥梁把数据从交易数据库通过ETL抽取、转换然后加载到数据仓库，并不是实时的。其次，交易数据库分库分表后也带来了很多挑战，比如订单号需要全局唯一，在业务扩容、业务缩容时需要做很多改动。第三是数据仓库本身天然面向主题，需要建多个数据仓库，尽管可以把相近的主题合并在一起，但这并不能改变数据仓库面向主题的本质，会造成大量的数据冗余。
“我们这个（TPC-C）测试更大的价值不在于OLTP，更重要的是想证明这个数据库既能够做交易，也能做智能场景分析。”阳振坤认为。OceanBase 2.2版本OLAP场景查询优化和执行能力显著提升，TPC-H全部22个查询，SF=1000(1TB)的数据量下，6台ECS(56超线程) Server总执行时间为730s。
据悉，兼容Oracle 的工作是 OceanBase 团队此前的重心。OceanBase 团队的目标是，用两年时间做到 Oracle 业务的平滑迁移，不需要修改一行代码、不需要业务做任何调整就能够将数据库迁移过来。
就如同OceanBase的名字一样，“海量”的数据库，OceanBase的征程也将是那个更广袤的关系型数据库市场。
很多人都知道蚂蚁金服有个传统项目是拜关公，“我们拜关公，不是我们迷信，更多的是表达我们对不可预知的一种敬畏。”未来的战场有很多不可预知，也有很多事等着OceanBase去探索，比如构建完善自身生态，将阿里内部的实践经验如何有效对外复用输出，如何处理企业客户原有IT资产等。
借用网友对OceanBase的评价作结：莫问前程，但行好事。孰好孰劣，市场和客户会给出答案。