解密：金融级海量数据库OceanBase

OceanBase是一个高性能、高可用、高可扩展并且廉价的关系数据库。

为什么要做OceanBase？

互联网金融对数据库系统提出了更高的要求。传统数据库在扩展性、事务特性以及数据强一致等方面已经做了大量的工作，但是仍不足以达到现在互联网飞速发展的要求。

以支付宝业务为例，其业务体量在平时几乎是一个固定的值，但是在淘宝、天猫以及其他一些电商业务有促销活动的时候，比如双11。如何在很短的时间之内把数据系统的能力提高一个数量级甚至更高？对于普通的基础设施系统，通过添加服务器或者存储设备等基本可以解决这个问题，但是传统数据库对于扩展能力有很大的制约。如果在数据库层面做得更好，毫无疑问，将极大地促进业务的发展，即便是高峰期时段，也能够给用户提供和平时一样的流畅体验。

比如，平时在淘宝交易的时间为2秒钟，那么，用户希望在双11这种极限情况下交易的时间依然是2秒钟。事实上，业界也有一些类似的技术，以试图解决这些问题，以获得更好的可扩展性和更高的性能，但是这些技术很难保证事务的完整性和一致性。而网络交易对数据一致性的要求极高，且服务不可中断。

OceanBase正是为了解决上述挑战而生。

为什么OceanBase是海量数据库？

OceanBase数据库是由阿里巴巴集团和蚂蚁金服集团自主研发的一款产品，其目标就是支持海量的数据的存储和计算。

和传统的数据库相比，OceanBase所具备的可靠性、稳定性和性能对硬件设备的依赖并不大。尤其是高可用性，OceanBase不依赖底层的硬件是无故障的。从设计之初，OceanBase的开发团队就假设底层的硬件是不靠谱的。OceanBase就是要用普通的硬件产品打造出更好的数据库服务。

2015年双11创造了每秒8.59万笔的交易支付，这是由OceanBase数据库支撑达成的，最关键的是，其达到数据0丢失的目标，也就是说完全保证了数据的一致性。OceanBase的完美表现也证明了，在普通的硬件平台之上，也可以打造出高可用的数据库服务。

为什么OceanBase是海量数据库？因为，目前在OceanBase的表单容量最大已经超过3000亿行，而且数据量还在不断增长。另外，OceanBase数据库还具备水平扩展能力，并且可以在线升级。迄今为止，在蚂蚁的核心业务上，OceanBase是零故障，表现比之前的系统好很多。

目前，OceanBase数据库处于不断发展的阶段，系统也在不断升级，不断演进。单个集群的规模已经超过100台服务器，就事务处理能力来看，单节点具备处理能力已经高达25万个TPS。

总结来说，OceanBase是全球第一个不依赖共享存储的金融级数据库。

OceanBase的技术原理及实现

OceanBase从开始就从设计理念上与传统数据库不同。技术团队认为，数据本身是有热度的，因此每天进行修改，但相对整体数据量来说都不多。为了设计更简单，OceanBase从架构上就做了简化。开发人员将数据分为两个部分，第一个部分是静态数据，持续化存储在SSD盘上；另外一个部分则是修改增量，比如新插入的订单数据，更新之后的账户数据等，都存放在内存里面。传统的数据库所有的修改都是发生在本地的，OceanBase把修改增量放到内存，其好处在于，使用很少的内存就可以支撑更大的业务。

世上没有完美的架构，OceanBase的这种方式会增多一些内部操作，产生一些消耗。不过，在技术团队的反复测试验证下，这一架构不仅能够保证系统的性能，而且拥有更强的扩展性。

以上就是OceanBase的整体设计思路。

现在，最新的OceanBase 1.0版实现了每一个节点都可以做查询、更新，处于一个完全对等的状态。这样的设计是为了增强系统的水平扩展能力。而在高可用方面，OceanBase的数据通常是至少拥有3个副本，并处于不同的机房。

OceanBase最大的集群规模数已经达到了上百个节点，支撑的是在线交易型的数据，一套集群可以服务很多个业务。甚至在上了公有云服务之后，可以支撑成百上千个租户。为此，开发人员将租户机制放进了数据库集群里面，这样的好处显而易见，那就是成本得到极大的降低。

在线交易中，每一笔交易都是非常少量数据的更新或者查询操作。但是要查大量数据，比如用户的详单、历史数据状态时，如果资源调度能力不强，那将是非常危险的。OceanBase可以在租户级别将资源的使用控制在安全的水位，从而避免了如双11中出现大查询而导致网络堵塞的情况。

对于OceanBase数据库来说，水平扩展其实是非常简单的。比如要增加一个节点，新购置一台服务器，剩下的数据库自己就能够解决，包括数据重新的分布等。

节点故障，硬件损坏，系统升级等，这些情况非常常见，如何做到持续可用呢？OceanBase提供了一种服务，在中间设置了一层OBProxy，主要是表分区信息、位置信息等。当要做某一个查询的时候，根据查询条件会自动化地将请求分发到OceanBase集群的特定节点上，这样就保证了路由是最短的，因此获得的性能也是最好的。

OceanBase与传统的数据库不一样，从诞生开始就没有准备采用磁盘，而是在SSD上，包括读写分离、批量回刷都基于此。另外，OceanBase还充分利用内存计算的能力来提升性能。当然，数据不可能一直放在内存，为此，技术团队设计了一些特别的机制，比如把内存里的数据回写到SSD，而且都是在系统运行低谷期进行这样的操作。

如果性能不提升，即便是扩展性非常好，也没有价值，因为那只意味成本的不断增加。为此，技术团队针对内存做了大量的性能优化工作。比如通常的应用场景有两种，一种是获取单条的记录，另一种是获取一批记录。OceanBase在内存里面维持两套索引，一个是Hash索引，一个是Btree索引，分别对应处理这两种不同的请求。同时，内存数据结构都是设计成无锁的，所以扩展性非常好。

这里对比一下MySQL。大家都认为MySQL的性能很好，路径很简单，但是测试数据显示，其单核的TPS能够达到1万，但是32核几乎难以做到10万的TPS。OceanBase的单核TPS是8000或16000，而10核的TPS则达到8万或16万，正因为如此，即便是跑在普通的服务器上，OceanBase也不会产生并发瓶颈。

OceanBase的演进

OceanBase现在支撑了支付宝的所有核心业务，如支付、交易、账务、花呗等，还有网商银行以及淘宝的很多交易业务也都基于OceanBase。

在OceanBase研发之初，技术团队在存储方面做了较多的工作，所以SQL能力不是特别强，因此也制约了一些拓展业务的能力。但近年来，技术团队投入很大的精力提升OceanBase的SQL能力，兼容并超越MySQL，甚至逐步具备Oracle的核心能力。这样，未来业务的迁移会变得平滑顺畅，且不需做改动。

OceanBase项目始于2010年。

在2011年开始做第一个业务，OceanBase还是一个KV系统。

2012年，OceanBase开始做SQL支持，也明确了其目的——为了支持更高要求的金融级的业务需求。

2014年，OceanBase发布了非常重要的0.5版本，通过架构的一些改进，已经可以做到持续可用且数据0丢失。在这一年，OceanBase也首次支撑了支付宝的核心业务，2014年双11，支付宝交易有一部分流量是跑在OceanBase上的。

2015年3月，支付宝所有的交易都切换到了OceanBase上，真正意义上彻底和Oracle说再见。

而很快，OceanBase就可以提供云数据库服务。