OceanBase是蚂蚁集团推出的关系型分布式数据库，是一款完全自研、全球唯一在TPC-C 和 TPC-H 测试上都刷新了世界纪录的国产原生分布式数据库。
宏观上的三次架构演进
2010年左右，OceanBase发布的 0.1 版本到 0.5 版本，虽然是一个分布式的架构，实现了SQL 层和存储引擎的分离，上面是一组SQL 无状态服务，下面是由ChunkServer 和UpdateServer 组成的存储集群，但其实是一个单写多读的架构，实际上并不支持分布式事务。
2016年之后发布了1.0版本，开始支持分布式事务。和大多数存储和计算分离的分布式数据库一样，松耦合的方式导致网络上的开销很大，延时不可控。所以OceanBase
1.0在设计上把存储事务SQL做成紧耦合的架构，将原来的三个Server合成一个OBServer节点，处理存储事务SQL；而且将高可用的粒度，由原来机器级别切分成若干个Zone。并且引入了多租户概念，实现较好的资源隔离。
2022 年OceanBase发布了4.x 版本，在这个版本中OceanBase正式提出了全新的分布式一体化概念，其核心理念在于把单机高性能、低成本的优势与分布式可扩展能力、高可用能力的优势完全融入到一套系统里。在OceanBase
4.0之前，事务扩展和存储扩展是放到同一个维度来看的，但这样会带来一个问题，如果存储分成了若干分片，事务处理和高可用能力也需要同等的粒度来分片。OceanBase
4.0中对这两个概念进行了解耦，若干个存储的分片会共享一个事务日志流以及这个日志流所对应后面的高可用服务。这种架构减少了日志流的开销，减少了分布式数据库建设的资源投入，对于中小型企业特别友好。
分布式一体化架构解读
灵活的部署形态
从部署形态上看，OceanBase支持单机部署，如果业务系统对读写分离有需求，可以使用 OceanBase 主备库的能力，就像传统的 MySQL 的主备库一样；如果觉得 MySQL 的主备库在切换的时候会产生丢数据的问题，可以从主备库动态的升级到OceanBase 三副本模式；如果觉得高可用、三副本的模式对你来说不是很关键，那么OceanBase 也具有非常强的单机模式下scale-up 垂直扩展的能力。
灵活的部署形态，使得用户可以根据系统的规模和需求选择不同的架构，也可以在上线后根据系统的需求变化来调整架构。
简化的分层设计
和集中式数据库相比，分布式最大的性能损耗来自于网络之间的IPC通讯。存储和计算分离，每个模块都可以独立扩展，架构设计上也显得清晰简洁，但却是性能的致命杀手。
为了兼顾各种部署形态下的性能，OceanBase简化了整体架构上的分层设计，主要分为代理层和服务层。
代理层的OB Proxy主要用于对SQL做基本解析，确定对应Leader所在服务器，并将请求路由至对应Leader。每个OB Proxy都是一个“无状态”的服务进程，不做数据持久化，也不参与数据库引擎的计算任务，不涉及事务处理，对部署位置没有要求。
服务层的OB Server包含单机数据库的所有功能，具体包括总控服务(RootService)、SQL引擎和存储引擎等组件。RootService是OceanBase的核心模块，属于集群的内置服务，不需要单独部署。其核心功能包括负责元数据管理、资源分配及调度：分区及副本管理、动态负载均衡、扩容/缩容等，以及全局DDL、集群数据合并等；SQL引擎提供SQL解析、执行等功能，支持MySQL和Oracle两种模式，在创建租户的时候可以通过指定SQL模式使得OceanBase能够根据需要兼容不同的SQL语法；存储引擎基于开源的LSM-Tree改造，其典型的特点是通过内存增量数据的批量合并写磁盘，将传统数据库中的数据文件随机写转换成了顺序写，大大提升了数据写的性能。关于LSM-Tree存储的详细介绍可以参见笔者前面的文章LSM-tree 为什么会成为众多开源数据库的青睐。
两层架构意味着如果一个事务不需要跨库执行，在OceanBase中相当于是单节点执行，而业务查询中真正需要跨库的操作通常不会超过10%，因此在同等硬件配置的前提下，单机部署形态的OceanBase能够取得比MySQL等单机数据库相当甚至更好的性能。
分布式事务的优化
分布式事务优化的最好方式是减少分布式。这句话咋看起来有些矛盾，但其实也有它的道理。除了前面说的90%的事务具备本地化执行的条件外，剩下的10%仍然可以通过更加精细的设计来尽量减少分布式执行，OceanBase里就有很多这样的设计。
比如在PolarDB-X解析的文章中我们提到了全局索引，OceanBase的Proxy也会根据SQL特征将其路由到存储所在的节点上，从而将原本是分布式执行的事务变成了本地执行。
再比如OceanBase专门优化了分布式处理协议，
在事务开启阶段，其他分布式数据库的两阶段提交过程中，为了实现多版本的事务隔离，需要获得一个全局的快照，这个快照的操作是非常大的开销，而OceanBase优化后的很多场景都不需要访问时间戳服务。
在事务提交阶段，传统的两阶段提交需要写四个阶段的日志，来保证数据的绝对安全。OceanBase事务提交协议提出了一个新思路，叫做参与者既协调者的两阶段提交协议。首先，OceanBase的参与者是三副本、高可用的，并不担心协调者的节点数据丢失，所以在参与者上不记日志，这样就节省了两条日志。第二，OceanBase会在第一个阶段就给应用返回成功，使得整体的 roundtrip 少了一次。所以整体来说，即使在分布式事务场景下面，OceanBase 的分布事务比其他的分布式数据库有很大的优势。
总结
总体来说，OceanBase单机分布式一体化能力，有两个维度的价值和意义：
第一，既可以单机方式部署，也可以分布式部署。而且可以在任何时刻，由单机形态变成分布式形态，从分布式形态变回单机形态，都支持动态变换。提供给用户更多更灵活的选项，满足不同场景下的应用需求。
第二，即使是在分布式部署场景下，相较于其他分层的分布式数据库，OceanBase的性能有很大的优势，如果用户做精细控制的话，单机事务比例增加以后，能够实现和单机数据库相当的效率。
写在最后
曾几何时，分布式数据库动辄10+甚至100+的节点数量，高昂的投资成本和指数级上升的运维工作，让很多中小型企业望而却步。
随着OceanBase
4.0+分布式一体化架构的推出，用户可以在数据量小的时候选择单机部署，在高可用要求不高的时候选择主备模式，也可以在上了一定规模后使用全分布式架构。不同架构的选择并不意味着性能的损失，因为OceanBase在设计时就考虑了不同形态下的性能优化，性能可以做到和单机数据库相当。
一个产品是否成熟最好的体现就是能够提供给用户更多的选择。随着国产化进程的持续推进，众多国产化软硬件产品在这个过程中得到了众多客户的支持，使得产品能够快速成熟起来。分布式数据库由于能够更好的解决高可用问题，最先得到了客户的认可，而随着分布式一体化产品的日臻完善，满足高可用的同时又不会有太多的性能损失，硬件投资和运维成本也在可控的范围，这样的产品会加速集中式商业数据库的替代吗？我们拭目以待！
