从0.5到4.0，OceanBase首次突破分布式数据库单机性能瓶颈

2022年，OceanBase4.0小鱼正式公布。这个版本有一个形象的比喻，叫做“小就是大”，旨在使OceanBase从原来支持大型企业为主，真正走向中小型企业。而作为业内首个单机分布式一体化架构的数据库，OceanBase 4.0的诞生是一次全新的尝试，也是数据库领域的重大的突破和创新。

OceanBase的12年

2010 年，OceanBase开始研发。彼时OceanBase分成存储和计算两层，上一层是无状态提供 SQL 服务的服务层，下一层是由两种 server 共同组成的存储集群。

这样的架构能够使OceanBase比较好的支撑类似于淘宝收藏夹的业务，具有一定的扩展性，特别是读的扩展性比较强，并且 SQL 层是无状态的，可以自由的伸缩。但同时，这个架构面临最主要的问题是由于写入的节点为UpdateServer节点，其是单点写入、多点读的架构，会导致在更大规模并发要求下，没有办法进行扩展。

另外，研发人员还发现，以这样的方式去割裂存储层和SQL层之后，查询时延不好控制。实际上网络服务很难控制时延，会有一些抖动，如果对时延要求极高情况下，很难控制时延抖动。

为了解决这些问题，OceanBase摒弃之前的架构，发展出了OceanBase1.0 - 3.0的架构，整体上来说是一个完全对等的节点，所有的节点都可以在处理 SQL 的同时，处理事务并保存数据。

其实，演进到 4.0 版本之前，OceanBase原有的架构已经有了非常好的扩展性。当时 3.0 版本参加了 TPC-C 测试，OceanBase是当时唯一一个通过了TPC-C测试的分布式数据库，也是唯一一个通过TPC-C测试的国产数据库，而且到目前为止保持世界第一。

但随着业务需求的迭代，4.0架构还是应运而生。OceanBase 4.0 架构核心的变化，是引入动态日志流的概念。原来把事务扩展和存储扩展的粒度等同起来一起去看，但如果存储分成了若干个分片，导致事务处理和高可用能力也是以这样的分片为粒度的。而4.0版本里把这两个概念进行了解耦，所以若干个存储的分片会共享一个事务日志流以及这个日志流所对应后面的高可用服务。

这一变化背后最核心的思路，是研发者们希望能够支撑更小的规模下的一些应用。比如蚂蚁这样大规模应用里，3.0 架构不会遇到瓶颈问题，但随着 OceanBase 走向通用，特别是各种各样的中小企业时，如果日志流的数目和分区数绑定到一起的话，在很多场景下是不能适应对中小规模企业支撑的。也就是说，如果日志流特别多，在越小规模下开销显得就会越大。

基于此，OceanBase开始架构单机分布式一体化的数据库体系结构。

单机分布式一体化

4.0 架构既可以通过分布式方式使用 OceanBase 数据库，也可以用大家原来熟悉的类似 MySQL 单机方式使用 OceanBase。

第一，如果以单机方式部署 OceanBase，或者在 OceanBase 集群内部署单容器租户，都能提供原来使用单机数据库一样的效率和性能。

第二，如果使用分布式模式，在租户层面上、事务层面上以及单条 SQL 执行层面上，都不需要因为引入了分布式而付出额外代价。在这种情况下，需要我们在 SQL 层、存储层、事务层各层设计上，以一种单机分布式一体化设计的方式去满足各种情况，在各个层面上做到兼顾。

而当OceanBase拥有单机分布式一体化能力后，对于用户也会产生两个维度的价值和意义。

第一，OceanBase 既可以单机方式部署，提供单机数据库相当的能力，并且可以在任何时刻，管理员可以去做形态的变换，由一个单机的形态变成分布式形态，从分布式形态变回单机形态，都可以做动态变换的。

第二，即使是在分布式部署场景下，相较于其他分层的分布式数据库，OceanBase 的性能有很大的优势，如果用户做精细控制的话，单机事务比例增加以后，效率和单机数据库也是相当的。

可以说，OceanBase 4.0真正开启了数据库小型化的进程，也诠释着“小即是大”的理念。