新型企业级分布式数据库oceanbase介绍

首先，什么是OceanBase？记得一两年前，在很多技术社区，我经常遇到这样的问题。有同学问OceanBase是企业级分布式数据库还是键值数据库。甚至有同学问阿里的数据库是怎么开发的。是从开源数据库转化而来的吗？最近这种问题已经很少了，但还是想简单说一下。OceanBase是阿里巴巴和蚂蚁金服集团自研的数据库。我们拥有OceanBase所有源代码的完全知识产权。

如果我三年前说什么是海洋基地？我可能会说OceanBase是一个分布式存储系统，但是今天，让我很有信心地告诉你，OceanBase是一个通用的全功能企业级分布式数据库产品。

作为基于分布式架构的企业级分布式数据库OceanBase有很多技术优势，但我认为其中的核心是ocean base，它完全可以搭建一个基于普通PC服务器的数据库集群，可以满足财务可靠性和数据一致性的要求。

如前所述，OceanBase是自研的企业级分布式数据库。其实我们称之为类似数据库的基础软件产品，国内目前还有很多团队在开发基础软件产品。对于所有这样的团队来说，其实在他们发展的过程中，都会面临一个非常关键、生死攸关的问题，那就是你如何让你的客户相信你的产品是稳定可靠的，你的产品是可用的？要证明这一点，往往需要这个产品在典型应用中长时间稳定运行，所以很多情况下会形成死锁。

OceanBase诞生并成长于阿里巴巴、蚂蚁金服集团等快速发展的互联网公司。如此快速成长的互联网公司，本身就是一个巨大的企业级分布式数据库应用市场。所以OceanBase这几年的发展，其实就是在这个市场上不断证明自己的过程。通过在这个市场的不断应用，帮助OceanBase加速产品成熟，帮助OceanBase度过一个自研基础软件产品最难的应用壁垒。

蚂蚁金服也通过OceanBase的应用，实现了所有核心业务的100%去O化。如今，OceanBase已在数十项关键业务上投入运营，包括支付、交易、会计、网商银行等系统。其实很多核心系统已经稳定运行多年，期间也经历了双十一大会等多次实战的考验。

去年我们正式发布了OceanBase的最新产品OceanBase1.0。OceanBase1.0在整个系统架构以及产品性能和兼容性方面都有了很大的进步。最重要的是，OceanBase1.0是整个OceanBase产品发展史上第一款具备大规模应用推广能力的产品。

接下来，我们将从几个方面向您介绍OceanBase的一些重要特性:

扩展性

我们知道商用企业级分布式数据库 extension模型本质上是单机扩展，可以通过引入处理能力更强、可靠性更高的软硬件设备来解决系统的可靠性和可扩展性问题，但也更昂贵。这种延伸模式也称为垂直延伸。垂直扩张有其非常重要的优势。它的优点是整个系统的整体交付非常好，所以垂直扩展非常有利于业务。

但是纵向扩展有两个缺点:一是成本非常高，二是扩展性差。以互联网行业为代表的企业，面对自身业务的快速增长和现有IT系统的可扩展性和成本之间的矛盾，选择在企业级分布式数据库之外解决系统可靠性和可扩展性问题。简单来说，在业务层面，将业务的数据层面进行拆分，将原本由一个数据库集群完成的功能分割成几个独立的单机数据库。原来很多应该由企业级分布式数据库来完成的功能都是由一个统一的中间层来管理的，也就是我们常说的子数据库子表的模型。

这种数据库和表划分模型有其非常重要的优点，有两点:

第一点是，整个数据的划分在应用程序设计的早期就已经决定了，因此这种模型通常具有良好的可扩展性。

第二点是，这种以中间层为核心的扩展，大大降低了对硬件包括数据库本身的依赖，从而可以显著降低整个系统的成本。

但是这种中间成本模式有一个很重要的缺点，就是对业务的侵扰很重，采用这种模式通常需要对业务本身进行比较大的改造。对企业整体的IT建设能力，包括运维能力提出了很高的要求。所以目前如果想把这样的模式复制到互联网以外的其他行业，其实是有很大挑战的。

OceanBase希望在这方面做得更多，希望通过我们产品的能力，把系统的可靠性和可扩展性重新纳入数据库的范围。基于统一部署的分布式数据库集群，用户在使用OceanBase时不需要知道数据是如何分布的，负载是如何平衡的，甚至不需要知道系统是如何容灾的，这样他们就可以减少对现有服务的改造，尽可能简化业务架构的设计，同时保持低成本和线性扩展。所以这是OceanBase的一个非常重要的客户价值:对业务透明。

我前面说过OceanBase是一个分布式集群，扩展性很好，但其实了解OceanBase的同学可能知道，在早期的OceanBase场景中，系统其实是单点的。具体来说，集群中的每个节点都可以提供读服务，但是只有一个节点可以提供写服务，这有点像传统的读写分离的设计。这是一个早期的选择。这种架构的问题是系统的可靠性和可扩展性是单点的，业务写作能力的提升依赖于纵向扩展。所以在OceanBase 1.0中，我们首先解决了这个问题，真正实现了全对等集群。目前集群中的所有节点都可以提供读写服务，使得整个系统的可扩展性和可靠性有了质的飞跃。这种架构的引入也使得OceanBase整体架构稳定，这一点非常重要，这使得OceanBase为加速下一步产品和技术的开发打下了非常重要的基础。

在OceanBase1.0中，我们还正式引入了数据分区的概念。数据分区是OceanBase实现可扩展性和高可用性的基本单元。数据分区和子数据库子表中的子表在功能上非常相似，都可以支持扩展，唯一不同的是数据分区是由数据库内核自己实现的。通过用户定义数据分区，系统可以帮助业务自动完成多机扩展，系统自动容灾。整个过程对企业是透明的。我们希望在未来，更多的企业可以使用分区来代替现有的子表，并帮助他们简化中间层的设计。

海洋基地的可用性

关系数据库传统的主备架构，无论一主一备，一主多备，基于主备强同步的最大保护模式，还是基于主备弱同步的最大性能模式，当主备间任意一个节点失效时，系统要么选择停止服务，要么选择忍受主备间的数据不一致。对于关键业务，停止服务是不可接受的，这意味着在这种架构下，当我们在活动和备用之间切换时，系统通常会丢失数据。OceanBase很好的解决了这个问题。

OceanBase的核心是Paxos分布式选举协议的工业化实现。Paxos协议本身是一个多数协议。根据Paxos协议，对数据库的任何更改都需要大多数成员的同意才能进行。这句话可以反过来理解，对数据库的任何改动都要经过大多数成员的同意才能进行。因此，在Paxos协议下，任何少数成员的故障都不会影响系统的可用性和数据一致性。

下图显示了一个简单的三节点OceanBase集群，其中有一个主集群和两个备用集群。在Paxos协议下，如果三个节点中的任何一个出现故障，系统都不会停止服务或丢失数据。同时，如果主节点出现故障，其他两个备用节点可以在短时间内自动重新选择一个主节点恢复服务。目前OceanBase级别的故障恢复时间是20秒，加上服务级别是几十秒，不超过一分钟。这不是实验环境的数据，而是很多真实故障下的实际表现。海洋基地的可用性

关系数据库传统的主备架构，无论一主一备，一主多备，基于主备强同步的最大保护模式，还是基于主备弱同步的最大性能模式，当主备间任意一个节点失效时，系统要么选择停止服务，要么选择忍受主备间的数据不一致。对于关键业务，停止服务是不可接受的，这意味着在这种架构下，当我们在活动和备用之间切换时，系统通常会丢失数据。OceanBase很好的解决了这个问题。

OceanBase的核心是Paxos分布式选举协议的工业化实现。Paxos协议本身是一个多数协议。根据Paxos协议，对数据库的任何更改都需要大多数成员的同意才能进行。这句话可以反过来理解，对数据库的任何改动都要经过大多数成员的同意才能进行。因此，在Paxos协议下，任何少数成员的故障都不会影响系统的可用性和数据一致性。

下图显示了一个简单的三节点OceanBase集群，其中有一个主集群和两个备用集群。在Paxos协议下，如果三个节点中的任何一个出现故障，系统都不会停止服务或丢失数据。同时，如果主节点出现故障，其他两个备用节点可以在短时间内自动重新选择一个主节点恢复服务。目前OceanBase级别的故障恢复时间是20秒，加上服务级别是几十秒，不超过一分钟。这不是实验环境的数据，而是很多真实故障下的实际表现。

基于OceanBase的这种高可用架构，我们可以根据业务和机房条件的不同容灾需求，跨机房部署数据库集群。

简要介绍三种常见的部署模式:

第一种本地部署。

这种模式比较简单。业务流量只能在本地部署。我们知道Paxos协议要求多数，三个以上的成员才能形成多数，所以我们要求至少三个机房，三份数据。这种部署模式具有机房级容灾能力，城市级故障时系统无法服务。

第二种本地部署+异地容灾模式。

同一业务的流量只能在本地部署，三个机房两个在本地，一个在异地。这种模式还具有机房级的容灾能力，可以在发生城市故障时提供异地容灾的能力。在很多场景下，客户可能在本地找不到第三机房，采用这种模式也是不错的选择。

我们需要付出的成本是，远程容灾室不提供日常情况下的流量。这里我们使用了5份数据，而不是我们刚刚看到的3份。为什么不是3份？因为使用了三个副本，所以当本地机房的任何一个服务器出现故障时，这个服务器的数据分区就只剩下两个副本，一个在另一个本地机房，另一个在容灾机房。此时，当系统的大部分形成时，需要两个城市之间的强同步，这在性能上是不可接受的。因为用来搭建OceanBase的数据库集群都是普通的PC服务器，单机故障非常常见。这里引入了5个数据副本，并以2+2+1的方式部署。第一，确保每个机房的份数不会形成多数。第二，如果本地机房一个副本出现故障，其他三个本地副本可以形成多数，也就是说单机故障不会导致业务的RT，因为需要引入城市间的强同步而显著增加。

多站点部署的第三种模式。

这也是一种具备城市级容灾能力的部署模式，意味着数据容灾可以交给底层数据库，可以大大简化容灾架构的设计。

支持城市级容灾有两点:一是流量本身可以在很多地方部署，当一个城市级故障发生时，流量本身可以切换到其他城市。

其次，支持城市容灾意味着我们应该在城市层面形成多数，这意味着整个数据库集群需要部署在至少三个城市。同样的数据也是五份，我们也避免了单机故障导致的业务流量跨城市的切换。支持城市容灾的成本很高，因为城市容灾意味着对数据库的任何更改都需要两个城市之间的强同步，这意味着任何更新事务的提交延迟都会增加。这个延迟就是两个城市之间的网络同步延迟，根据城市之间的距离不同，通常在几毫秒到几十毫秒之间。因此，要支持多站点部署模式，首先必须对业务进行评估。这种延迟会对服务的性能和容量产生重大影响吗？如果是这样，需要对其进行优化，以减少在同步链路上提交的更新事务的数量。

这里要说明的是，无论采用哪种部署模式，所有这些跨多个机房部署的节点都是一个完整数据库集群的一部分。OceanBase可以在这个数据库集群中自动实现流量路由、故障转移和负载均衡。从业务使用或者运维的角度来说，整体交付，这是前面说的最重要的客户价值。对于业务透明，这也是OceanBase接下来最重要的工作方向，我觉得。

这里看一下我们目前的表现水平。应该说，在OceanBase架构稳定之后，OceanBase的整体性能水平在过去一年有了很大的提升。这个性能水平也是目前公布的所有三个同步性强的数据库产品的性能测试结果中最好的。

OceanBase的其他功能描述如下。

首先是Mysql完全兼容。完全兼容Mysql的工作量其实非常大。去年我们也投入了大量的人力进行相关产品的研发。到目前为止，OceanBase已经实现了从sql语法、数据类型到系统函数等对Mysql的完全兼容。作为这项工作的副产品，我们去年向Mysql开源社区提交了200多个有效的bug。Mysql完全兼容的事实，大大强化了OceanBase作为通用关系数据库的产品特性，真正帮助商家迁移到OceanBase，无需更改一行代码，降低了用户的迁移成本和学习成本。同时，OceanBase真正具备大规模应用和部署的能力。

OceanBase1.0支持的另一个重要特性是多租户。该功能的推出也正式宣布OceanBase成为云数据库产品，可以对外提供云服务，支持业务云。OceanBase对多租户的支持是系统在内核层面的原生支持。我们称之为SaaS或DBaaS架构。我们可以看到Oracle最新版本推出的多租户也是基于这种架构，而我们目前在市场上看到的云数据库产品，大部分都是基于这样一种隔离不同数据库实例的IaaS架构。相比IaaS架构，OceanBase这种原生支持的架构可以实现不同租户之间底层资源的共享，从而提高硬件的利用率和集群部署的密度。同时，多租户的资源隔离大大加强了产品在整个资源中的整合，包括系统运维的能力。

以上是OceanBase 1.0在其他方面的一些重要特性。

其中很多已经超过了Mysql现有的支持能力。在设计这方面的功能性能时，我们查阅了很多商业数据库。比如OceanBase1.0就推出了完整的诊断监控系统，很大程度上参考了Oracle，所以ORACLE中很多基础的监控设施，比如Top SQL，Top Wait等。，目前实际上已经得到了OceanBase的全力支持。其他类似的功能，包括SQL大纲、闪回、物化视图等等，都是一样的。这些特性使得基于ORACLE知识体系的客户，包括运维方面的学生，如果以后使用OceanBase，对很多方面都很熟悉。

我刚才说的是OceanBase的一些核心的特点。作为一个完整的产品形态，OceanBase还包括一个非常强大的管理和运营平台OCP。

目前无论是内部客户还是外部客户，无论是开发生还是运维生，都是基于同一个平台接入和使用OceanBase。通过OCP平台，我们可以为业务构建从业务接入、数据迁移、在线部署、日常运维的完整、封闭的功能链，从而帮助业务实现整体上云。

经过几年的发展，OceanBase在产品上积累了很多重要的技术优势。同时，随着近年来整个核心业务的稳定运行，蚂蚁金服向业界证明了OceanBase能够支撑金融核心业务。去年我们也正式启动了OceanBase通过阿里云平台对外提供服务的进程。到目前为止，我们已经与一些金融客户开展了实质性的项目合作，欢迎大家进一步了解和使用OceanBase！