一、架构图
OceanBase 数据库采用无共享（Shared-Nothing）分布式集群架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎、事务引擎，运行在普通 PC 服务器组成的集群之上，具备高可扩展性、高可用性、高性能、低成本、与主流数据库高兼容等核心特性。
OceanBase 数据库的一个集群由若干个节点组成。这些节点分属于若干个可用区（Zone），每个节点属于一个可用区。可用区是一个逻辑概念，表示集群内具有相似硬件可用性的一组节点，它在不同的部署模式下代表不同的含义。例如，当整个集群部署在同一个数据中心（IDC）内的时候，一个可用区的节点可以属于同一个机架，同一个交换机等。当集群分布在多个数据中心的时候，每个可用区可以对应于一个数据中心。每个可用区具有 IDC 和地域（Region）两个属性，描述该可用区所在的 IDC 及 IDC 所属的地域。一般情况下，地域指的是 IDC 所在的城市。可用区的 IDC 和 Region 属性需要反映部署时候的实际情况，以便集群内的自动容灾处理和优化策略能更好地工作。根据业务对数据库系统不同的高可用性需求，OceanBase 集群提供了多种部署模式，关于部署模式的更多信息，参见 OceanBase 集群高可用部署方案简介。
在 OceanBase 数据库中，一个表的数据可以按照某种划分规则水平拆分为多个分片，每个分片叫做一个表分区，简称分区（Partition）。某行数据属于且只属于一个分区。分区的规则由用户在建表的时候指定，包括 Hash、Range、List 等类型的分区，同时还支持二级分区。例如，交易库中的订单表，可以先按照用户 ID 划分为若干个一级分区，再按照月份把每个一级分区划分为若干个二级分区。对于二级分区表，二级分区的每个分区是一个物理分区，而一级分区只是逻辑概念。一个表的若干个分区可以分布在一个可用区内的多个节点上。每个物理分区有一个用于存储数据的存储层对象，叫做 Tablet，用于存储有序的数据记录。
当用户对 Tablet 中的记录进行修改时，为了保证数据的持久化，需要记录 Redo 日志到 Tablet 对应的日志流（Log Stream）中。每个日志流服务了其所在节点上的多个 Tablet。为了能够保护数据，并在节点发生故障时不中断服务，每个日志流及其所属的 Tablet 有多个副本。一般来说，多个副本分散在多个不同的可用区里。多个副本中有且仅有一个副本接受修改操作，叫做主副本（Leader），其他副本叫做从副本（Follower）。主从副本之间通过基于 Multi-Paxos 的分布式共识协议实现了副本之间数据的一致性。当主副本所在节点发生故障时，一个从副本会被选举为新的主副本并继续提供服务。
在集群的每个节点上会运行一个叫做 observer 的服务进程，它内部包含多个操作系统线程。节点的功能都是对等的。每个服务负责自己所在节点上分区数据的存取，也负责路由到本机的 SQL 语句的解析和执行。这些服务进程之间通过 TCP/IP 协议进行通信。同时，每个服务会监听来自外部应用的连接请求，建立连接和数据库会话，并提供数据库服务。关于 observer 服务进程的更多信息，参见 线程简介。
为了简化大规模部署多个业务数据库的管理并降低资源成本，OceanBase 数据库提供了独特的多租户特性。在一个 OceanBase 集群内，可以创建多个互相之间隔离的数据库"实例"，叫做租户。从应用程序的视角来看，每个租户等同于一个独立的数据库实例。不仅如此，每个租户可以选择 MySQL 或 Oracle 兼容模式。应用连接到 MySQL 租户后，可以在租户下创建用户、Database，与一个独立的 MySQL 库的使用体验一致。同样的，应用连接到 Oracle 租户后，可以在租户下创建 schema、管理角色等，与一个独立的 Oracle 库的使用体验一致。一个新的集群初始化之后，就会存在一个特殊的名为 sys 的租户，叫做系统租户。系统租户中保存了集群的元数据，是一个 MySQL 兼容模式的租户。
二、采用架构
Shared-Nothing 架构优点
易于扩展：高并发、大数据量提供高扩展能力。
内部处理自动化并行。
三、功能适用性
OceanBase 数据库社区版仅提供 MySQL 模式。
为了隔离租户的资源，每个 observer 进程内可以有多个属于不同租户的虚拟容器，叫做资源单元（Unit）。资源单元包括 CPU 和内存资源。每个租户在多个节点上的资源单元组成一个资源池。
为了实现 OceanBase 数据库对应用程序屏蔽内部分区和副本分布等细节，使应用访问分布式数据库像访问单机数据库一样简单，我们提供了 OceanBase 数据库代理 ODP（OceanBase Database Proxy，又称 OBProxy）服务。应用程序并不会直接与 OceanBase 数据库节点建立连接，而是连接 ODP，然后由 ODP 转发 SQL 请求到合适的 OceanBase 数据库节点。ODP 是无状态的服务，多个 ODP 节点通过网络负载均衡（例如，SLB）对应用提供统一的网络地址。
四、组件解析
cluster 集群是OB最上面一层，一套集群分布在不同的region 中，每个region可以有多个zone.每个zone可以有多个observer.同时observer中可以有多个租户。
region 物理概念：对应物理上的城市或者地域。集群有多个region时，数据库具有地域容灾能力。
zone 逻辑概念：一个region内可以有多个zone，ob的数据采用多副本方式存储，分别存储在不同的zone里面，由paxos协议选主。
observer是一个单进程软件，通常一台物理机或者虚拟服务器运行一个observer进程，我们称为节点。一个zone内可以有多个observer.
租户概念：一个OBserver内可以有多个租户，每个租户资源cpu可以超卖，内存隔离。
五、sql流转方式
接入层：对接连接，鉴权校验用户密码。
SQL层：语法词法解析，sql优化，生产执行计划。并执行。
事务层：原子性、隔离性。
均衡层：扩容、缩容 对应的分区块迁移。以分区块做迁移（分区块就是hase分区分为多个分区块）
复制层：数据同步的方式 log stream 日志流。类似于binlog。
存储层：内存表，磁盘表
六、高可用方案
- 基于 Paxos 一致性协议的多副本高可用解决方案
该方案基于Paxos一致性协议实现，通常在同一个集群内通过多副本（例如，三副本或五副本）提供容灾能力。
在少数派副本不可用（三副本集群允许一个副本不可用，五副本集群允许两个副本不可用）时，数据库可以自动执行容灾切换并恢复服务，保证不丢数据（RPO = 0），故障恢复时间在 8 秒以内（RTO < 8s）。
- 基于日志异步复制的物理备库解决方案
该方案类似于传统数据库的主备复制解决方案。两个或多个集群之间，允许以租户为粒度，通过异步复制 Redo 日志来构建租户级别的主备关系，提供计划内无损切换和故障时有损切换两种容灾能力。
该方案主要用于满足双机房或双地域场景下的容灾需求。主租户提供读写能力，备租户提供只读和容灾能力。在执行计划内无损切换时，主租户和备租户互换角色，不丢数据（RPO = 0），切换时间为秒级（RTO 为秒级）。
当主租户所在的集群出现故障后，可以执行有损切换，将备租户切换为主租户。此时不能保证不丢数据，RPO 大于 0，切换时间为秒级（RTO 为秒级）。
- 基于仲裁的高可用解决方案
该方案是 OceanBase V4.1.0 版本新提供的一种高可用解决方案。该方案通过引入一个独立的仲裁服务，允许通过更少副本数提供良好的容灾能力。
这里以两个全功能副本和一个仲裁服务的部署架构为例：在一个全功能副本出现故障时，集群会在仲裁服务参与的情况下，自动执行容灾降级，保证数据不丢（RPO = 0），切换时间为秒级（RTO 为秒级）；在故障节点服务恢复后，集群会自动探测并执行服务升级，恢复故障前的可用能力。在此过程中，仲裁服务仅参与同步和持久化少量的元信息，资源开销（CPU/内存/网络等）极小。
- 同机房三副本
如果只有一个机房，可以部署三副本或更多副本，来达到机器级无损容灾。当单台 Server 或少数派 Server 宕机情况下，不影响业务服务，不丢数据。如果一个机房内有多个机架，可以为每个机架部署一个 Zone，从而达到机架级无损容灾。
- 同城双机房物理备库
如果同城只有双机房，又想达到机房级容灾能力，可以采用物理备库，每个机房部署一个集群。当任何一个机房不可用时，另一个机房可以接管业务服务。如果备机房不可用，此时业务数据不受影响，可以持续提供服务；如果主机房不可用，备库需要激活成新主库，接管业务服务，由于备库不能保证同步所有数据，因此可能会丢失数据。
- 同城三机房三副本
如果同城具备三机房条件，还可以为每个机房部署一个 Zone，从而达到机房级无损容灾能力。任何一个机房不可用时，可以利用剩下的两个机房继续提供服务，不丢失数据。这种部署架构不依赖物理备库，不过不具备地域级容灾能力。
- 两地两中心物理备库
用户希望达到地域级容灾，但是每个地域只有一个机房时，可以采用物理备库架构，选择一个地域作为主地域，部署主库，另一个地域部署备库。当备地域不可用时，不影响主地域的业务服务；当主地域不可用时，备库可以激活为新主库继续提供服务，这种情况下可能会丢失业务数据。
更进一步，用户可以利用两地两中心实现双活，部署两套物理备库，两个地域互为主备。这样可以更加高效利用资源，并且达到更高的容灾能力。
- 两地三中心加物理备库
如果用户在两个不同的地域共有三个机房，可以使用 "两地三中心加物理备库" 的方案提供地域级容灾能力。
我们将有两个机房的地域称为主地域，业务在主地域两个机房里各部署一个或两个全功能副本，数据库的读写服务在主地域提供。另外一个地域机房中部署仲裁服务和物理备库，提供容灾服务。
在主地域一个机房出现故障时，仲裁方案会自动执行降级，确保业务在秒级恢复，同时不丢失数据。在主地域两个机房同时出现故障时，需要将物理备库激活成主库提供服务，此时业务有损，RPO > 0。
- 三地三中心五副本
为了支持地域级无损容灾，通过 Paxos 协议的原理可以证明，至少需要 3 个地域。该方案包含三个城市，每个城市一个机房，前两个城市的机房各有两个副本，第三个城市的机房只有一个副本。和两地三中心的不同点在于，每次执行事务至少需要同步到两个城市，需要业务容忍异地复制的延时。
- 三地五中心五副本
与三地三中心五副本类似，不同点在于，三地五中心会把每个副本部署到不同的机房，进一步强化机房容灾能力。
七、存储架构
分为磁盘存储和内存存储
磁盘数据放在sstablen内
在 OceanBase 数据库中, 对于用户表每个分区管理数据的基本单元就是 SSTable，当 MemTable 的大小达到某个阈值后，OceanBase 数据库会将 MemTable 冻结，然后将其中的数据转存于磁盘上，转储后的结构就称之为 Mini SSTable 或者是 Minor SSTable。当集群发生全局合并时，每个用户表分区所有的 Minor SSTable 会根据合并快照点一起参与做 Major Compaction，最后会生成 Major SSTable。每个 SSTable 的构造方式类似，都是由自身的元数据信息和一系列的数据宏块组成，每个数据宏块内部则可以继续划分为多个微块，根据用户表模式定义的不同，微块可以选择使用平铺模式或者编码格式进行数据行的组织。
-
宏块
OceanBase 数据库将磁盘切分为大小为 2MB 的定长数据块，称之为宏块（Macro Block），宏块是数据文件写 IO 的基本单位，每个 SSTable 就由若干个宏块构成, 宏块2M固定大小的长度不可更改, 后续转储合并重用宏块以及复制迁移等任务都会以宏块为最基本粒度。
-
微块
在宏块内部数据被组织为多个大小为 16KB 左右的变长数据块，称之为微块（Micro Block），微块中包含若干数据行（Row），微块是数据文件读 IO 的最小单位。每个数据微块在构建时都会根据用户指定的压缩算法进行压缩，因此宏块上存储的实际是压缩后的数据微块，当数据微块从磁盘读取时，会在后台进行解压并将解压后的数据放入数据块缓存中。每个数据微块的大小在用户创建表时可以指定，默认 16KB，用户可以通过语句指定微块长度，但是不能超过宏块大小，语句如下。
ALTER TABLE mytest SET block_size = 131072;
一般来说微块长度越大，数据的压缩比会越高，但相应的一次 IO 读的代价也会越大；微块长度越小，数据的压缩比会相应降低，但相应的一次随机 IO 读的代价会更小。另外根据用户表模式的不同，每个微块构建的时候可能以平铺模式（Flat）或编码模式（Encoding）分别进行构建。在目前版本中，只有基线数据可以指定使用编码模式组织微块，对于转储数据全部默认使用平铺模式进行数据组织。
内存数据放在memtablen内
OceanBase 数据库的内存存储引擎 MemTable 由 BTree 和 Hashtable 组成，在插入/更新/删除数据时，数据被写入内存块，在 HashTable 和 BTree 中存储的均为指向对应数据的指针。
**HashTable ：**不适合对范围查询使用 HashTable。
**BTree：**单行的查找，也需要进行大量的主键比较，从根结点找到叶子结点，而主键比较性能是较差的，因此理论上性能比 HashTable 慢很多。
LSM-TREE 数据转储和并
-
转储
OceanBase 数据库中的转储即 Minor Compaction 概念可以理解和其他 LSM-Tree 架构数据库的 Compaction 概念类似，主要负责 MemTable 刷盘转成 SSTable 以及多个 SSTable 之间的 Compaction 策略选择以及动作。OceanBase 数据库中采用的是 leveled 结合 size tiered 的 Compaction 策略，大致可以分为三层，其中 L1 和 L2 就是固定的 leveled 层次，L0 层是 size tiered，L0 内部还会继续根据写放大系数以及 SSTable 个数进行内部 Compaction 动作。
-
合并
合并也就是 Major Compaction，在 OceanBase 数据库中也叫每日合并，概念和其他 LSM-Tree 数据库稍有不同。顾名思义，这个概念诞生之初是希望这个动作放到每天凌晨 2 点左右整个集群做一次整体的 Compaction 动作。合并一般是由每个租户的 RS 根据写入状态或者用户设置发起调度，每个租户的每次合并都会选取一个全局的快照点，租户内所有的分区都会用这个快照点的数据做一次 Major Compaction，这样每次合并租户所有的数据都基于这个统一的快照点生成相应的 SSTable，通过这个机制不仅能帮助用户定期整合增量数据，提升读取性能，同时还提供了一个天然的数据校验点，通过全局的一致位点，OceanBase 数据库能够在内部对多副本以及主表索引表进行多维度的物理数据校验。
八、核心特性
- 高可用
支持同城/异地容灾，可实现多地多活，满足金融行业6级容灾标准，数据0丢失。
- 高兼容
高度兼容MySQL和 Oracle，覆盖绝大多数常见功能。
- 水平扩展
实现透明水平扩展，支持业务快速的扩容缩容。
- 低成本
基于LSM-Treez的高压缩引擎，使存储成本降低70%-90%。
- 实时HTAP
基于同一份数据同一个引擎，同时支持实时交易和实时分析两种场景，依靠Btree和hashtable实现
- 安全可靠
代码完全自主研究，代码级可控，自主研发单机分布式一体架构。