OceanBase简介及其与MySQL兼容性介绍

OceanBase是阿里巴巴和蚂蚁金服合作开发的通用分布式关系兼容mysql的数据库，定位为商业企业数据库。OceanBase可以提供金融级的可靠性，目前主要应用于金融行业，也适用于非金融行业场景。它结合了传统关系数据库和分布式系统的优点，使用普通PC服务器组成数据库集群，具有优良的线性伸缩性。

 

通过在底层分布式引擎中实现Paxos多数协议和多副本特性，OceanBase具备了令人称道的高可用性和容灾能力，可以不辜负“永远在线”数据库系统的美誉，完美支持多站点、多站点容灾等高可用性部署。

 

OceanBase是一个准内存数据库系统，其独特的读写分离架构和SSD固态盘高效存储引擎，为用户带来超高性能体验。

 

OceanBase定位为云数据库。通过在兼容mysql的数据库中实现多租户隔离，一个集群可以服务多个租户，租户之间完全隔离，互不影响。

 

OceanBase目前完全兼容MySQL，用户可以免费从MySQL迁移到OceanBase。同时，OceanBase在兼容mysql的数据库中实现了分区表和二级分区功能，可以完全替代MySQL常用的数据库划分和表划分的方案。

 

OceanBase的存储引擎

OceanBase本质上是一个基线加增量的存储引擎，与关系数据库有很大的不同。存储机制是LSM(日志结构合并树)，这也是大多数NoSQL使用的存储机制。OceanBase采用读写分离架构，将数据分为基线数据和增量数据，其中增量数据存储在内存(MemTable)，基线数据存储在SSD磁盘(SSTable)。虽然不是刻意设计，但OceanBase确实比传统数据库更适合双十一、秒杀、优惠券销售等短期突发性大流量场景:

 

短时间内大量用户涌入，短时间内流量非常大。兼容mysql的数据库系统压力很大。

一段时间后(几秒、几分钟或半小时等)。)，业务流量快速或明显下降。

OceanBase是“基线数据(硬盘)”+“修改增量(内存)”架构，如下图所示。

 

 

 

整个兼容mysql的数据库以硬盘(一般是SSD)为载体，所有的数据修改都是增量数据，只写在内存中。新增、删除、更改的数据(修改增量)都在内存中，所以DML是一个完整的内存操作，性能非常高。基线数据存储在硬盘上，所以OceanBase可以看作是一个准内存数据库。这样做的好处是:

 

事务写在内存中(除了事务日志必须下载)，所以性能大大提高。

没有硬盘随机写入，硬盘随机读取不受干扰，高峰期系统性能明显提升；对于传统数据库来说，业务高峰期通常是大量随机写盘(脏页被刷)的高峰期，大量随机写盘会消耗大量IO，尤其是考虑到SSD的写放大，对读写性能影响很大。

基线数据只读，缓存简单，效果提升。

读取数据时，数据可能在内存中有更新版本，在永久存储中有基线版本。有必要合并两个版本以获得最新版本。同时在内存中实现块缓存和行缓存，避免随机读取基线数据。当内存中的增量数据达到一定规模时，会触发增量数据和基线数据的合并，将增量数据转储(称为dump，也称为minor freeze)。同时，系统会在每晚空闲时间自动合并(简称大冻结)。

 

简而言之，OB为什么采用这种特殊的架构，是基于这样一个理论基础——虽然兼容mysql的数据库本身的数据量越来越大，记录也越来越多，但是每天增加、删除、修改的数据量并不大，只占数据库总量的很小一部分。这种情况不仅适用于支付宝的支付数据，也适用于其他大多数兼容mysql的数据库实际应用。建立上述存储引擎是OB的重要理论基础。

 

 

 

日志结构的合并树(LSM树)，日志结构，日志结构，只需要不断追加。“merge-tree”，即“Merge-tree”，将多个文件合并为一个。LSM树最大的特点就是写入速度快，主要是利用磁盘的顺序写入。LSM树存储引擎和B树存储引擎一样，也支持添加、删除、读取、更改和顺序扫描等操作，并通过批量存储技术避免了随机写盘的问题。当然，凡事有利有弊。与B+树相比，LSM树牺牲一部分阅读性能来大幅提升写作性能。

 

 

 

LSM树的设计思想很简单:将修改后的数据增量保留在内存中，等到累积到指定的大小，再通过合并排序的方式将内存中的数据合并追加到磁盘队列的末尾(因为所有要排序的树都是有序的，所以通过合并排序可以快速合并在一起)。但是，看书的时候，有点麻烦。需要将磁盘中的历史数据和内存中最近的修改操作进行合并，因此写入性能大大提高。读取时，可能需要查看内存是否被命中，否则需要访问更多的磁盘文件。

 

基于日志的存储引擎是一个比较新的方案，其核心思想是系统化地将磁盘上的随机写入变为顺序写入。因为硬盘的性能特点，写性能比B树存储引擎高几倍，读性能则相反。b树把所有的压力都放在了写操作上。从根节点索引到数据存储位置，可能需要多次读取文件；真正插入的时候，可能会导致页面多次拆分写文件。LSM树插入时是直接写入内存的，所以只要使用红黑树或跳转表等有序数据结构使内存中的数据保持有序，就可以提供更高的写吞吐量。LSM树的基本思想简单而有效，足以有效地支持区间查询和非常高的写吞吐量。然而，当LSM树寻找数据库中不存在的关键字时，它需要检查索引和所有段文件。为了优化这种情况，存储引擎通常使用Bloom filter。

 

OceanBase如何保证书写的原子性？

分布式数据库技术的难点在哪里？简单来说，第一个便士是好的，数据库要支持事务，事务有酸原则。这四个字母代表:A原子性，C一致性，I孤立性，D持久性。

 

原子性:是指一个事务中的多个操作要么全部完成，要么全部失败，不会有中间状态。比如A转账100元，A账户扣100元，B账户必须增加100元。这两样东西必须像原子一样紧紧结合在一起。绝不允许“甲扣了钱，乙没加”的情况发生。

一致性:A转账100元。转账一完成，A会即时查看其最新余额，必须显示扣除100元后的金额，B会即时查看增加100元后的余额。任何时候所有账户都必须完全匹配。

隔离:这意味着多个并发事务不会相互影响。a转账给B100元，不可能对c有什么影响。

持续性:是指一旦交易成功，就不会丢失。甲转B100美元。此转移一旦完成，将永久生效。

一致性是目标，原子隔离和坚持是手段。只要酸中AID做得好，C自然会满意。

 

因为数据分散在几个数据库服务器上，所以数据库被分割了。分布式编写最大的难点其实是保证ACID中的A原子性。

 

例如，假设A向B转账100元，由于是“分布式数据库”，A用户的账户数据存储在A机器上，B用户的账户数据存储在B机器上。

 

如果负责从A账户扣款100元的A机在交易发生时崩溃，扣款失败，但负责给B账户加100元的B机正常工作，加了100元——这将导致支付宝损失100元。

 

另一方面，如果负责从A账户扣100元的A机正常，已经扣了100元，而负责给B账户加100元的B机崩溃，100元没有加，那么用户就损失了100元——最后，支付宝要赔偿用户100元。

 

 

 

为了保证以上两种尴尬情况不发生，OceanBase 1.0采用了一整套技术，但最重要的有两项。

 

投票机制

数据库采用“三份”，即任何一个账户都有三份相同的数据，即一个主咖和两个备胎。

 

例如，帐户A的数据必须同时存在于三台机器上。转账的时候，至少执行两台机器才完成转账，也就是说三台机器中有一台坏了，不影响转账的执行。同时，三台机器实时互相发送“心跳信号”。如果一台机器挂了，另外两台会立刻感觉到。处理完手头的交易后，会立即向系统发出警报，系统会自动为他们匹配一个新的合作伙伴，三台机器继续工作。而是把坏掉的机器交给技术人员修理，修好后重新上架成为备用机，等待进入战斗序列。

 

也就是说，除非两台机器在同一年的同一天同时坏了分、秒、毫秒，否则数据库的工作不会受到影响。

 

 

 

就算这样还不够，在关键节点上，OceanBase会采用五个节点投票。也就是说，除非三台机器在同一年的同一天、同一个月、同一分钟、同一秒、同一个毫秒内坏了，否则数据库的工作不会受到影响。这个概率已经低到尘埃里了。

 

 

 

OceanBase，在存储层，通过分区级Paxos日志同步实现高可用和自动扩展，支持灵活的存储架构，包括本地存储和存储与计算分离。经典的集中式数据库往往采用主备同步方案，有两种同步方式:第一种是强同步，每一个事务操作都需要强同步到备机，才能回答用户。这种模式可以保证服务器故障不丢失数据，但必须停止服务，无法保证可用性；另一种是异步的，每个事务只有在主机成功时才能回答用户。这种方式可以实现高可用性，但是主数据库和备用数据库之间的数据不一致，备用数据库切换到主数据库后会丢失数据。

 

 

 

强一致性和高可用性是数据库的两个最重要的特征。在主备份同步模式下，您不能两者兼得。Paxos是基于多数的分布式投票协议。每笔交易都需要成功写到一半以上的服务器上，才能回答用户。俗话说，“三个臭皮匠，顶个诸葛亮。”假设总共有三个服务器，每个事务操作都需要在至少两个服务器上成功。无论任何一台服务器出现故障，系统中仍然有一台服务器包含所有可以正常工作的数据，这样就不会有任何数据丢失，并且在30秒内选择新的主库恢复服务，RPO等于0，RTO小于30秒。所有保证RPO=0的协议都是Paxos或者Paxos的变种，Raft就是其中之一。

 

监督机制

监督机制实际上是两阶段提交协议(2PC)的实践。仔细想想，除了坏机，还有一些情况会破坏事务的原子性。

 

比如账户A需要扣款100元，但是余额只有90元，或者已经到了今天的转账限额。这种情况下，如果贸然给B账户加100元，而A账户没有扣够，那就麻烦了。

 

另一方面，如果账户B的状态异常，你不能添加100元，也会有麻烦。解决这个问题的办法就是引入一个裁判。裁判站在账户A和账户B旁边，其工作流程如下:

 

裁判问账号A:你的三台机器都没问题吧？账号A说:没问题。

裁判问账户A:你的账户允许扣100吗？账号a说:允许。

裁判问账号B:你的三台机器都没问题吧？账户B说:没问题。

裁判问账号B:你的账号状态能接受100吗？乙:是的。

这时裁判吹响了哨子，A、B账户同时被冻结。

A扣100，B扣100，双方向裁判报告“成功”。

裁判再次吹哨，账号A和B同时解冻。

以上七个步骤都是按时间顺序完成的。任何一步卡住了，账都不会乱，一分钱也不会亏。完全符合“原子化”的要求。

 

 

 

在2PC中担任协调人。

 

OceanBase如何保证事务的隔离？

数据库不能只服务一个用户，需要允许多个用户同时操作数据，也就是并发。因此，需要保证多个并发事务的隔离，这就涉及到并发控制技术。常见的并发控制方法包括基于锁的并发控制和多版本并发控制。

 

基于锁的并发控制

数据库锁定用户在事务处理过程中操作的每一行数据，包括读操作加读锁和写操作加写锁。读写块，读写块。如果两个不同的事务试图修改同一行数据，事务1添加一个写锁正常执行，事务2只能阻塞等待。当事务1完成执行并释放写锁时，事务2继续执行。

 

以转账操作为例，账户A有100元，账户B有200元。如果交易1以10元从账户A转账到账户B，在交易1执行过程中，账户A和账户B的数据会被锁定。如果交易2再进行一次转账操作，用50元从账户A转账到账户B，将无法向A添加写锁，交易2将等待，直到成功添加写锁。

 

如果在事务1和事务2的执行过程中，另一个事务3要查询两个账户A和B的余额总和，那么需要读取A和B两行，读取前要加一个读锁。但是，当事务1和事务2被操作时，读锁没有被成功添加，所以事务3需要等到事务1和事务2都完成后才能被执行。

 

多版本并发控制

在上面的例子中，不管交易1和交易2是否完成，读取账户A和B的总余额的操作的结果是确定的(300元)。但是基于锁的并发控制，读写都是阻塞的，这就大大降低了数据库的并发性能，于是出现了MVCC方法来控制并发。对于数据库的数据，每次修改都会保留版本历史，这样读操作就可以直接在版本历史上执行，而不会被写操作阻塞。

 

在MVCC方法下，每个事务都有一个提交版本，继续上面事务3的例子。假设数据的初始版本是98，事务1的版本号是100，事务2的版本号是101。然后，在完成所有修改后，数据库中的数据状态如下:

 

 

 

每次数据修改的记录将被连接起来。另一个全局变量，全局提交版本(GCV)，指示最后一次全局提交的版本号。事务1执行前的GCV是98，事务1提交后是100，事务2提交后是101。因此，当事务3开始执行时，首先获取GCV，然后根据这个版本号读取相应的数据。

 

MVCC的修改操作仍然依赖于上面提到的锁定机制，所以写操作之间的冲突仍然需要等待。但MVCC最大的优点是读操作和写操作完全隔离，互不影响，对数据库性能和并发的提升非常有利。

 

OceanBase使用的方案

当采用MVCC方案时，GCV的修正需要依次增加。如果GCV修改为101，则意味着101之前的所有事务都已提交。在OceanBase使用分布式交易后，这种保障就变得困难了。例如，版本号为100的事务可以是分布式事务，版本号为101的事务可以是独立事务。分布式事务的提交过程明显比独立事务长。结果，版本号为101的事务首先完成，GCV更改为101。但此时，版本号为100的事务仍在提交，无法读取。

 

因此，OceanBase采用了MVCC和锁基相结合的方式。读取操作首先获取GCV，然后根据这个版本号读取每一行数据。如果这一行数据没有修改，或者有修改但是修改后的版本号会大于GCV，那么这一行数据可以根据版本号直接读取。如果这一行数据中有正在提交的事务，并且版本号可能小于用于读取的版本号，那么读取操作需要等待事务结束，就像基于锁的方案中读取锁等待写入锁一样。但是，这种情况发生的概率极低，所以总体表现不比MVCC差。

 

海洋基地的高可用性

高可用性是数据库的基本要求之一，传统数据库允许通过日志同步来实现主备镜像。然而，传统数据库的高可用性实际上是建立在传统高可靠服务器和高可靠共享存储的基础上的，因为主数据库和备用数据库在主备镜像中不能完全同步。

 

OceanBase也使用性价比更高、可靠性略低的服务器，但同样的数据存储在超过一半的多个(> =3)服务器上(例如3个服务器中的2个，5个服务器中的3个等。)，而且每一个写事务都要到达一半以上的服务器才能生效，所以在少数服务器出现故障的情况下不会有数据丢失。不仅如此，当主数据库出现故障时，传统的数据库主备份镜像通常需要外部工具或人力将备份数据库升级到主数据库，而OceanBase底层实现的是Paxos高可用性协议。主数据库失效后，剩下的服务器会自动选举新的主数据库，继续提供服务。OceanBase数据库可以自动切换，完全不会丢失数据。

 

OceanBase和MySQL的比较

1.OB的重做日志由paxos实现，这是一种分布式一致性算法。所以在CAP理论中，虽然OB采用了强一致的模型，但是OB可以在某些网络分区上实现高可用性(通俗点说就是一半以上的机器还活着的时候就可以工作)，官方的MySQL目前还做不到这一点。

 

2.OB的存储结构使用两级LSM树。内存中的C0 Btree叶节点不需要和磁盘上的Btree一样大，可以做得更小，对CPU缓存友好，不会有写放大的问题。OB的写性能大大提高。同时，磁盘上的C1树不是传统的Btree(Btree如果不压缩可能会浪费一半的空间)。大大提高了空间利用率。简单来说就是速度快，性价比高。

 

3.数据库自动分片功能(hash/range，支持一级和二级分片)，提供独立的代理路由将查询等操作写到对应的分片上。这意味着无论数据量有多大，都不需要手动划分数据库和表。而且可以在线在服务器之间迁移碎片，解决热点问题(资源分配不均的问题，以便灵活加机减机)。每个切片(确切的说是选为主片的切片)都支持读写，从而实现多点写入(高吞吐量和线性可扩展的性能)。

 

4.在数据库内部实现的非阻塞两阶段提交(跨计算机事务)。

 

5.数据库原生多租户支持可以直接隔离租户之间的cpu、mem、io等资源。

 

6.高可用性。对于OceanBase来说，相同的数据存储在一半以上的服务器上(> =3)(例如3个服务器中的2个)，每一个写事务必须到达一半以上的服务器才能生效。因此，当少数服务器出现故障时，不会有数据丢失，RPO可以等于零。不仅如此，在OceanBase底层实现的Paxos高可用性协议，在主库出现故障后，剩下的服务器会很快自动选举出新的主库，实现自动切换，继续提供服务，使得RTO在实际生产系统中可以达到20秒以内。

 

 

 

7.扩展你的能力。借助MySQL数据库中间件，通过划分数据库和表来实现横向扩展。这种解决方案解决了传统数据库垂直扩展的共性问题，但仍有一定的局限性，如容量难以扩展和收缩、无法支持全局索引、数据一致性难以保证等。OceanBase从数据库级别提供了真正的水平可伸缩性。OceanBase是基于分布式系统实现的，可以方便地扩展和收缩，并且用户不会察觉。同时，OceanBase在集群中的动态负载平衡、分布式查询和全局索引能力进一步增强了其可扩展性。对于用户数据库和表划分的方案，OceanBase提供了分区表和二级分区的功能，完全可以替代。