超越Google Spanner，阿里巴巴/蚂蚁金服OceanBase关系数据库正式商用

金融行业对IT系统的要求非常严苛，依赖性也更强。由于业务量大，实时处理要求高，金融系统对IT系统的可用性、稳定性和安全性等的要求都是其它行业无法比拟的。

金融行业的IT系统一般都采用IBM的高性能服务器甚至是大型机，运行传统的DB2/Oracle关系型数据库，并使用高可靠的共享存储保障数据的可靠性。几十年来，IBM主机+DB2/Oracle数据库+共享存储成为全球几乎所有银行的核心业务系统标准配置。金融用户付出的代价也是高昂的，数千万甚至数亿的硬件购置费用，惊人的数据库软件许可费用以及每年总体费用20%左右的硬件及软件服务支持费用。四~五年后，整套硬件得全部更换，否则无法保证系统的正常运行，更不谈高可用。面对业务的快速扩展，这种传统单机应用方式的扩展性极其有限，无法满足金融行业的需求。

能不能采取分布式技术，将数据库系统运行到价格更便宜的普通x86服务器上?Google最早开始改变这一现状，推出分布式数据库Google Spanner，并在2011年应用于其广告计费系统AdWords。2010年，OceanBase分布式关系数据库在淘宝开始研制并在2011年初应用于淘宝收藏夹;2016年，蚂蚁金服的核心系统全部迁移到OceanBase，成为全球第一个将核心业务上全部运行在普通x86服务器上的金融级服务平台，不但保证100%可用性，而且成本大幅降低。

蚂蚁金服高级研究员阳振坤

接受记者采访的蚂蚁金服高级研究员阳振坤表示，拥有天时、地利、人和的阿里巴巴/蚂蚁金服成功地推出了运行于普通服务器上的分布式数据库OceanBase，用不到以前十分之一甚至更低的硬件成本，做到了传统关系型数据库所有能做到的事，这不能不说是一个巨大的突破。

阿里巴巴/蚂蚁金服为什么要做自己的分布式数据库?

百度一下，你会发现，阳振坤是著名的计算机专家。早年，他在王选院士的麾下，是北京大学计算机研究所的教授和北大方正研究院的副院长。离开方正后，曾在微软和百度从事分布式系统的研究。2010年，阳振坤到了阿里巴巴，却一头扎进了数据库领域，历时近七年，从零开始，带领团队研发了这款中国唯一的应用于金融核心系统的分布式关系数据库OceanBase。

谈起阿里为什么做数据库，还有一个小故事。马云曾经说过：“我喜欢听别人抱怨。当四周全是抱怨、愤怒、不满时，只要能提出解决之道，机会就会出现。我们老在抱怨别人，若能解决这些抱怨中的任何一个，10年后你会成功。”

对于运行于高端服务器/大型机以及高端存储的关系数据库的抱怨由来已久：高昂的软件硬件成本，扩容之后无法缩容导致资源闲置浪费，数据库主库计划外停机导致数据丢失，须人工对账·····

2008年，除了高昂的软硬件成本外，淘宝还遭遇了数据库系统的扩展难题：传统的商业银行和商业门店开业后，连接数据库的终端数量是相对固定的，店面扩展、新开分店可能要半年甚至更长时间，对应的数据库系统的扩容有足够的时间窗口;而互联网企业则完全不同，访问的用户数量无法确定，并且可能在几天甚至几小时内增长数倍，小型机和共享存储的季度乃至半年的采购周期无法适应业务的需求，这其实是以互联网为代表的新兴社会生产力对数据库的新的需求。

然而，模仿却不能改变产业格局。后起的IBM和微软的关系数据库系统都没有撼动Oracle的王者地位，是因为他们的技术方案与Oracle相似，架构相似，成本相似，作为最关键的基础设施的关系数据库，其迁移成本和风险都比较高，这种情况下后来者劣势十分明显。

而这正是OceanBase选择从零开始做关系数据库数据库的原因：x86服务器和分布式技术天然的水平扩展能力，可以按需求随时增加/减少服务器，并且大幅度降低数据库硬件成本，不仅满足互联网等新兴企业对数据库的快速扩展的需求，也形成了巨大的成本优势;数据三副本和Paxos协议在单机/单机房故障的情况下避免了数据丢失，并且保证了服务持续可用;服务器内存的增加和固态盘(SSD)的普及也为OceanBase提供更好的硬件基础。此外，淘宝/支付宝的数以千计的数据库生产系统，完全能够把一个有价值的自研数据库打磨得非常稳定可靠。

对标Google Spanner，OceanBase做得更好

F1本来是Google的AdWords重构项目，Spanner则是其中的分布式数据库，2008年底开始研发，但直到2012年其论文发表后才为外界所知。2017年2月，Google发布了基于Spanner的数据库服务Cloud Spanner：Google基于Spanner提供的、可用于关键业务的云数据库服务。

与Spanner相比，后起之秀OceanBase更具有前瞻性的思维和大胆的技术路线选择。

从时间上看，Spanner在世界上首次在跨地域尺度上实现了ACID，并且很好地实现了水平扩展，解决了基于普通廉价x86服务器的数据库高可用，这是一个了不起的创新。而OceanBase在2010年立项，独立发展了自己的ACID、水平扩展以及基于普通x86服务器的数据库高可用技术等，并在2011年2月开始在淘宝收藏夹使用。

在对SQL的支持和对关系模型的支持上看，Spanner没有支持国际标准SQL及其接口(ODBC/JDBC等)，也没有采用真正的关系模型(尽管支持join等)，主要原因也许是Spanner最早定位于Google内部应用。这些缺失使得Spanner能够以较小的成本和在较短的时间内投入生产运行，并且更好地契合内部应用，但这也使得迁移已有的基于传统关系数据库的业务到Spanner的工作量和难度很大，这对Spanner的外部应用和推广的负面影响无法忽视。OceanBase从第一天就强调采用标准的关系模型和支持国际标准SQL，与传统关系数据库更相似，后续推广应用的代价更小，比如目前MySQL应用可以不做任何修改地无缝迁移到OceanBase。

分布式系统都需要一定程度的服务器时钟同步，Spanner通过TrueTime实现了大规模、跨地域分布式数据库系统的快照读隔离级别，这非常了不起，但这个技术方案导致单次访问延迟在5ms甚至更长，许多业务无法忍受如此之大的延时。OceanBase采用跟TrueTime迥异的机制，但也实现了跨地域的数据库高可用。

在应用上，Spanner通过F1用于Google生产系统，之前主要用于内部项目，Spanner缺乏像传统商业数据库的各种内部状态和事务执行过程跟踪和分析手段，这对于Spanner的外部应用推广也会有较大的影响。OceanBase从一开始的目标就是像传统关系数据库一样直接用于生产系统，有比较完善的内部监控和事务执行跟踪机制。

OceanBase拥有更好的架构

让阳振坤自豪的是OceanBase相比Spanner拥有更好的架构。

一方面，针对x86服务器SSD闪存盘容易读出、不耐擦写的弱点，OceanBase分布式数据库设计扬长避短，采用的方法是将基线数据存放在SSD，将变动频繁的增删改数据放在内存，从而避免更多SSD写操作。OceanBase采用“基线数据(硬盘)”+“修改增量(内存)”的架构，如下图所示：

即整个数据库以硬盘(通常是SSD)为载体，新近的增、删、改数据(“修改增量”)在内存，而基线数据在保存在硬盘上，因此OceanBase可以看成一个准内存数据库，。

另一方面，出于高可用的考虑，在典型场景下，OceanBase是三机群(zone)部署：根据配置和部署的不同，业务高峰时可以一个机群(zone)、两个机群(zone)或者三个机群(zone)同时提供读写服务。

OceanBase是一个多机(分布式)系统，并且必须保证任何时刻出现的少量硬件(服务器、存储、网络等)异常不影响业务。为此，OceanBase引入了Paxos协议，每一笔事务，主库执行完成后，要同步到半数以上库(包括主库自身)，例如3个库中的2个库，或者5个库中的3个库，事务才成功。这样，少数库(例如3个库中的1个库，或者5个库中的2个库)异常后业务并不受影响。

OceanBase的目标不仅是超越是Google Spanner，而且要超越传统关系数据库

截止到2016年年底，蚂蚁金服包括交易库、支付库、会员库、账务库等所有的核心数据库都采用了OceanBase，都运行在普通的x86服务器上，成为国内乃至全球第一个在金融核心业务上采用分布式数据库的成功案例。

2016年，OceanBase渡过了一个成功的双十一：支持了支付宝核心的交易、支付、会员和账务等，并且创造了新的纪录：交易创建17.5万笔/秒、交易支付12万笔/秒、全天累计支付10.5亿笔!同时，OceanBase创造的成本节约更是惊人的!

阳振坤表示，虽然不是刻意设计的，但OceanBase的准内存模式确实比传统数据库更适合像双十一、聚划算、秒杀以及银行国库券销售等短时间突发大流量的场景：短时间内大量用户涌入;短时间内业务流量非常大，数据库系统压力非常大;一段时间(几秒钟、几分钟、或半个小时等)后业务流量迅速或明显回落等。虽然2010年设计OceanBase架构时，其实并没有特别考虑到这个突发大流量的因素。

OceanBase的应用扩展并没有停步。蚂蚁金服投资的印度最大移动支付公司Paytm采用了OceanBase数据库，OceanBase还在国内数家银行进行验证性测试(Proof of Concept，即POC)。

对于未来的发展，阳振坤表示，OceanBase分布式数据库的目标不仅是对标或者超越Google Spanner，而且还要进入传统的关系数据库市场，通过金融领域，经过这一要求最严苛的行业的考验后，OceanBase分布式数据库会在其它行业推广，把低成本、高可用性的数据库产品的价值带给广大的用户。