OceanBase领域模型

组成维度

1

N

部署OCP

并行优化最重要的参考信息是数据的分布信息（Location），即查询所需访问的每个分区的各个副本在集群中的存储位置，这一信息由总控服务（主）（Master Root Service）维护，为了提升访问效率该分布信息还有缓存机制

创建租户

Parser

日志副本

【租户内存】observer租户内存（ observer 总内存 - system_memory）observer system 内存 （system_memory)

Plan Cache

租户级别，使用Paxos协议，包含保证分布式事务的一致性 C

转储操作1、目的是不断的把内存的 MemTable 写入磁盘以释放内存空间2、转储过程首先会冻结 MemTable（阻止当前的 MemTable 再有新的写入），并生成新的活跃 MemTable3、Partition 副本可以独立决定冻结当前 MemTable，并转储到磁盘上4、转储出的数据只与相同大版本的增量数据做数据归并，不与全局静态数据合并合并操作1、是将动、静态数据做归并，会比较费时；当转储产生的增量数据积累到一定程度时，通过 Major freeze 实现大版本的合并

span style=\

写数据

OBProxy无状态，即使宕机重启也不会影响数据一致性，所以OBProxy在部署时都带有一个守护进程，周期性检 查OBProxy的健康程度，一旦发现宕机就立即重启OBProxy

OB的表都是分区维度

parser tree

1、普通表默认就是一个分区 1:12、分区表就看实际有多少分区1:N

Transformer（逻辑改写模块）：在查询优化中，经常利用等价改写的方式， 将用户SQL转换为与之等价的另一条SQL， 以便于优化器为之生成最佳的执行计划，我 们称这一过程为“查询改写” Transformer 在 resolver 之 后 ， 分析用户 SQL的语义，并根据内部的规则或代价模型， 将用户SQL“改写”为与之等价的其他形式， 并将其提供给后续的优化器做进一步的优化

只读型副本

Optimizer

优先级：<code style=\

所在OB Server来提供

资源池

SQL相关timeout设置，OB Proxy

OB Proxy 集群

支持的事务隔离级别1、MySQL租户支持1.1、读已提交1.2、可重复读两种隔离级别2、ORACLE租户支持2.1、Read Committed：避免脏读，存在不可重复度和幻读2.2、Serializable：避免脏读、不可重复读、幻读

增量数据（写内存）MemTable

事务隔离级别

◼测试模式：主要用于现阶段开发调试，无需依赖 ConfigServer     ⚫ ConfigServer是OCP平台提供的OB集群物理入口管理服务，是一个web api的服务     ⚫ 测试模式通过指定集群的RSList（ip列表）来启动，OBProxy 集群仅可访问创建 OBProxy 集群时 指定的那个 OceanBase 集群，OBProxy 集群创建成功后不可追加可连接的 OB 集群◼ 生产模式     ⚫ ObProxy可以通过指定 config server 提供的 config_url 来启动，config server服务可以协助获 取该集群的配置信息。同一个config server可以保存多个OB集群的RSList信息，使obproxy能为 多个OB集群同时提供服务    ⚫ 在连接ObProxy时，其用户名类似 root@sys#cluster，其中 root 为用户名，sys 为租户名， cluster 为集群名

1、支持单节点 和 三节点两种部署方式2、span style=\

LDC

进行Fast Parser

SQL请求

MemStore使用率 达到 freeze_trigger_percentage（默认70%）触发冻结及后续的转储/合并 等行为

➢ 读写分离策略

Root Service（Master）

observer总内存（memory-limit（优先））（memory-limt-percentage)为 OS 预留内存(1-observer内存）

Tablet

获取

Redo-Log

功能

路由

1、可通过 OCP 或者 命令行 部署 OceanBase 集群。2、span style=\

SQL Plan Management（SPM）

资源池的Unit_Nums

命中

1、如果 OB Server 进程异常终止，通过 server_permanent_offline_time参数（比照参考值）的值来判定是否进行“临时下线”处理2、故障时间小于这个值，代表系统认为异常服务器可能随时会恢复，所以暂时不做处理，此时异常副本在集群内还有2份，还是处于多数，所以不影响对外提供服务，不过如果再有服务器出问题，则会停止对外服务3、故障时间大于这个值，ob 会将机器作“临时下线”处理，从其他zone的主副本中，将缺失的数据复制到本zone内剩余的机器上，以维持副本个数异常终止的observer进行恢复后，会自动加入集群，如果已经做过“临时下线”处理，需要从本zone内其他机器上将 unit迁移过来

租户

➢ 依赖两阶段提交协议保证分布式事务的原子性；

1、1个租户中的每个zone，只能有1种资源池；2、1个租户每个zone可以配置不一样的资源池3、也就是说，租户中每个zone可以是不同的参数配置，即每个zone中的unit总尺寸可以不同

➢ 采用MVCC进行并发控制， 实现read-committed隔离级别；➢ 所有修改的行加互斥锁，实现写 - 写互斥；➢ 读操作读取特定快照版本的数据，读写互不阻塞；

###### GTS服务高可用（保证 一致性Consistency）- `GTS` 是**集群的`核心`**，**根据**`租户的级别不同`**采用**`不同的方式实现高可用`  - 用户租户    - OceanBase 数据库使用**`租户级别`内部表 `__all_dummy`的 `leader` **作为 **`GTS 服务提供者`**，`时间`**来源于**`该leader 的本地时钟`    - **`GTS`默认是`三副本`的**，其**`高可用能力`跟`普通表的能力`一样**  - 系统租户    - 使用 `__all_core_table 的 leader` **作为** `GTS 服务的提供者`，`高可用能力`与`普通表`**一样**    - 时间戳正确性保证如果Leader主实例出现问题，则需要按照Paxos协议重新选主

备份/恢复的最小单位

副本

分区表特点：可多机扩展提高可管理性提高性能自动负载均衡、自动容灾对业务透明，可以取代“分库分表”方案支持分区间并行单表分区个数最大8192单机partition支持上限： 8万（推荐不超过3万）

一个分区可以有多个副本

1..*

部署环境配置

样例

logical plan

写入新的执行计划

计划缓存(Plan Cache)

A.原子性

监控 && 运维

转储 minor freeze

Table Group

集群

部署 OMS/ODC

使用OAT图 形化界面部 署 OCP 和 OBServer

通知OB Server异步刷新DDL执行结果

慢查询

Hint

Root Service

一个租户在同一个Server上最多有一个Unit

C.一致性

OB Server所处位置

连接管理

Other Area

租户N 内存（memstore_limit_percentage）租户N cache memory font color=\"#000000\

1、在1个租户中，1个资源池只能有1种unit2、依靠超过1的ZONE_LIST属来设定1:N的关系

表

在收到用户发送的SQL请求串后，Parser会将字符串分成一个个的“单词”，并根据预先设定好的语法规则解析整个请求，将 SQL请求字符串转换成带有语法结构信息的内存数据结构，我们 称为“语法树”（Syntax Tree）为了加速SQL请求的处理速度，OceanBase对SQL请求采用了**特有的`快速参数化`**，**以加速查找**`plan cache的速度`特有的参数化过程：OB：先参数化，之后立即用这个做键找寻执行计划缓存，如果不存在再进行语法树解析传统数据库：先进行语法树解析，然后将结果作为键找寻执行计划缓存

通 过 OCP 创 建 OceanBase 租户。

通过 OCP 部署 OB Proxy ， 实现负载均衡。

部署OB Proxy

Config Server

转储文件

SQL语句

触发 minor 或 major freeze （freeze_trigger_percentage) 1-freeze-trigger_percentage （转储、合并时，这部分内存依然可以使用)

`分层转储`机制：- 多层compaction策略  - **新增**`L0 层`：**被冻结的**`MemTable` 会 **直接 flush** 为 `Mini SSTable`，**可同时存在**`多个Mini SSTable`- 架构变化: `3层` Vs `4层`  - `3层架构`    - memtable + minor sstable(L1) + major sstable (L2)  - `4层架构`    - memtable + **mini sstable(L0)** + minor sstable(L1) + major sstable (L2)

OB Proxy

font color=\"#000000\

OBProxy 支持备优先读路由策略，通过用户级别系统变量 proxy_route_policy 控制备优先读路由。备优先读仅在 弱一致性读时生效，且优先读 follower 而非主备均衡选择：1、取值为 <code style=\

Executor（执行器）：◼ 对于本地执行作业，Executor会简单的从执行计划的顶端的 算子开始调用，由算子自身的逻辑完成整个执行的过程，并 返回执行结果◼ 对于远程或分布式作业，Executor需要根据预选的划分，将 执行树分成多个可以调度的job，并通过RPC将其发送给相关 的节点执行

Optimizer（优化器）：优化器是整个SQL请求优化的核心，其作用是为SQL请求生成最佳的执行计划;在优化过程中，优化器需要综合考虑SQL请求的语义、对象数据 特征、对象物理分布等多方面因素，解决访问路径选择、连接顺 序选择、连接算法选择、分布式计划生成等多个核心问题，最终 选择一个对应该SQL的最佳执行计划为了充分利用OceanBase的分布式架构和多核计算资源的优势， OceanBase的查询优化器会对执行计划做并行优化：根据计划树 上各个节点的数据分布，对串行执行计划进行自底向上的分析， 把串行的逻辑执行计划改造成一个可以并行执行的逻辑计划

SQL Cache

可以有多个从实例

Fast Parser

IDC

Outline

I.隔离性

Code Generator（代码生成器）：优化器负责生成最佳的执行计划，但其输出的结果并不能立即执 行，还需要通过代码生成器将其转换为可执行的代码，这个过程 由Code Generator负责Code Generator执行的过程只是忠实地将优化器的生成结果翻 译成可执行代码，并不做任何优化选择

GTS（Global Timestamp Service）全局唯一的时间戳服务

stmt‘

其中的一种存在形式

2

【多租户共享内存】system内存system_memory

CREATE [UNIQUE] INDEX index_name ON table_name ( column_list ) [LOCAL | GLOBAL]  [ PARTITION BY column_list PARTITIONS N ] ;- 创建索引（MySQL模式）- ```sql  ALTER TABLE table_name ADD INDEX|KEY index_name ( column_list ) ;  ```**局部索引与全局索引**###### 概述当分区表出现之后，情况发生了变化：`主表`的`数据`**按照**`分区键（Partitioning Key）的值`**被分成**了`多个分区`，`每个分区`**都是**`独立的数据结构`，`分区之间的数据`**没有交集**。这样一来，索引所依赖的单一数据结构不复存在，那索引需要如何应对呢？——**这就引入了“局部索引”和“全局索引”两个概念**- **`局部索引`**  - `局部索引`又名`分区索引`，创建索引的分区`关键字是LOCAL`，`分区键`**等同于**`表的分区键`，`分区数`**等同于**`表的分区数`，总之，**`局部索引的分区机制`和`表的分区机制`一样的**     意味着 局部分区索引 是建立在 表分区的基础上的，在每个分区内 建立 的局部索引- **`全局索引`**  - `全局索引`的创建规则是**在**`索引属性中`指定`GLOBAL关键字`  - 与局部索引相比    - `全局索引最大的特点`是`全局索引的分区规则`**跟**`表分区`是**相互独立的**，`全局索引`**允许指定**`自己的分区规则`和`分区个数`，**不一定需要**跟`表分区规则`**保持一致**

Minor Dump

physical plan

OceanBase 数据库每个服务器的计划缓存都是独立的执行计划缓存的相关视图及不支持的场景- `计划缓存`相关的`视图`：  - `(g)v$plan_cache_stat`    - 记录`每个计划缓存的状态`，每个计划缓存在该视图中有一条记录  - `(g)v$plan_cache_plan_stat`    - 记录`计划缓存中所有执行计划的具体信息及每个计划总的执行统计信息`  - `(g)v$plan_cache_plan_explain`    - 记录某条 SQL 在计划缓存中的执行计划- `计划缓存`**暂不支持的场景**  - 执行计划所占内存超过20 MB 时，不会加入计划缓存  - 如果该计划为分布式执行计划且涉及多个表，不会加入计划缓存- 一次完整的语法解析、语义分析、查询改写、查询优化、代码生成的SQL编译流程称为一次硬解析（毫秒级）`  - `硬解析生成执行计划的过程比较耗时（一般为`毫秒级`），这对于OLTP语句来说是很难接受的- OceanBase通过计划缓存（Plan Cache）`来**避免**`SQL硬解析`

数据库

1、以root用户登录OCP服务器，执行以下命令 bash init_obcluster_conf.sh 2、在显示的模式选择中，选择1-单点部署，选择3-3节点部署。 3、系统生成配置模式 4、根据注释信息，修改配置模板，之后可以开始部署

Resolver（语义解析模块）： 当SQL请求字符串经过语法、词法解析，生成“语法树”之后， resolver会进一步将该语法树转换为带有数据库语义信息的内部 数据结构在这一过程中，resolver将根据数据库元信息将SQL请求中的 token翻译成对应的对象（例如库、表、列、索引等），生成的 数据结构叫做Statement Tree（语句树）

Unit是副本的存储容器

Code Generator

作为集群中的Zone或者说OB Server的反向代理，为其服务，与其交互

SQL 执行计划

OB故障切换的粒度：表或者分区表的子分区，也就是单位为 分区分区：是数据迁移的最小单位

Executor

➢ 备优先读策略

先查看是否命中

1、同一个分区不能跨Unit，同一个分区表的不同分区可以跨Unit2、同号分区组的分区会聚集在同一个Unit内部

0

MVCC

总体介绍（Root Service）1、OceanBase的核心模块，管理整个集群2、集群内置服务，无需额外软、硬件部署3、自带高可用能力，无单点故障风险核心功能1、系统初始化（BootStrap）；系统元数据管理2、资源分配及调度：分区及副本管理、动态负载均衡、扩容/缩容等3、全局DDL；集群数据合并

部署OAT

RSList

D.持久性

依靠，保证分布式事务全局一致性

###### 常量不能参数化的场景- 所有 ORDER BY 后常量（例如\

Transformer

索引

基于

KV Cache会被其它众多内存模块复用

Primary Zone

对于已上线的业务，如果出现优化器选择的计划不够优化时，则需要在线进行计划绑定，即无需业务进行 SQL 更改， 而是通过DDL 操作将一组 Hint加入到SQL中，从而使优化器根据指定的一组 Hint，对该 SQL生成更优计划。该组 Hint 称为Outline

1、对SQL做基本解析，确定对应Leader所在服务器；2、反向代理，将请求路由至对应的Leader；Leader位置无法确定时随机选择OB Server；3、轻量SQL解析+快速转发，保证高性能，单OB Proxy每秒转发100w次请求；1、每个OB Proxy是一个“无状态”的服务进程，不做数据持久化，对部署位置无要求；2、OB Proxy不参与数据库引擎的计算任务，不参与事务（单机or分布式）处理；3、不需要独立服务器，可以与OB Server共用一台服务器，如果应用对实时性要求高，也可以将OB Proxy部署到应用服务器中。OB Proxy 无需单独部署，任挑一个OB Server 都可以部署，通过OCP把安装包安装上去

OB Proxy所处位置

全能型副本

租户1 内存（memstore_limit_percentage） 租户1 cache memoryfont color=\"#000000\

SQL Plan BaseLineSQL执行计划基线

不可动态伸缩的内存

可动态伸缩的内存

leader副本

分区表的全局索引不再和主表的分区保持一对一的关系，而是将所有主表分区的数据合成一个整体来建立全局索引。更 进一步，全局索引可以定义自己独立的数据分布模式，既可以选择非分区模式也可以选择分区模式 ：◼ 全局非分区索引（Global Non-Partitioned Index）◼ 全局分区索引（Global Partitioned Index）    span style=\

◼ 在observer宕机/升级/重启时，客户端与OBProxy的连接不会断开，OBProxy可以迅速切换到正常的server上， 对应用透明◼ OBProxy支持用户通过同一个OBProxy访问多个OceanBase集群◼ Server session对于每个client session独占◼ 同一个client session对应server session状态保持相同(session变量同步)

1、如果多个表的分区方式完全相同（分区类型、分区健个数、分区数量等），可以在逻辑上将这些表归属到同一个Table Group中，以影响动态负载均衡的策略2、同一个Table Group中的所有表，分区ID（partition_id）相同的所有分区，他们的leader在同一个ob server上：在不影响全局负载均衡的前提下，可有效减少分布式事务引入的跨机访问开销3、如果负载均衡被打破（服务器故障后、扩容缩容等），Table Group中的所有表会作为一个整体来调整分区分布和leader分布4、动态创建和删除，并且对上层应用完全透明5、如果租户的 unit_num=1 且 primary_zone只有一个zone，不需要 table group

sys 租户内存（memstore_limit_percentage） sys租户 cache memoryfont color=\"#000000\

➢ Redo-Log使用Paxos协议做多副本同步

Redo-Log主副本所在OB Server 只要等到任何一个从副本响应落盘成功，主副本就认为Commit成功并返回了（应该讲的是默认3个Zone的情况下，有1个反馈就已经是多数了）

MemStore中的MemTable

OB Proxy 无需单独部署，任挑一个OB Server 都可以部署，通过OCP把安装包安装上去

GTS Leader

Zone

Resolver

一个分区在一个Zone中最多有一个全能型副本或日志副本只读型副本在同一个Zone可以有多个

一个主实例

应用

分区（Partition）

OS总内存（物理服务器、VM 、docker)

◼ 周期性汇报统计项到OCP，实现了语句级别，事务级别，session级别，Obproxy级别的各种统计◼ Xflush日志监控（包括慢查询监控、error包监控等）◼ SQL Audit功能 ◼ 实现了大量内部命令来实现远程监控，查询和运维

MemStore占OB内存的比例按照 memstore_limit_percentage 来设

部署备份/恢复服务

弱一致性读

守护进程

###### 自动淘汰相关配置- 当`计划缓存`**占用**的`内存`**达到**了`需要淘汰计划的内存上限`(即**淘汰计划的高水位线**)时，**对**`计划缓存`中的`执行计划`**自动进行淘汰**- **优先淘汰**`最久没被使用的执行计划`，**影响淘汰策略的`参数`和`变量`**如下：  - **`【参数】plan_cache_evict_interval`**：检查执行计划是否需要淘汰的间隔时间  - **`【变量】ob_plan_cache_percentage`**：（**租户内服务器维度**）计划缓存可使用内存占租户内存的百分比    - （**最多可使用内存**为：`租户内存上限` * `ob_plan_cache_percentage`/100）  - **`【变量】ob_plan_cache_evict_high_percentage`**  ：计划缓存使用率（百分比）达到多少时，触发计划缓存的淘汰  - **`【变量】ob_plan_cache_evict_low_percentage`** ：计划缓存使用率（百分比）达到多少时，停止计划缓存的淘汰##### 执行计划缓存的刷新计划缓存中执行计划可能因为各种原因而失效，这时需要将计划缓存中失效计划进行刷新，即将该执行计划删除后重新 优化生成计划再加入计划缓存如下场景会导致执行计划失效，需要对执行计划进行刷新：- SQL 中涉及表的 Schema 变更时（比如添加索引、删除或增加列等），该 SQL 在计划缓存中所对应的执行计划将被刷新- SQL 中涉及重新收集表的统计信息时，该 SQL 在计划缓存中所对应的执行计划会被刷新。由于 OceanBase 数据库 在数据合并时会统一进行统计信息的收集，因此在每次进行合并后，计划缓存中所有计划将被刷新- SQL进行outline计划绑定变更时，该SQL对应的执行计划会被刷新，更新为按绑定的outline生成的执行计划

OceanBase部署流程

1、每个分区在一个Zone上只有1个副本2、每个Zone里可以有多个分区的单一副本

Region

租户简介1、资源隔离策略：内存物理隔离；CPU逻辑隔离，数据隔离2、一般一个应用占用一个租户3、集群创建完成后，会有一个默认的 sys租户被创建，其中会有一个root用户租户特性租户类似传统数据库的实例，它由系统租户根据需要创建出来具有以下特性：1、可以创建自己的用户2、可以创建数据库、表等所有客体对象3、有自己独立的系统数据库4、有自己独立的系统变量5、数据库实例所具备的其他特性span style=\

OB 事务

这些基础概念和OBproxy路由密切相关，根据不同的配置，Obproxy 进行综合的路由排序：◼ LDC配置：    ⚫ 本地： 同城同机房（IDC相同）    ⚫ 同城： 同城不同机房（IDC不同，Region 相同）    ⚫ 异地： 不同的地域（Region不同）◼ Observer 状态： 常态 vs 正在合并span style=\

OB Server 扮演 两阶段提交的，保证原子性的 协调者、参与者的角色，即：这两个角色并不是按照zone来分隔，而是跨zone的 以 OB Server 为单位的；协调者和参与者互相能感知到对方的存在

GTS Follower

Fast Parser后未命中

◼ IDC : 互联网数据中心，可以简单看成一个物理机房◼ LDC ：logical data center ，是对 IDC 的一种逻辑划分◼ Region：地域信息，通常代表一个城市，包含一个或多个IDC，每个IDC部署一个或多个zone。一个OB集群 可以包含若干个Region，每个Region包含若干个IDC，每个IDC部署若干个zone

OB Server

➢ 保证主键唯一等一致性约束； ➢ 全局快照 - 单租户GTS服务， 1秒钟内能够响应获取全局时间 戳的调用次数超过200万次；

跨机分布式事务一致性

Unit

OceanBase <code style=\

对服务器或操作系统 进行一系列的设置， 包 括 设 置 服务器的 BIOS、磁盘挂载、网 卡，添加装机用户， 安装依赖包等。

2、需要proxy提供自身所处的机房信息proxy支持客户端&集中式部署，因此proxy的LDC的支持全局级别&session级别，即可以全局设置默认的LDC，也可 以每个session可以指定使用不同的LDC。font color=\"#000000\

收到用户请求后，OBProxy的执行流程： 1. parse sql，通过简易parse，解析出sql涉及的table name、database name◼ proxy parser在根据SQL选择server时，有以下几点特殊的逻辑：    ⚫ proxy parser只解析Begin/START/TRANSACTON/SET/和其他DML，如果遇到其他单词开头的语句，proxy 的parser会直接跳过，认为该语句不包含表名    ⚫ proxy parser会按照第一条包含实体表名的stmtement进行路由，如果整个stmtement都不包含表名，则将 请求发送至上一条SQL所发送的server◼ observer会根据执行计划的类型，来告诉proxy是否将请求路由至正确的server，如果路由失败，proxy会更新 location，当前的反馈机制如下：    ⚫ server返回第一条DML的命中情况2. fetch route entry，根据用户的tenant name、database name、table name、partition id 向observer拉取该partition的路由表3. sort route entry，根据各种相关属性对路由表中ip进行排序    ⚫ read_consisitency：强一致性读or弱一致性读    ⚫ 目标server状态 ：正在合并or常态    ⚫ 路由精准度： PS or TS    ⚫ LDC 匹配： 本地、同城、异地    ⚫ Zone 类型    ⚫ 读写分离的ob_route_policy取值4. filter by congestion，从路由表中依次尝试目标ip，通过黑名单进行过滤5. forward request，将用户请求转发给目标server

stmt

基线数据 SS Table

部署 OceanBase 集群

每个Unit只能属于1个租户

合并 Major freeze

转储和合并的最大区别在于，合并是集群上所有的Partition 在一个统一的快照点和全局静态数据进行合并的行为，是一个全局的操作，最终形成一个全局快照。转储和合并的对比如下所示：转储（Minor freeze）                          1、Partition 级别，只是MemTable的物化2、每个Partition 独立决定自己MemTable的冻结操作，主备Partition无需保持一致3、转储只与相同大版本的Minor SSTable 合并，产生新的Minor SSTable，所以只包含增量数据，最终被删除的行需要特殊标记合并（Major freeze）1、全局级别，产生一个全局快照2、全局Partition一起做 MemTable 的冻结操作，要求主备Partition保持一致3、合并会把当前大版本的 SSTable 和 MemTable 与前一个大版本的全量静态数据进行合并，产生新的全量数据