OceanBase从2010年开始研发，下图展示了 OceanBase 0.5版本的整体架构。彼时 OceanBase分成存储和计算两层。上一层是无状态提供SQL服务的服务层，下一层是由两种server共同组成的存储集群。
最初，OceanBase采用基于UpdateServer架构的设计，该架构在一定程度上支持可扩展性，特别是在读取方面表现较为强大。同时，SQL层是无状态的，可以自由伸缩。然而，这一架构的主要瓶颈在于写入节点为单点写入、多点读取的结构，无法在大规模并发需求下进行有效扩展。此外，将存储层和SQL层分离可能导致查询时延难以控制，对于对时延要求极低的应用场景而言，这是一个值得关注的问题。
为了应对上述问题，OceanBase进行了新架构的开发，即图1-5的OceanBase 1.0 - 3.0版本。这一架构采用了完全对等的节点，所有节点都能够同时处理SQL、事务和保存数据。在纵向方向上，该架构提供了分布式可扩展性，而在横向方向上则实现了高可用性。通过不断添加机器，服务的可扩展性得到了显著提升。因此，OceanBase的新架构更有效地支持大规模并发需求，并能更好地控制查询时延。
在演进到4.0版本之前，OceanBase的原有架构已经具有极好的扩展性。并且基于3.0的架构参加了TPC-C测试，使OceanBase成为当时唯一通过TPC-C测试的国产分布式数据库。这表明OceanBase 3.0架构在水平扩展性上有出色的适应性。从三个节点到OceanBase在测试中达到7.07亿tpmC指标，随着节点数量的增加，整个tpmC指标呈现出良好的线性扩展性。在参加TPC-C评测时，OceanBase通过1557台机器组成的大集群，在8小时的压测中展示了每秒2000万次的事务处理能力。这表明前面的架构能够支持极好的扩展性和并发处理能力，几乎可以满足世界上绝大多数在线服务系统的需求。
随着业务需求的不断迭代，OceanBase 4.0架构引入了动态日志流的概念，与原有架构相比发生了核心变化。在3.0的版本中，事务扩展和存储扩展的粒度是等同的，但当存储被分成多个分片时，事务处理和高可用能力也以相同的分片为粒度。在4.0版本中，这两个概念被解耦，多个存储分片可以共享一个事务日志流以及对应的高可用服务。这一变化背后的核心思路是，希望能够支持更小的规模下的应用。对于像蚂蚁这样的大规模应用，3.0架构不会遇到瓶颈问题，但随着OceanBase走向通用，特别是针对各种中小企业时，如果日志流的数目和分区数绑定在一起，很多场景下可能无法适应对中小规模企业的支撑。这意味着，如果日志流过多，在更小规模下开销会显得更大。因此，OceanBase 4.0架构的引入是为了更好地适应不同规模企业的需求。下图展示了OceanBase 4.0的架构。
OceanBase是一个基于通用服务器硬件的分布式数据库，没有特殊的硬件要求。它采用Shared Nothing架构，具有分布式执行能力。在服务器上，OceanBase运行一个名为observer的单进程程序作为数据库的运行实例，使用本地的文件存储数据和事务Redo日志。
OceanBase集群部署需要配置可用区（Zone），由若干个服务器组成。可用区是一个逻辑概念，表示集群内具有相似硬件可用性的一组节点。在不同的部署模式下，可用区代表不同的含义。例如，当整个集群部署在同一个数据中心（IDC）内时，一个可用区的节点可以属于同一个机架、同一个交换机等；当集群分布在多个数据中心时，每个可用区可以对应于一个数据中心。
在分布式集群内部，用户存储的数据可以存储多个副本，用于故障容灾和分散读取压力。在一个可用区内部，数据只有一个副本；不同的可用区可以存储同一个数据的多个副本，副本之间由共识协议保证数据的一致性。
OceanBase内置多租户特性，每个租户对于使用者是一个独立的数据库。一个租户能够在租户级别设置租户的分布式部署方式。租户之间CPU、内存和IO都实现了隔离。
通过以上架构，OceanBase实现了高可用、高兼容、水平扩展等特性，支撑各个公司的业务场景落地。
