B

本地执行（**Local Execution**）

接收客户端请求生成执行计划的数据库服务器和计划实际执行的服务器是同一个。

表（**Table**）

最基本的数据库对象。每个表由若干行记录组成，每一行有相同的预先定义的列。用户通过 SQL 语句对表进行增、删、查、改等操作。通常，表的若干列会组成一个主键，主键在整个表的数据集合内唯一。

表组（**Table Group**）

对经常会被同时访问的一组表，为了优化性能，需要将它们相同类型的副本存储在同一个 OceanBase 数据库服务器中。通过定义一个 Table group，并且将这一组表放在这个 Table group 中来达到这个目的。此外，同一个 Table group 的多个分区表具有相同的分区数和分区规则。假设一个 Table group 里的表都有 N 个分区，所有这些表的第 i 个分区的集合组成一个 Partition group。同一个 Partition group 里的分区，主副本总是位于同一个 Server上。

并行合并（**Parallel Compaction**）

特指对单个分区的并行合并。

并行执行（**Parallel Execution**）

一个执行计划在执行前，根据需要访问的分区情况，被切分成一个或者多个任务来执行。在执行过程中，调度器可以串行调度计划的多个任务，也可以让多个任务同时被调度执行。这种多个任务被同时调度执行的方式称为并行执行。

布隆过滤器缓存（**Bloom Filter Cache**）

布隆过滤器缓存，用于快速判断行在基线数据或转储数据是否存在，当结果为不存在时，可以减少磁盘 IO 和 CPU 消耗。

备份元数据库/恢复元数据库（**Backup Metadb/ Restore Metadb**）

备份元数据库包含参数表 backup_base_profile 以及控制备份任务的四张表，分别是 base_data_backup、base_data_backup_task、base_data_backup_task_history 和 inc_data_backup 。恢复元数据库包含控制恢复任务的四张表，分别是 oceanbase_restore 、 base_data_restore 、 inc_data_restore 和oceanbase_restore_history 。通常会将备份元数据库和恢复元数据库部署在同一个数据库中。

备份工具程序/恢复工具程序（**AgentServer/agentrestore.jar**）

AgentServer 是备份工具，是一个常驻进程，每隔一段时间查询元数据库 MetaDB 中的 base_data_backup 表有无备份任务，来控制整个基线、增量数据备份的发起、取消，也会随着任务的推进更新备份任务四张表的状态。agentrestore.jar 是恢复工具，顾名思义是 Java 编写的 Jar 包，也是常驻进程，每隔一段时间查询元数据库 MetaDB 中的控制表，负责调度整个恢复任务的发起，也会随着任务的推进更新恢复任务四张表的状态。

C

Commit Log (CLOG)

操作日志，用来记录对数据库对象的修改，通过 WAL 协议，满足事务原子性和持久性的要求。 一个分区的一个事务在执行过程中会产生一条或多条 Commit Log，并通过 Multi-Paxos 协议复制到这个分区的其它副本上。一个分区完整的 Commit Log 序列代表了这个分区完整的修改历史。

查询改写（**Query Rewrite/Query Transformation**）

通过对用户查询做等价的改写以便优化器生成最佳执行计划的过程。

存储过程（**Stored Procedure**）

服务器端提供的用户编程方式。

D

DFO (Data Flow Object)

分布式并行执行计划中，若干个需要在一起流水线执行的算子集合，有时也被称为子计划。

DIO（**Direct Input-Output**）

直接输入输出。

Data Transfer Layer (DTL)

数据传输层，分布式并行执行框架中用于提供各执行线程之间数据传输的网络传输框架。

大版本冻结（**Major Freeze**）

集群中所有的节点在一个统一的快照点冻结当前的活跃 Memtable，不再接受新开启事务的写操作，新事务的写操作在新的活跃 Memtable 中进行。

大版本冻结版本号（**Major Freeze Version**）

大版本冻结的版本号。

地域（**Region**）

Region 指一个地域或者城市（例如杭州、上海、深圳等），一个 Region 包含一个或者多个 Zone，不同 Region 通常距离较远。OceanBase 数据库支持一份数据的多个副本 Region 部署。

地域/互联数据中心（**Region/IDC**）

每台 OBServer 服务器都具有 Region/IDC 属性，其中 Region 记录 OceanBase 集群地域信息，通常代表一个城市，IDC 记录 OceanBase 集群的机房信息。一个 OceanBase 集群包含若干个 Region，每个 Region 包含若干个 IDC，每个 IDC 部署若干个 OBServer 服务器。根据不同 Region 和 IDC，OceanBase 客户端与 OBServer 服务器，或者 OBServer 服务器 OBServer 服务器之间的位置关系可以分为 3 种：同 Region 同 IDC、同 Region 不同 IDC 和不同 Region。三者优先级依次降低。

冻结Memtable（**Frozen Memtable**）

Active Memtable 达到一定的内存阈值，进行冻结生成冻结 Memtable，冻结的 Memtable 不能再写入增量数据。

冻结版本（**Frozen Version**）

发生冻结操作时的版本号。

自适应游标共享（**Adaptive Cursor Sharing**）

一种可以让优化器每一个参数化 SQL 存储多个执行计划，并根据 SQL 语句中谓词的选择性来选择合适的计划的机制。

E

二级索引（**Secondary Index**）

访问数据表的一种辅助数据结构。与主键不同，二级索引通常包括由用户显式或隐式指定的一组键值。在 OceanBase 数据库中，二级索引一般实现为与主表关联的数据表。

F

访问路径（**Access Path**）

数据库中访问某张表的特定方式，通常分为主键访问和二级索引访问。

分布式执行（**Distributed Execution**）

执行计划在多台数据库服务器上执行，每台服务器完成其中的一部分工作。

分裂分区（**Partition Split**）

通过 Schema 变更调整表的分区数，将一个表由一个分区变成多个分区或者多分区的表格变成更多的分区，会触发表已有分区上数据按照新的分区方式重新组织。分裂操作可以在表（Table）上操作，也可以在表组（Tablegroup）上操作，在表组上操作等同于对表组中所有的表按照同样的方式进行分裂。

分区**（Partition）**

与 Oracle 中 Partition 的概念相同，在 OceanBase 数据库中只有水平分区，表的每一个分区包含一部分记录。根据行数据到分区的映射关系不同，分为 hash 分区、range 分区（按范围）和 list分区等。每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区。例如，交易记录表，按照用户 ID 分为若干 hash 分区，每个一级 hash 分区再按照交易时间分为若干二级 range 分区。

分区裁剪**（Partition Pruning）**

数据库根据查询条件，避免访问无关分区的优化过程。分区裁剪可以分为静态和动态两种类型。

副本**（Replica）**

为了数据安全和提供高可用的数据服务，每个分区数据在物理上存储多份，每一份叫做分区的一个副本。每个副本，包括存储在磁盘上的静态数据（SSTable）、存储在内存的增量数据（MemTable）、以及记录事务的日志三类主要的数据。根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全、性能伸缩性、可用性、成本等之间的选择。

• 全能型副本：也就是目前支持的普通副本，拥有事务日志，MemTable 和 SSTable 等全部完整的数据和功能。它可以随时快速切换为 Leader 对外提供服务。

• 日志型副本：只包含日志的副本，没有 MemTable 和 SSTable。它参与日志投票并对外提供日志服务，可以参与其他副本的恢复，但自己不能变为主提供数据库服务。

• 只读型副本：包含完整的日志，MemTable 和 SSTable 等，但是它的日志比较特殊。它不作为 Paxos 成员参与日志的投票，而是作为一个观察者实时追赶 Paxos 成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入 Paxos 成员组，又不会造成投票成员增加导致事务提交延时的增加。

OceanBase 数据库支持的副本类型如下表所示。

副本根据负载和特定的策略，由系统自动调度分散在多个 Server 上。副本支持迁移、复制、增删、类型转换等管理操作。

主/从副本（Leader/Follower）

主/从副本定义了某一时刻某表分区副本的角色。对于 OceanBase 数据库，每个分区至少三副本，副本之间使用 Paxos 协议同步 Leader 的 Redo 到 Follower，策略上三个成员里只要有超过半数以上成员接收到 Redo 并落盘成功确认后，Leader 上的事务才可提交。每个分区的全部副本（三副本，五副本等）是一个独立的 Paxos Group，交付自行独立选主的能力，当一个 OceanBase 节点故障时，只有对应 OceanBase 数据库节点内部作为 Leader 的 observer 服务中断，OceanBase 集群服务会自动选出新的 Leader。

负载均衡（**Load Balance**）

系统根据一定的策略，通过动态调整 UNIT 的位置和 UNIT 内副本的位置，使得同一个 Zone 内所有 Server 的资源使用率达到均衡的过程。负载均衡策略要考虑很多因素，目前分为两级调度。具体信息请参见本节 Partition 调度 和 Unit 调度 的信息。

复制表功能**（Copy Table-Oceanbase 2.X）**

为应对应用访问频率高更新低频率同时总能访问到最新数据的小表访问需求，同时要保证数据一致性，目前只能选择强一致性读访问 Leader 数据的方案。但由于访问频率高，Leader 容易成为性能瓶颈。为了解决“小表广播”需求场景问题，Oceanbase 数据库 V2.x 版本结合自身架构提供了复制表功能，将相关小表的副本复制到表所属租户的所有 OBServer 上。该表称为复制表，这些副本称为复制副本。复制表的更新事务在提交时保证将数据同步到所有的全功能副本及复制副本，确保在更新事务 Commit 成功之后，在租户任意 OBServer 上能读到该事务修改的数据。

G

Granule

分布式并行执行计划中，对于表和索引扫描的最小工作任务粒度，可以是一个分区，或者是一个 query range。

工作线程**（Worker Threads）**

OceanBase 数据库中用以处理租户请求的线程。属于同一个租户的一组工作线程通过共享一个任务队列来服务用户的请求。

H

Hint

数据库中用以直接指定优化器行为的用户原语。

行

一个行由若干列组成，有些时候其中的部分列构成主键（row key）并且整个表按主键顺序存储。有些表（例如，SELECT 指令的结果）可以不包含主键。

行版本合并**（Row Compact）**

将增量行数据中多个修改版本的数据合并成一行数据。

行缓存**（Row Cache）**

基线数据和转储数据的行数据缓存，用于提升查询性能。

合并/每日合并**（Major Compaction）**

将内存 MemTable 中的增量数据以及转储的增量数据和持久化存储上的基线数据进行合并，形成新的基线数据的过程。

合并分区**（Merge Partition ）**

聚合是分裂的逆操作。用户通过 Schema 变更调整表格分区数触发，调整后的分区数比调整前的少。系统会把多个分区按照新的分区方式合并在一起。聚合操作可以在表格（Table）上操作，也可以在表组（Table group）上操作，在表组上操作是对表组中所有的表格按照同样的方式进行聚合。

宏块**（Macro Block）**

OceanBase 数据库数据文件的内部管理单位，包含若干微块，是 OceanBase 数据库存储系统写入的最小单元。

宏块分裂**（Macro Block Split）**

由于宏块范围内插入和更新数据导致空间不足，需要将数据存放到多个宏块中。

宏块合并（**Macro Block Merge**）

由于删除数据，相邻的几个宏块中的所有行可以在一个宏块中存放，把相邻的多个宏块转换成一个宏块的过程。

宏块空间回收（**Macro Block Recycle**）

合并过程中会根据原基线数据和变更数据生成新的基线数据，原基线数据的宏块被重复利用的过程称为回收。

宏块预读（**Macro Block Prefetch**）

在范围查询的过程中，根据需要提前预读取相邻的宏块。

活跃 Memtable（**Active Memtable**）

当前活跃的 Memtable，可以写入增量数据。与 Frozen Memtable 相对应。

J

基线数据（**Baseline Data**）

每日合并生成的存储于持久化介质上的只读有序数据。

基线数据版本（**Baseline Data Version**）

基线数据的版本。

渐进合并**（Progressive Compaction）**

为了降低全量合并对系统的影响，一轮合并操作只合并部分的宏块，经过几轮以后，完成所有宏块的合并。采用渐进合并的主要目的是控制单次合并的时间，在表模式发生变化（如增加、删除列）的时候，需要在合并过程中更新所有行，如果是一个大表，更新所有行对合并时间有很大的影响。在这种情况下，采用渐进合并能有效控制每次合并的时间。

K

可用区/区（**Availability Zone/ Zone**）

Zone 是 Availability Zone 的简称。一个 OceanBase 集群，由若干个可用区（Zone）组成。通常由一个机房内的若干服务器组成一个 Zone。为了数据安全性和高可用性，一般会把数据的多个副本分布在不同的 Zone 上，可以实现单个 Zone 故障不影响数据库服务。

库，数据库**（Database）**

数据库对象，一个数据库对象中可以包含表、视图等其他数据库对象。

快速参数化（Faster Parsing）

OceanBase 数据库特有的针对实参 SQL 快速扣取参数（参数化）的过程。快速参数化结合OceanBase 数据库计划缓存的固有特点，通过增加约束条件等方法，避免了输入 SQL 再次执行时的语义分析过程，加速了计划匹配的效率。

L

连接顺序（**Join Order ）**

执行计划中连接多表时的执行顺序。

轮转合并

为了减少合并对业务的影响，各个 Zone 按照指定的顺序依次合并，正在合并的 Zone 不对外提供服务。

逻辑数据中心**（Logical Data Center（LDC））**

LDC 是对 IDC（Internal Data Center, 互联网数据中心）的一种逻辑划分。OceanBase 数据库在多地多中心部署时，会以 Region 和 Zone 的单位对所有 OBServer 服务器进行划分，此时 OceanBase 数据库的客户端路由和 OceanBase 数据库内部的 RPC 路由被称为 LDC 路由。

M

MVCC（**Multi-Version Concurrency Control**）

多版本并发控制。

慢查询

超过指定时间的 SQL 语句查询。

Multi-Paxos

一种执行多 Paxos 实例的优化协议，OceanBase 数据库使用 Multi-Paxos 协议实现 Commit Log 的多机持久化。

Membership Log

一种特殊的记录一个分区成员组变更记录的 Commit Log。

MySQL 模式（**MySQL Mode**）

MySQL 兼容性模式。为降低 MySQL 数据库迁移 OceanBase 数据库引发的业务系统改造成本，使业务数据库设计人员、开发人员、数据库管理员等可复用积累的技术知识经验，快速上手使用 OceanBase 数据库所做的一种租户类型功能，目前高度兼容 MySQL 语法，常用系统表、函数保持一致。

N

Nop Log

Commit Log 中的一种特定类型的日志，表示空操作。Nop Log 产生于 Multi-Paxos 协议的恢复阶段，如果一条日志没有在多数派副本上持久化成功，在恢复阶段就可能产生一条 Nop Log 作为这条日志的内容。

O

OceanBase（简称 OB）

由蚂蚁集团、阿里巴巴完全自主研发的金融级分布式关系数据库。

OBProxy

OceanBase 数据库高性能反向代理服务器，它接收客户端的应用请求，并转发给 OBServer，然后 OBServer 将数据返回给 OBProxy，OBProxy 将数据转发给应用客户端。具有防连接闪断、屏蔽后端异常（宕机、升级、网络抖动）、MySQL 协议兼容、强校验、支持热升级和多集群等功能。

OBServer

OceanBase 数据库服务器。Server 是运行 OBServer 进程的物理机，一台物理机上可以部署一个或者多个 OBServer。在 OceanBase 数据库内部，Server 由其 IP 地址和服务端口唯一标识。

OceanBase 云平台（**OceanBase Cloud Platform**）

简称 OCP，提供可视化监控、运维、报警等功能。

OLAP（**On-Line Analytical Processing**）

联机分析处理。

OLTP（**On-Line Transaction Processing**）

联机事务处理。

Oracle 模式**（Oracle mode-Oceanbase 2.X）**

Oracle 兼容性模式。为降低 Oracle 数据库迁移 Oceanbase 数据库引发的业务系统改造成本，使业务数据库设计人员、开发人员、数据库管理员等可复用积累的技术知识经验，快速上手使用 OceanBase 数据库所做的一种租户类型功能，逐步兼容 Oracle 语法，常用系统表、函数保持一致。

P

Partition 调度（Partition 负载均衡）

对于每一个租户每个 Zone 中的若干个 UNIT，通过在 UNIT 之间迁移副本，达到每个 UNIT 内资源使用率的均衡。

其中：

• 属于同一个分区表的若干不同分区，会均匀分散在不同的 UNIT 上，使得每个 UNIT 有相同个数的分区

• 属于同一个 Partition Group 的若干分区，会聚集在同一个 UNIT 上

• 在保证上述每组分区个数均衡的基础上，通过交换这组分区内的分区，降低 Server 的磁盘水位线

• 通过迁移非分区表的分区，降低 Server 的磁盘水位线

PX Worker

分布式并行执行下，在每一个机器上参与执行一个分布式并行计划的工作线程。

Q

Query Coordinator（QC）

在分布式并行执行计划中，主控节点上的一个线程，用于调度、协调整体分布式并行执行计划的执行。

迁入

Move in 是用户通过 Schema 变更把一个没有表组（table group）属性的表格设置上表组属性。数据库内会检查被操作表格的分区方式和目标表组的分区方式，只有完全一致的情况，DDL才会成功。

迁出**（Move out）**

迁出是迁入的逆操作，用户通过 Schema 变更把一个表格的表组（table group）属性删除，即把这张表从表组内迁出。用户通过 Schema 变更把一个表格的表组属性从 A 修改为 B，表格会从 A 中迁出，然后迁入 B。

迁移**（Migration ）**

将分区的副本从一个节点迁到另一个节点，先在目标节点上增加一个副本，完成后再将源节点上的副本删除。

全量合并**（Full Compaction）**

进行全量合并时，无论分区的宏块是否修改都重新生成一遍。可以在表粒度指定是否采用全量合并，通常在表模式发生变化（如增加、删除列）或者存储属性发生变更（如修改压缩级别）时，对该表进行全量合并。在需要对表进行全量合并时，通常采用渐进合并的方式来控制单次合并的时间。

全局索引**（Global Index）**

OceanBase 数据库中跨分区的数据索引。全局索引通过全局化的存储数据键值与主键信息，可以快速定位到数据所在的分区。

全局一致性快照**（Global Consistent Snapshot-Oceanbase 2.X）**

在没有实现全局一致性快照前，分布式数据库无法实现跨节点的一致性读和保证因果序。OceanBase 数据库 V1.4.x 版本中，应用系统设计和开发人员需要保证一条 SQL 语句中访问的多个表、多个分区都在同一个 OceanBase 数据库节点上，同时对于依赖操作顺序的业务系统，无法保证两个前后事务分别修改两个节点上两张表的数据反映顺序。OceanBase 数据库 V2.0 版本实现的全局一致性快照功能，从根本上解决了这些问题。相对于 Google Truetime 基于原子钟的硬件实现，OceanBase 数据库的全局时间戳（GTS）服务是纯软件实现的，不依赖特定的硬件设备，也不对客户方的部署环境提额外的要求，使得 OceanBase 数据库能够服务更广泛的专有云客户。OceanBase 数据库 V2.x 版本的全局时间戳打开后，跨节点读写、因果序的行为和单机数据库完全一致。

强一致性读/弱一致性读（**Strong Read Consistentcy/ Weak Read Consistentcy**）

强一致性读是默认的一种 OceanBase 数据库的 SQL 执行方式，即 SQL 必须转发到涉及 Partition 的 Leader 所在的 OBServer 服务器上才能执行，用以保证获取到实时最新数据。弱一致性读是相对于强一致性读来说的。即 SQL 只需在涉及 Partition 的 OBServer 服务器上执行即可，不强制是 Leader。如需使用弱一致性 SELECT，主要通过两种方式。一种是带 read_consistency(weak) Hint 的 SELECT语句，另一种是在当前 Session 中修改ob_read_consistency 的系统变量取值为 weak。

R

Red**o 日**志索引

Ilog 操作日志（Commit Log）在文件中不是根据日志 ID 有序存放的，为顺序读取操作日志，在ilog 中存放了每条操作日志在日志文件中的位置，ilog 中的记录是按照日志 ID 有序的。

Rowid

分区局部索引的基线数据行中保存的主表行数据的位置信息，用于快速定位相应的主表行。

Row Merge

将基线行数据和增量行数据进行融合形成新版本行的过程。

Row Purge/Range Purge

标识一些行被删除了。

RPC（**Remote Process Call**）

远程方法调用。

RS**（RootServer）**

主控服务器。主要进行集群管理、数据分布和副本管理。

Reconfirm

Reconfirm 即再次确认，Multi-Paxos 协议中 Leader 上任需要执行的一个流程。分区 Leader 上任之后，要把之前这个分区多数派上持久化成功的日志再次确认一遍，并把这些确认过的日志同步到所有正常工作的副本，确认多数派都持久化成功所有日志后 Reconfirm 才算成功。

S

Schema

通常来说，指的是数据库对象（如表、视图、索引等）的模式；在 OceanBase 数据库服务端，也指所有数据库对象模式的集合。

Schema Version

在 OceanBase 数据库服务端，维护了一个全局的 Schema 版本号，数据库对象的每次变化都会引起全局 Schema 版本的升高。每一个数据库对象也有一个自己的版本号，该版本号是该对象最近一次修改（创建、变更等）对应的全局 Schema 版本号。

Slog/SSTable Log

节点为了维护本机基线数据一致性而使用的日志。

Sub Query Coordinator（SQC）

分布式并行执行计划中，每一台参与执行的服务器上会有一个本地的协调者，用于接收从 QC 发送来的调度指令，获取本地执行工作线程，生成本地执行任务的 granule，协调本地执行。

SSTable

用于存储基线数据或转储数据，行数据有序存储。

Start Working Log

分区 Leader 上任成功，处理新事务之前写的第一条特殊日志，这条日志包含新 Leader 的上任时间。

数据库**（Database）**

数据库是按数据结构来组织、存储和管理数据的仓库。数据库下包括若干表、索引，以及数据库对象的元数据信息。

数据倾斜**（Data Skew）**

数据中对于某一个或某几个值出现的次数特别多，占据了对应数据较大的比例，在分布式执行过程中，数据倾斜会引起执行的长尾，导致被分配处理这些值的执行线程会用更多的时间完成执行。

刷新 Schema**（Schema Refresh）**

OceanBase 数据库的 DDL 操作对系统对象的变更都发生在 Root Server 上，为使得集群中的每一个节点都能获取到最新的 Schema 信息，Root Server 定期将最新的 schema version 广播给集群中每一个节点。节点在收到 schema version 后，和本地缓存的 schema version 比对，如果本地落后于全局版本，则从系统表中获取变更来更新本地缓存的系统对象信息，这个过程叫刷新 Schema。

算子**（Operator）**

组成执行计划的基本单元。一般通过多个算子构成一棵执行树完成用户 SQL 请求。

T

统计信息**（Statistics）**

一个描述数据库中表和列信息的数据集合。在 OceanBase 数据库中，统计信息有表统计信息（table level statistics）和列统计信息（column level statistics）两种。

U

UNIT调度（Unit负载均衡）

对于每个 Zone，根据 UNIT 的动态调度，达到均衡的策略:

• 属于同一个租户的若干个 UNIT，会均匀分散在不同的 Server 上

• 属于同一个租户组的若干个 UNIT，会尽量均匀分散在不同的 Server 上

• 当一个 Zone 内机器整体磁盘使用率超过一定阈值时，通过交换或迁移 UNIT 降低磁盘水位线

• 否则，根据 UNIT 的 CPU 和内存规格，通过交换或迁移 UNIT 降低 CPU 和内存的平均水位线

Universe

表示跨地域部署的所有 OceanBase 数据库。

V

VIP（**Virtual IP**）

虚拟 IP 地址。RootServer 主机由 VIP 决定。

W

微块**（Micro Block）**

宏块内部的管理单位，数据读的最小单位。

微块缓存**（Block Cache）**

微块在内存中的缓存，用于减少微块被频繁访问的 IO，提升查询性能。

微块索引缓存**（Block Index Cache）**

微块索引在内存中的缓存，用于提升频繁访问的查询性能。

位置**（Locality）**

用来描述一个表的副本类型以及分布位置的方式。基本语法结构型为 replicas@location，由如下一些元素组成：

• 副本类型（replicas）：例如， F 表示全功能副本；L 表示日志型副本。

• 位置（location）：位置是系统已知的一组枚举值。位置是zone的名称，如hz1, bj2等。

• 量词：不指定量词时，表示一个副本；用 {n} 表示 n 个副本。有一种特殊的量词 {all_server} 表示副本数和可用的 Server 数相同。目前，由于一些实现上的考虑，一个分区在一个 Zone 中最多有一个全功能或日志型副本（这些类型的副本是 Paxos 复制组的成员），只读型副本在同一个 Zone 可以有多个。

位置信息缓存**（Location Cache）**

分区位置信息缓存。每个节点维护分区位置信息，在执行计划生成阶段，根据位置信息生成不同类型的执行计划；在执行阶段，根据位置信息将计划发送到相应的节点执行。位置信息缓存的更新是按需的，如果在语句执行过程中发生由于位置失效产生的错误，则刷新相应分区的位置信息。

无主选举

分区没有 Leader 的情况下，这个分区的多副本进行的选主流程。无主选举的两个触发场景是集群重启分区第一次选举和分区原 Leader 故障，无主选举需要等原 Leader 的 Lease 过期后才能开始。

X

小版本冻结（**Minor Freeze**）

分区在内存中的增量数据超过阈值时，冻结该分区当前活跃 Memtable，不再接受新开启事务的写操作，新事务的写操作在该分区新的活跃 Memtable 中进行。

Y

远程执行**（Remote execution）**

接收用户请求和生成执行计划的数据库服务器和计划执行的数据库服务器不是同一个，并且只有一台数据库服务器执行该计划。

优化器**（Optimizer）**

优化器是决定用户查询执行计划的核心模块。通过访问相关数据的统计信息，结合 OceanBase 数据库内置的规则与代价模型，优化器为用户查询生成最佳的执行计划。

有主改选

分区有 Leader 的情况下，把分区 Leader 切换到指定 OBServer 的流程。有主改选不需要等原有 Leader Lease 过期。

Z

Zone

是 Availability Zone 的缩写。

一个 OceanBase 集群由若干个 Zone 组成。Zone 的含义是可用性区，通常指一个机房（数据中心或 IDC）。为了数据的安全和高可用性，一般会把数据的多个副本分布在多个 Zone 上。这样，对于 OceanBase 数据库来说，可以实现单个 Zone 的故障不影响数据库服务。一个 Zone 包括若干物理服务器。

增量合并（**Incremental Compaction**）

进行增量合并时，只重新生成所包含的行发生修改的宏块。

增量数据（**Incremental Data**）

执行增、删、改（insert、update、delete）等操作产生的修改数据，该部分数据尚未与基线数据合并，包括 Memtable 数据和转储数据。

增量数据表（**Memtable**）

内存中增量修改记录的集合。

租户（**Tenant**）

OceanBase 数据库通过租户实现资源隔离，采用单集群多租户的管理模式。OceanBase 集群的一个租户相当于一个 MySQL 或者 Oracle 的实例。OceanBase 数据库的租户之间的资源和数据都是隔离的。租户拥有一组计算和存储资源，提供一套完整独立的数据库服务。

OceanBase 数据库上有系统租户和普通租户。系统租户下存放 OceanBase 数据库管理的各种内部元数据信息；普通租户下存放用户的各种数据和数据库元信息。

只读Zone/读库（**Readonly Zone**）

只读 Zone 是一种特殊的 Zone，在这个 Zone 里，只部署只读副本。通常当多数派副本故障的时候，OceanBase 数据库会停止服务，但在这种情况下，只读 Zone 能继续能够提供弱一致性读。这也是 OceanBase 集群内提供读写分离的一种方案。

执行计划/计划（**Execution Plan/Plan**）

数据库中用以执行用户 SQL 请求的物理代码的集合，通常是一棵由算子构成的执行树。

执行计划缓存/计划缓存（**Plan Cache**）

执行计划在每台 Server 上的缓存。SQL 语句的优化是一个比较耗时的过程，为了避免反复执行优化过程，生成的执行计划会加入到执行计划缓存中，以便再次执行该 SQL 时使用。每一个租户在每一台 Server 上都有一个独立的执行计划缓存，用以缓存在此 Server 上处理过的执行计划。

执行计划绑定**（Execution Plan Binding）**

用户通过 outline 绕过优化器而直接指定 SQL 的执行计划的过程，通常用于优化器生成的执行计划错误或者不够高效的场景。

执行计划匹配**（**Execution plan matching）

数据库为用户 SQL 选择在执行计划缓存中合适的执行计划的过程。

主键**（Rowkey）**

与传统关系数据库的主键（primary key）相同，表中每一行数据的标识符，用于唯一标识表中的行，表中的数据按照 RowKey 排序。

主可用区（**Primary Zone**）

Primary Zone 指的是分区的主副本所在的 Zone，可以为分区指定一个 Zone 的列表，当分区需要切主的时候，容灾策略会按照这个列表的顺序决定新主的偏好位置。

如果不设定 Primary Zone，系统会根据负载均衡的策略，在多个全功能副本里自动选择一个作为 Leader。

只读可用区（**Read Zone**）

只读 Zone 是一种特殊的 Zone，在这个 Zone 里，只部署只读副本。通常当多数派副本故障的时候，OceanBase 数据库会停止服务，但在这种情况下，只读 Zone 能继续提供弱一致性读，即读 Zone、读库。这也是 OceanBase 数据库提供读写分离的一种方案。

转储（**Dump）**

将小版本冻结的 Frozen Memtable 中的增量数据与前一个版本转储数据（如果存在）合并后持久化存储到磁盘的过程称为转储。在合并过程中，转储数据也参与和基线数据的合并，形成新的基线数据。

转储数据版本号（**Minor Freeze Version**）

转储数据的版本号。

子计划（**Sub Plan**）

在分布式并行执行场景下，和 DFO 意思相同。

资源池（**Resource Pool**）

一个租户拥有若干个资源池，这些资源池的集合描述了这个租户所能使用的所有资源。一个资源池由具有相同资源规格（Unit Config）的若干个 UNIT（资源单元）组成。一个资源池只能属于一个租户。每个 UNIT 描述了位于一个 Server 上的一组计算和存储资源，可以视为一个轻量级虚拟机，包括若干 CPU 资源、内存资源和磁盘资源等。

一个租户在同一个 Server 上最多有一个 UNIT。实际上，从概念上讲，副本是存储在 UNIT 之中，UNIT 是副本的容器。

组提交（**Group Commit**）

组提交是为了优化写日志时的刷磁盘问题，将多个事务的日志聚在一起用一次 IO 完成持久化。