蚂蚁OceanBase于2020年3月在阿里云上实现商用，并在公有云上正式对外开放。网上也有相关的生态产品，包括OCP：OceanBase云平台、OTA：ocean base tuning Advisor、OMS：OceanBase迁移服务和ODC：OceanBase开发者中心。

第一，部署公有云OceanBase服务器

蚂蚁金服自研的分布式关系数据库OceanBase是纯原生的分布式关系数据库，在代码层面完全可控。蚂蚁OceanBase产品基于3AZ的三个副本部署，通过paxos协议保证多个节点间的数据一致性。即使是单点故障或单个AZ故障也能保证业务连续性，RPO=0，RTO。

在安全性和可用性方面，蚂蚁OceanBase非常适合金融业务场景。因为监管要求，金融业务场景(如银行等)无法上公有云。但这并不影响其他金融业务，如保险、基金等。

第二，蚂蚁OceanBase架构原理

与大多数分布式系统不同，OceanBase没有单独的主控服务器或主控进程。通常，分布式系统包含一个整体控制过程，用于全局管理、负载平衡等。蚂蚁OceanBase没有单独的主控流程。它的主控是一个名为RootService的服务，集成在ObServer中。OceanBase将从所有工作机器中动态选择一个观察者来执行整体控制服务。另外，当总控服务所在的观测器失效时，系统会自动选择一个新的观测器来提供总控服务。这种方式的好处是简化了部署，虽然实现复杂，但大大降低了使用成本。

OceanBase可以通过分区能力无限扩展。蚂蚁OceanBase与传统数据库分区不同的是，传统数据库的所有分区只能位于一个服务器上，而OceanBase的每个分区可以分布到不同的服务器上，每个分区有三个副本。从数据模型的角度来看，OceanBase可以看作是传统数据库分区表的多机实现。它可以将不同用户生成的所有数据整合到一个统一的表格中。无论这些分区如何分布在多台服务器上，整个系统呈现给用户的都是一张表，后台实现对用户完全透明。OceanBase在用户门户中使用OBProxy。它是一个访问代理，根据用户请求的数据将请求转发到适当的服务器。OBProxy最大的亮点在于性能出众，在一台非常普通的服务器上就可以达到每秒一百万的处理能力。

多个分区分布在多个服务器上。因为多个分区跨越了观察者，所以分布式事务是通过两阶段提交在内部实现的。当然，两阶段提交协议的性能较差，蚂蚁OceanBase做了很多内部优化。它提出了分区组的概念，将不同表的多个被频繁访问的分区放在一起，或者具有相似的访问模式，放入一个分区组。OceanBase会在后台尽可能将同一个分区组调度到一台服务器上，避免分布式事务。同时，对两阶段提交协议的内部实现进行了优化。两阶段提交协议涉及多个服务器，包括协调者和参与者。参与者维护每个服务器的本地状态，协调者维护分布式事务的全局状态。通常的做法是保留一个协调器的日志来持久化分布式事务的全局状态，而OceanBase的做法是在失败的情况下通过查询所有参与者的状态来恢复分布式事务。这样就保存了协调人的日志，只要所有参与者都预提交成功，整个交易就成功了，不需要等待协调人写日志就可以回答客户端。

第三，海底存储架构

OceanBase是一个共享的通知架构。每个观察者都有一个独立的存储引擎，将数据保存在本地，以满足灾难恢复场景下的数据连续服务。蚂蚁OceanBase采用LSM树架构设计缓存和数据存储，将数据先写入内存中的MemTable，使频率最高、最活跃的数据在内存中访问，大大提高了热数据的访问效率。当MemTable的写入达到一个阈值时，MemTable中的数据将被合并并转移到磁盘上的SSTable中。在许多基于LSM树的存储系统中，为了解决写操作的性能问题，通常将表分成多层。当一层中的表的数量或大小达到某个阈值时，它们被合并到下一层中。

在OceanBase内部，也会有很多不同类型的缓存，缓冲区类似于Oracle和MySQL。缓存用于缓存表数据的块缓存，以及行缓存、日志缓存、位置缓存等。在内存中缓存基线数据以提高查询性能。针对不同的租户，每个租户都有自己独立的缓存，可以配置对应租户内存使用的上下限，从而隔离租户或者抢占超售，适用于不同的需求场景。

在存储成本方面，蚂蚁OceanBase采用了很多数据压缩算法，比如lz4，zstd等。OceanBase会对数据集做两层瘦身。第一层是编码，它将使用字典、RLE和其他算法来精简数据。第二层是一般压缩，使用lz4等压缩算法对再次编码后的数据进行瘦身。与MySQL Innodb的传统压缩相比，zstd算法对于同样的数据集，可以节省的存储量仅为MySQL的1/3，帮助用户大大节省了存储成本。更重要的是，传统数据库中定长页的设计和压缩必然会产生存储空洞，压缩效率会受到影响。但是，在OceanBase等采用LSM树体系结构的存储系统中，压缩对数据写入性能没有任何影响。

第四，蚂蚁OceanBase SQL引擎

OceanBase租户支持Oracle和MySQL的兼容性。首先，和传统的MySQL相比，OB除了硬解析之外，还和Oracle一样支持软解析。同时，解析器还支持SQL参数化和绑定变量。解析器将解析后的SQL模板和执行计划放在计划缓存中，计划缓存中已经有的SQL可以节省每次硬解析带来的开销，从而提高SQL的运行效率。

基于LSM树的存储架构，OB设计了独特的成本模型，引入了统计信息，并拥有基于代码模型的优化器，这意味着OB可以根据统计信息计算出每条SQL的最优访问路径，并给出最优的执行计划。同时OB可以根据用户需求在线动态绑定固化执行方案，可以为应急高效的场景提供便利。在执行器端，OB不仅支持嵌套循环的连接方式，还支持哈希连接和归并连接，提高了大表连接的效率。还支持并发执行、分布式SQL等。

第五，蚂蚁OceanBase的AACID特征

OceanBase是一个分布式关系数据库，符合ACID原理。在传统ACID的基础上，OceanBase特别强调A，可用性。基于Paxos协议的多副本日志复制可以在单点故障的情况下提供无数据丢失的业务连续性。在一致性方面，OB采用了MVCC的多版本一致阅读。当数据块更新时，OB将打开一个新的数据块，并将数据版本带入事务id。只能访问事务中的SQL，未提交的数据不会被其他会话访问。隔离方面，OceanBase支持Oracle的提交读取和序列化两个事务隔离级别，与Oracle兼容良好。就持久性而言，与大多数传统数据库一样，日志排在第一位。提交事务时，重做日志在数据写入之前成功写入。当出现异常时，不会出现数据歧义。

在数据安全方面，OceanBase也采取了各种保护措施，最大程度保证数据安全。例如，回收站机制将回收站的开关设置在租户级别。当回收站打开时，在drop table或truncate的情况下，数据不会被立即删除，而是会进入回收站。在回收站停留期间，可以通过闪回的命令将表恢复到原来的状态，大大避免了误操作带来的一些风险。

对于删除、更新等数据修改操作，OB支持基于位置的闪回查询，将数据恢复到某个时间点，从而具备针对业务或运维中错误的SQL执行检索数据的能力。同时，从timestam/scn开始，Oracle tenant下也支持查询。

2019年10月，OceanBase在TPC-C性能测试中拔得头筹。创造了tpmc6088万的世界纪录，是之前顶级甲骨文的两倍。同年11月，又在支付宝双十一促销中创造了6100万笔/秒的支付峰值，再次打破世界纪录。经过多次极限业务测试，OceanBase证明分布式数据库在性能、可靠性和可用性上可以媲美集中式数据库。传统的商业数据库，如oracle、SQL server、DB2等，都依赖于高端的硬件设备(小型计算机、存储和光纤网络)，而OceanBase只需要普通的PC服务器、SSD磁盘和万兆网络。并且它还具有较高的存储压缩比。蚂蚁OceanBase上云后，目前其他管理平台(OCP、ODC、OTA)都是免费的，除了数据库本身按规范收费，迁移服务按小时收费。OCP可以方便地管理集群、租户和数据库。用户，监控租户和节点的性能。ODC可以方便地管理和维护数据库对象(表/视图/函数/存储过程等)。它的SQLConsole可以用来方便地操作数据库。通过OTA，可以及时发现当前业务基础中存在问题的SQL，提供优化建议，绑定执行计划。使用这些平台可以让运维白条，降低运维难度。