OceanBase 数据库整体架构

OceanBase 数据库采用无共享（Shared-Nothing）分布式集群架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎、事务引擎，运行在普通 PC 服务器组成的集群之上，具备高可扩展性、高可用性、高性能、低成本、与主流数据库高兼容等核心特性。更多 OceanBase 数据库部署架构的介绍，参见 系统架构。

OceanBase 数据库使用通用服务器硬件，依赖本地存储，其分布式部署使用的多个服务器也是对等的，没有特殊的硬件要求。OceanBase 数据库的分布式数据库处理采用 Shared Nothing 架构，数据库内的 SQL 执行引擎具有分布式执行能力。

OceanBase 数据库的服务器上会运行一个名为 observer 的单进程程序作为数据库的运行实例，使用本地的文件存储数据和事务 Redo 日志。

OceanBase 集群的部署需要配置可用区（Zone），每个可用区由若干个服务器组成。可用区是一个逻辑概念，表示集群内具有相似硬件可用性的一组节点，它在不同的部署模式下代表不同的含义。例如，当整个集群部署在同一个数据中心（IDC）内的时候，一个可用区的节点可以属于同一个机架，同一个交换机等。当集群分布在多个数据中心的时候，每个可用区可以对应于一个数据中心。

用户存储的数据在分布式集群内部可以存储多个副本，用于故障容灾，也可以用于分散读取压力。同一个租户在一个可用区内的数据只有一个副本，不同的可用区可以存储同一个数据的多个副本，副本之间由 Paxos 协议保证数据的一致性。

OceanBase 数据库内置多租户特性，每个租户相当于一个独立的数据库实例，一个租户能够在租户级别设置本租户的分布式部署方式。各租户之间的 CPU、内存和 IO 等资源相互隔离。

OceanBase 集群的数据库实例内部由不同的组件相互协作，这些组件从底层向上由多租户层、存储层、复制层、均衡层、事务层、SQL 层、接入层组成。

多租户层

为了简化大规模部署多个业务数据库的管理并降低资源成本，OceanBase 数据库提供了独特的多租户特性。在一个 OceanBase 集群内，可以创建很多个互相之间隔离的数据库"实例"，叫做一个租户。从应用程序的视角来看，每个租户等同于一个独立的数据库实例。不仅如此，每个租户可以选择 MySQL 或 Oracle 兼容模式。应用连接到 MySQL 租户后，可以在租户下创建用户、Database，与一个独立的 MySQL 库的使用体验一致。同样的，应用连接到 Oracle 租户后，可以在租户下创建 Schema、管理角色等，与一个独立的 Oracle 库的使用体验一致。一个新的集群初始化之后，就会存在一个特殊的名为 sys 的租户，叫做系统租户。系统租户中保存了集群的元数据，是一个 MySQL 兼容模式的租户。

为了隔离租户的资源，每个 observer 进程内可以有多个属于不同租户的虚拟容器，叫做资源单元（UNIT）。资源单元包括 CPU 和内存资源。每个租户在多个节点上的资源单元组成一个资源池。

存储层

存储层以一张表或者一个分区为粒度提供数据存储与访问，每个分区对应一个用于存储数据的 Tablet（分片），用户定义的非分区表也会对应一个 Tablet。

Tablet 的内部是分层存储的结构，总共有四层：MemTable、L0 层 Mini SSTable、L1 层 Minor SSTable 以及 Major SSTable。DML 操作插入、更新、删除等首先写入 MemTable，待 MemTable 达到一定大小时转储到磁盘成为 L0 层 Mini SSTable。L0 层 Mini SSTable 个数达到阈值后会将多个 L0 层 Mini SSTable 合并成一个 L1 层 Minor SSTable。在每天配置的业务低峰期，系统会将所有的 MemTable、L0 层 Mini SSTable 和 L1 层 Minor SSTable 合并成一个 Major SSTable。

每个 SSTable 由若干个大小为 2MB 的定长宏块组成，每个宏块内部由多个不定长微块组成。

Major SSTable 的微块会在合并过程中通过编码方式进行格式转换，微块内的数据会按照列维度分别进行列内的编码，编码规则包括字典、游程、常量或差值等。每一列压缩结束后，还会进一步对多列进行列间等值或子串等规则编码。编码能对数据大幅压缩，同时提炼的列内特征信息还能进一步加速后续的查询速度。

在编码压缩之后，还可以根据用户指定的通用压缩算法进行无损压缩，进一步提升数据压缩率。

复制层

复制层使用日志流（LS、Log Stream）在多副本之间同步状态。每个 Tablet 都会对应一个确定的日志流，每个日志流对应多个 Tablet，DML 操作写入 Tablet 的数据所产生的 Redo 日志会持久化在日志流中。日志流的多个副本会分布在不同的可用区中，多个副本之间维持了共识算法，选择其中一个副本作为主副本，其他的副本皆为从副本。Tablet 的 DML 和强一致性查询只在其对应的日志流的主副本上进行。

通常情况下，每个租户在每台机器上只会有一个日志流的主副本，可能存在多个其他日志流的从副本。租户的总日志流个数取决于 Primary Zone 和 Locality 的配置。

日志流使用自研的 Paxos 协议实现了将 Redo 日志在本服务器持久化，同时通过网络发送给日志流的从副本，从副本在完成各自持久化后应答主副本，主副本在确认有多数派副本都持久化成功后确认对应的 Redo 日志持久化成功。从副本利用 Redo 日志的内容实时回放，保证自己的状态与主副本一致。

日志流的主副本在被选举成为主（Leader）后会获得租约（Lease），正常工作的主副本在租约有效期内会不停的通过选举协议延长租约期。主副本只会在租约有效时执行主的工作，租约机制保证了数据库异常处理的能力。

复制层能够自动应对服务器故障，保障数据库服务的持续可用。如果出现少于半数的从副本所在的服务器故障，即还有多于半数的副本正常工作，则数据库的服务不受影响。如果主副本所在的服务器出现问题，其租约会得不到延续，待其租约失效后，其他从副本会通过选举协议选举出新的主并授予新的租约，之后即可恢复数据库的服务。

均衡层

新建表和新增分区时，系统会按照均衡原则选择合适的日志流创建 Tablet。当租户的属性发生变更，新增了机器资源，或者经过长时间使用后，Tablet 在各台机器上不再均衡时，均衡层就会通过日志流的分裂和合并操作，并在这个过程中配合日志流副本的移动，让数据与服务在多个服务器之间再次达到均衡。

当租户有扩容操作，获得了更多的服务器资源时，均衡层会将租户内已有的日志流进行分裂，并选择合适数量的 Tablet 一同分裂到新的日志流中，再将新日志流迁移到新增的服务器上，以充分利用扩容后的资源。当租户有缩容操作时，均衡层会把需要缩减的服务器上的日志流迁移到其他服务器上，并与其他服务器上已有的日志流进行合并，以缩减机器的资源占用。

随着数据库的长期使用，用户持续地创建或删除表，并且写入更多的数据，即使服务器资源的数量没有变化，原本均衡的情况也可能会被破坏。最常见的情况是，当用户删除了一批表后，删除的表可能原本聚集在某一些机器上，删除后这些机器上的 Tablet 数量就变少了，应该把其他机器上的 Tablet 均衡一些到这些少的机器上。均衡层会定期生成均衡计划，将 Tablet 多的服务器上的日志流分裂出临时日志流并携带需要移动的 Tablet，临时日志流迁移到目的服务器后再与目的服务器上的日志流进行合并，以达成均衡的效果。

事务层

事务层保证了单个日志流和多个日志流 DML 操作提交的原子性，也保证了并发事务之间的多版本隔离能力。

原子性

一个日志流上事务的修改，即使涉及多个 Tablet，通过日志流的 write-ahead log 也可以保证事务提交的原子性。事务的修改涉及多个日志流时，每个日志流会产生并持久化各自的 write-ahead log，事务层通过优化的两阶段提交协议来保证事务提交的原子性。

当涉及到多个日志流的事务发起提交时，事务会选择其中一个日志流作为两阶段提交的协调者。协调者会与事务修改的所有日志流通信，判断 write-ahead log 是否持久化。当所有日志流都完成持久化后，事务进入提交状态。协调者会再驱动所有日志流写下该事务的 Commit 日志，表示事务最终的提交状态。当从副本回放或者数据库重启时，已经完成提交的事务都会通过 Commit 日志来确定各自日志流事务的状态。

宕机重启场景下，对于宕机前还未完成的事务，会出现写完 write-ahead log 但是还没有写下 Commit 日志的情况。由于每个日志流的 write-ahead log 都包含了事务的所有日志流列表，通过此信息可以重新确定哪个日志流是协调者并恢复协调者的状态，再次推进两阶段提交协议，直到事务达到最终的 Commit 或 Abort 状态。

隔离性

GTS（Global Timestamp Service）服务是一个用于在租户内产生连续增长的时间戳的服务，其通过多副本保证可用性，底层机制与上述 复制层 所描述的日志流副本同步机制一致。

每个事务在提交时会从 GTS 获取一个时间戳作为事务的提交版本号并持久化在日志流的 write-ahead log 中，事务内所有修改的数据都以此提交版本号标记。

每个语句开始（对于 Read Committed 隔离级别）或者每个事务开始（对于 Repeatable Read 和 Serializable 隔离级别）时，都会从 GTS 获取一个时间戳作为语句或事务的读取版本号。在读取数据时，会跳过比自己大的事务版本号选择比当前读取版本号小的所有版本号中最大的版本号的数据，通过这种方式为读取操作提供了统一的全局数据快照。

SQL 层

SQL 层将用户的 SQL 请求转化成对一个或多个 Tablet 的数据访问。

SQL 层组件

SQL 层处理一个请求的执行流程是：Parser、Resolver、Transformer、Optimizer、Code Generator、Executor。其中：

• Parser 负责词法或语法解析。将用户的 SQL 分成一个个的 "Token"，并根据预先设定好的语法规则解析整个请求，转换成语法树（Syntax Tree）。

• Resolver 负责语义解析。根据数据库元信息，将 SQL 请求中的 Token 翻译成对应的对象（例如库、表、列、索引等），生成的数据结构叫做 Statement Tree。

• Transformer 负责逻辑改写。根据内部的规则或代价模型，将 SQL 改写为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化。

  Transformer 的工作方式是在原 Statement Tree 上做等价变换，变换的结果仍然是一棵 Statement Tree。

• Optimizer（优化器）为 SQL 请求生成最佳的执行计划。需要综合考虑 SQL 请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、联接顺序选择、联接算法选择、分布式计划生成等问题，最终生成执行计划。

• Code Generator（代码生成器）将执行计划转换为可执行的代码，但是不做任何优化选择。

• Executor（执行器）启动 SQL 的执行过程。

在标准的 SQL 流程之外，SQL 层还有 Plan Cache 能力，将历史的执行计划缓存在内存中，后续的执行可以反复执行这个计划，避免了重复查询优化的过程。配合 Fast-parser 模块，仅使用词法分析对文本串直接参数化，获取参数化后的文本及常量参数，让 SQL 直接命中 Plan Cache，加速频繁执行的 SQL。

多种计划

SQL 层的执行计划分为本地、远程和分布式三种。本地执行计划只访问本服务器的数据。远程执行计划只访问非本地的一台服务器的数据。分布式计划会访问超过一台服务器的数据，执行计划会分成多个子计划在多个服务器上执行。

SQL 层并行化执行能力可以将执行计划分解成多个部分，由多个执行线程执行，通过一定的调度的方式，实现执行计划的并行处理。并行化执行可以充分发挥服务器 CPU 和 IO 处理能力，缩短单个查询的响应时间。并行查询技术可以用于分布式执行计划，也可以用于本地执行计划。

接入层

OceanBase 数据库代理 ODP（OceanBase Database Proxy，又称 OBProxy）是 OceanBase 数据库的接入层，负责将用户的请求转发到合适的 OceanBase 数据库实例上进行处理。

ODP 是独立的进程实例，独立于 OceanBase 数据库实例部署。ODP 监听网络端口，兼容 MySQL 网络协议，支持使用 MySQL 驱动的应用直接连接 OceanBase 数据库。

ODP 能够自动发现 OceanBase 集群的租户及数据分布信息，对于代理的每一条 SQL 语句，能尽可能识别出该语句将要访问的数据，并将该语句直接转发到数据所在服务器的 OceanBase 数据库实例。

ODP 有两种部署方式，一种是与 OBServer 节点分开部署（单独的机器部署或者与应用部署在同一台机器上），另一种是部署在 OBServer 节点所在的机器上。部署 ODP 代理后，用户的所有请求会由 ODP 发送到合适的 OceanBase 数据库服务器。用户可以使用网络负载均衡服务将多个 ODP 聚合成同一个对应用提供服务的入口地址。

有关 ODP 部署方式的更多介绍，参见 ODP 官方文档。