为何经过40多年的发展关系型数据库依然是主流？OceanBase 2.2免费体验(oceanbase数据库开源吗)

　　蚂蚁金服近期开展的 “共战‘疫情’，技术破局”数字课堂线上直播系列演讲我们将整理并发布在 “蚂蚁金服科技” 公众号上，欢迎关注。

　　今天将全面解读OceanBase 2.2版本的核心特性，解析在异地容灾多活、在线数据迁移等场景下OceanBase的完整解决方案，以下为OceanBase团队的庆涛老师演讲整理全文：

　　大家下午好。我是来自蚂蚁金服OceanBase团队的庆涛，很荣幸能在云栖社区直播平台为大家分享OceanBase数据库的相关知识。OceanBase官网最近发布了2.2版本的安装包，大家可以免费下载获取。安装文件里面包含了两个重要产品，一个是OCP(OceanBase Cloud Platform)和OceanBase 2.2版本，其中OCP是OceanBase的自动化运维平台，这次分享打算分两期给大家介绍OCP和OceanBase 2.2的功能，以及OceanBase 2.2的运维和开发。

　　首先跟大家分享一下OceanBase产品的定位和发展历史。

　　一个常见的问题：很多人会问OceanBase数据库到底是什么?首先OceanBase和Oracle / MySQL一样，它是一款关系型数据库，但是跟Oracle和MySQL不同的是，它是分布式架构的关系型数据库。而且它是一款原生的分布式数据库，不是分库分表中间件架构的数据库。 OceanBase数据库由阿里巴巴和蚂蚁金服完全自主研发，不依赖于任何开源项目。目前OceanBase的定位是一款商业数据库，主要用于替换Oracle和MySQL，在部分场景下可以替换DB2数据库。

　　下面为大家简单介绍一下OceanBase的发展历史。如今OceanBase已经有9年多的历史，我们的第一个业务是淘宝收藏夹，业务的特点是在上百亿的大表之间做关联查询。如今大家打开手机淘宝，这个业务其实依然是跑在OceanBase数据库之上。OceanBase的版本分为三个阶段，其中从0.4版本开始就在支付宝承担核心交易业务去O以及在网商银行承担全部的核心数据库。1.0版本后，OceanBase架构完全重构，兼容MySQL 5.6的SQL语法，从1.4版本开始逐步走向商用，第一家使用OceanBase的客户是南京银行。2018年9月，OceanBase 发布了2.0版本，OceanBase开始兼容Oracle的SQL语法，如今内部版本已经到了2.2.3。目前我们可以做到兼容70%左右的Oracle常用语法。

　　接下来为大家介绍OceanBase的几个重要的外部客户，目前网商银行全部的核心业务数据都在OceanBase上，南京银行的互联网核心业务，参照网商银行的架构搭建，也使用了OceanBase数据库。全国各地有越来越多的城商行、农商行、以及一些互联网保险、证券公司的业务，目前也开始在OceanBase上部署。

　　OceanBase能在金融行业扎根，除了有支付宝强大的业务场景背书外，还离不开OceanBase最核心的六大产品能力。

　　第一就是高可用。OceanBase的架构设计天然就是为故障容灾而设计的，它的数据至少有三副本，任何时候机器故障，只可能会出现局部的数据访问中断，并且会很快地自动恢复，恢复时还可以保证数据绝对不会丢失。这就是我们通常说的 RTO约等于30秒，然后RPO=0。这里30秒是包括故障探测时间。

　　第二个能力就是分布式架构，OceanBase数据库可以在线扩容、缩容、迁移、以及做负载均衡，并且整个集群可以异地部署，跨城市部署。 成熟的方案有两地三中心和三地五中心。

　　第三个能力就是兼容Oracle和MySQL的常用语法。我们现在重点是兼容Oracle的语法。

　　第四个能力就是高性能，2017年，OceanBase支撑了支付宝双11大促活动，交易峰值达到每秒钟25.6万笔。2019年，OceanBase得到了国外权威机构TPC-C的认证，测试结果达到6088万tpmC，荣登性能榜首，是 Oracle结果的两倍。

　　第五个能力是低成本。OceanBase基于普通的PC服务器，只需要SSD盘、万兆网络，不需要小机，存储，还有光纤网络。

　　第六个能力就是多租户的能力。OceanBase使用的时候很像云数据库，但是它跟云没有必然的关系。 在OceanBase集群里面，我们可以按需分配实例，还可以在线的资源扩容或者缩容。

　　那么接下来我来带大家详细了解一下OceanBase 2.2版本的核心功能以及背后的原理。

　　首先是集群，OceanBase集群架构至少包括三台机器，上图里实例是九台机器，机器会分为三个区域存放，每个区域我们称为一个zone，zone可以是小到一个机柜，机房，大到一个数据中心。三个数据中心的机器，整体上我们是做成一个OceanBase集群，每个机器都是普通的X86服务器，普通的SSD，万兆网卡彼此互通。

　　我们会在每个机器上面运行一个OceanBase的数据库软件，它是一个单进程程序，叫OBServer，每个机器上的OBServer进程的作用基本上是一样的，都包含两个模块，一个是SQL引擎、一个是存储引擎。整个集群里面会有一台机器比较特别，它会有一个RootService，我们称为总控服务。所以从这个架构图上来看，当9台机器全部运行了OBServer进程以后，在我们眼里它就是9个OBServer进程，它们组成了一个集群。

　　OBServer进程有一个特殊的能力，进程起来之后，它会把主机的绝大部分的CPU内存和磁盘空间资源占为己有。所以9个机器启动了OBServer进程之后，在我们的眼里的话就变成了9个资源单位，每个有30个CPU，200G内存、4T空间。它们组成集群就形成了一个超大的资源池子，270个CPU、1800G内存、36T空间。实际上这是所有的分布式数据库都要具备的基本能力，就是把各个机器的能力、资源聚合在一起。

　　那么接下来我们就看OceanBase集群的资源池，这么大一个资源池它怎么使用?这就要提到OceanBase强大的多租户能力。首先OceanBase会有一个内部租户，这个租户，也就是我们说的内部实例，主要是用于管理用的，它会占用少量的资源。15个CPU，60G内存，那么剩下的这些大部分资源就是未分配的，是留给业务用的。这时候我们来了两个业务，每个业务它会说我需要多少资源，那么在OceanBase里面就会划分出一块资源给业务使用，没有分完的，就留待给其他的业务使用。

　　从这里的设计可以看出，当我们的业务方需要一个数据库的时候，我们的运维人员在一分钟以内就可以把数据库创建好，运维的效率大大提升。

　　接下来再来看一下OceanBase里面数据分布的特点。首先OceanBase里数据的最小单位，不是表而是分区，但分区跟表是有关系的，我们说一个普通的表就是一个分区，像这里的t1表，表明它就是一个分区，我们给它编个号叫0号分区，所以这里写t1(p0)就表示 t1表的分区，但是一个分区表会有多个分区，像t3表、t4表的话，它就是分区表有0号分区、1号分区、2号分区，有三个分区。这些分区是分布在OceanBase集群任意的机器里面，没有固定的位置，这是第一个特点。

　　第二个特点是每个分区会有三个副本，副本就是指一模一样的内容，像 t1(p0)，它也会有另外两个t1(p0)，三个副本在角色上面会有所区分，我们通过颜色来区分，比如绿色的是主副本，我们也称为leader副本。黄色的是备副本又叫follower副本。默认情况下只有主副本提供读写服务，follower副本不提供读写服务，并且每个分区的三个副本一定是分布在三个zone里面的，我们横向看是三个zone。在OceanBase里有一个反向代理软件叫OBProxy，它的作用主要就是接受应用的SQL请求。 收到SQL之后会把请求转发到主副本所在的节点上面，OBProxy后面还会详细的介绍。

　　我们来看另外一个问题，三副本的内容是怎么保持同步的?比如说t1(p0)有三个副本，默认只有主副本提供读写。它们之间的同步是靠主副本上面的事务日志，也就是clog。当主副本上一个事务要提交的时候，它会把clog同时发给两个备副本。然后三个副本会把日志持久化到磁盘上，当三个成员里面，绝大多数成员把这个事务日志写成功之后，主副本上的事务就可以提交了。 这里协议使用了Paxos协议。

　　除了保持数据同步以外，当主副本出现故障时，OceanBase会自动的从两个备副本里选出一个新的主副本出来，并且会保证新选出来的主副本拥有全部的事务日志，所以数据是不会丢的。OceanBase的故障切换的力度很细，它是分区级别的，所以我们不会说某一台机器是主某一台机器是备，从这个图里面我们可以看出来有5台机器有主副本，凡是有主副本的机器都可以提供服务。 当你的业务表很多的时候，每台机器上实际上都可以有主副本，所以OceanBase的机器是没有主备概念的。

　　接下来我们详细的讲解OBProxy的功能。 OBProxy的功能其实说起来也很简单，它就是只做SQL路由，不参与运算。当收到业务的SQL请求，分析出里面要访问的表，然后找到表对应的分区的主副本在哪个机器上面，就把它转发过去，取出数据之后原路返回。对于用户来说，OBProxy就是OceanBase数据库的一个代理，所以OBProxy的可用性非常重要。通常情况下我们会部署多个OBProxy，然后把它们挂在用户已有的一个负载均衡设备上面，比如说F5上面，然后F5提供一个VIP给业务用，但F5的高可用是靠自身的备机去提供。

　　这里顺带提一下，除了OBProxy有路由功能以外，OBServer自身也是有路由功能的。接下来我们来看一下OceanBase 的SQL兼容性。

　　前面说OceanBase支持多租户，它可以兼容MySQL或者Oracle，实际上只能2选1不能同时兼容。下图左侧是MySQL常用的SQL功能，右侧是目前实现的Oracle常用的SQL功能。就Oracle功能这一块，现在是重点发展的方向。

　　数据类型的话，我们已经实现了75%的类型和86%的函数。存储过程也支持了不少功能，有些场景下业务客户的存储过程是可以平迁到OceanBase上的。在事务方面，OceanBase支持两种事务隔离级别，一个是读已提交，还有序列化隔离级别，这点是跟Oracle一致的。

　　OceanBase支持跨节点的分布式事务，内部原理是两阶段提交，强一致的，并且这个事务对业务是透明的。使用的时候，业务只要稍微注意一下额，这个事务一定要及时提交，以避免长事务在OceanBase里会超时报错。此外，OceanBase还支持自治事务。

　　下面为大家介绍OceanBase相关的解决方案。在OceanBase的周边生态产品中，除了OceanBase集群外，我们还开发了一款OceanBase运维平台——OCP(OceanBase Cloud Platform)，这款产品的目标就是让运维人员绝大部分的工作都可以通过运维平台来自动化完成。

　　第二个产品是OceanBase开发者中心——ODC(OceanBase Developer Center)，面向开发人员，目标是让开发人员能通过这个平台去连接数据库，而不用直连数据库，这样我们可以控制权限和审计功能。

　　第三个就是OceanBase的迁移服务——OMS(OceanBase Migration Service)，我们重点看一下OceanBase的迁移服务。为大家分享一个客户案例，某银行有一个Oracle业务，有一个MySQL业务，我们现在需要把它迁移到OceanBase上来。刚开始的时候客户应用是读写Oracle和MySQL，然后我们部署OMS之后，就把Oracle和MySQL的数据分别同步到OceanBase的Oracle租户和MySQL租户。这个时候业务是不停的，这个同步是实时同步，它会同步增量。 当增量追上的时候，我们再寻找一个业务低峰期的时候，让业务短暂的停写原来的数据库，这个时候OMS可以对两边的数据做一个全量的校验，确保两边数据是一致的，然后再做决定，即切换。所谓的切换就是OMS把数据同步的方向给调整一下，从OceanBase同步回原来的Oracle数据库，这时候客户的业务再把连接指向新的OceanBase数据库，那么这样的一个切换过程就完成了。这里我们会把OB的数据同步回Oracle，这个是为了方便回滚，一旦客户决定再切换回去的时候，我们只需要把这些操作反过来做一遍就可以。 同样的在回切的时候，我们依然要两边做数据校验，校验一致之后，我们再把同步方向返回来应用，把连接改回去就可以了。

　　OceanBase的容灾方案常用的就是两地三中心。两地三中心中整个集群是三副本架构，分布在三个机房，其中同城两机房，延时是2毫秒，异地机房延时是7毫秒。任何一个机器或者机房故障的话，数据库的服务都可以很快的恢复，并且保证不丢数据。当然有个缺点，故障之后写性能会下降一点点，如果应用不能承受性能下降的话，我们通常会做5副本，也就是三地五中心。

　　最后我们来总结一下OceanBase的几个核心关键字，低成本、高可用、可扩展、高性能的分布式关系型数据库，同时它又像云数据库一样，并且适合金融行业的异地容灾和多活。OceanBase目标就是做一款分布式的Oracle。