OB-初窥

https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V3.1.2/what-is-oceanbase

概述

OceanBase 数据库是分布式关系数据库软件，具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性。

支持混合负载的能力，可以同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用。

兼容性

• 支持 MySQL 5.6 版本全部语法
• 支持绝大多数的 Oracle 语法和几乎全量的过程性语言功能

业务连续性

高可用

数据以多副本的方式分布在集群的各个节点上

• RPO = 0（Recovery Point Objective，零数据丢失）
• RTO < 30秒（Recovery Time Objective，故障恢复时间小于 30 秒）

可扩展

支持在线扩缩容

概念

地域（Region）

Region 指一个地域或者城市（例如杭州、上海、深圳等），一个 Region 包含一个或者多个 Zone

可用区/区（Zone）

Zone 是 Availability Zone 的简称。一个 OceanBase 集群，由若干个可用区（Zone）组成。通常由一个机房内的若干服务器组成一个 Zone。

OBServer

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

资源池（Resource Pool）

一个资源池由具有相同资源规格（Unit Config）的若干个 UNIT（资源单元）组成。一个资源池只能属于一个租户。每个 UNIT 描述了位于一个 Server 上的一组计算和存储资源，包括CPU 资源，内存资源，磁盘资源等。

OBProxy

OceanBase 数据库代理 ODP（OceanBase Database Proxy，又称 OBProxy）是 OceanBase 专用的代理服务器，OceanBase 用户的数据会以多副本的形式存放在各个 OBServer 上，ODP 则负责接收用户发过来的 SQL 请求，转发用户 SQL 请求到最佳目标 OBServer 上，并将执行结果返回给客户。

RS（RootServer）

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

Multi-Paxos

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

ODC

OceanBase 开发者中心（OceanBase Developer Center，ODC）是为 OceanBase 数据库量身打造的企业级数据库开发平台。ODC 支持连接 OceanBase 中 MySQL 和 Oracle 模式下的数据库，同时为数据库开发者提供了数据库日常开发操作、WebSQL、SQL 诊断、会话管理和数据导入导出等功能。

OCP

OceanBase 云平台（OceanBase Cloud Platform，OCP）伴随 OceanBase 数据库而生，是一款以 OceanBase 为核心的企业级数据库管理平台。不仅提供对 OceanBase 集群和租户等组件的全生命周期管理服务，同时也对 OceanBase 相关的资源（主机、网络和软件包等）提供管理服务，让您能够更加高效地管理 OceanBase 集群，降低企业的 IT 运维成本。

OMS

OceanBase 迁移服务（OceanBase Migration Service，OMS）是 OceanBase 提供的一种支持同构或异构 RDBMS 与 OceanBase 之间进行数据交互的服务，它提供了数据的在线迁移和实时增量同步的数据复制能力。

系统架构

OceanBase 数据库采用 Shared-Nothing 架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎，运行在普通 PC 服务器组成的集群之上，具备可扩展、高可用、高性能、低成本、云原生等核心特性。

架构图

集群架构

一个 Region 可以包含一个或者多个 Zone，Zone 是一个逻辑的概念，它包含了 1 台或者多台运行了 OBServer 进程的服务器（以下简称 OBServer）。每一个 Zone 上包含一个完整的数据副本，由于 OceanBase 数据库的数据副本是以分区为单位的，所以同一个分区的数据会分布在多个 Zone 上。每个分区的主副本所在服务器被称为 Leader，所在的 Zone 被称为 Primary Zone。如果不设定 Primary Zone，系统会根据负载均衡的策略，在多个全功能副本里自动选择一个作为 Leader。

每个 Zone 会提供两种服务：总控服务（RootService）和分区服务（PartitionService）。其中每个 Zone 上都会存在一个总控服务，运行在某一个 OBServer 上，整个集群中只存在一个主总控服务，其他的总控服务作为主总控服务的备用服务运行。总控服务负责整个集群的资源调度、资源分配、数据分布信息管理以及 Schema 管理等功能。 其中：

• 资源调度主要包含了向集群中添加、删除 OBServer，在 OBServer 中创建资源规格、Tenant 等供用户使用的资源；
• 资源均衡主要是指各种资源（例如：Unit）在各个 Zone 或者 OBServer 之间的迁移。
• 数据分布管理是指总控服务会决定数据分布的位置信息，例如：某一个分区的数据分布到哪些 OBServer 上。
• Schema 管理是指总控服务会负责调度和管理各种 DDL 语句。

分区服务用于负责每个 OBServer 上各个分区的管理和操作功能的模块，这个模块与事务引擎、存储引擎存在很多调用关系。

OceanBase 数据库基于 Paxos 的分布式选举算法来实现系统的高可用，最小的粒度可以做到分区级别。集群中数据的一个分区（或者称为副本）会被保存到所有的 Zone 上，整个系统中该副本的多个分区之间通过 Paxos 协议进行日志同步。每个分区和它的副本构成一个独立的 Paxos 复制组，其中一个分区为主分区（Leader），其它分区为备分区（Follower）。所有针对这个副本的写请求，都会自动路由到对应的主分区上进行。主分区可以分布在不同的 OBServer 上，这样对于不同副本的写操作也会分布到不同的数据节点上，从而实现数据多点写入，提高系统性能。

存储引擎

OceanBase 数据库的存储引擎采用了基于 LSM-Tree 的架构，把基线数据和增量数据分别保存在磁盘（SSTable）和内存（MemTable）中，具备读写分离的特点。对数据的修改都是增量数据，只写内存。所以 DML 是完全的内存操作，性能非常高。读的时候，数据可能会在内存里有更新过的版本，在持久化存储里有基线版本，需要把两个版本进行合并，获得一个最新版本。

如上图所示，在内存中针对不同的数据访问行为，OceanBase 数据库设计了多种缓存结构。除了常见的数据块缓存之外，也会对行进行缓存，行缓存会极大加速对单行的查询性能。为了避免对不存在行的空查，OceanBase 数据库对行缓存构建了布隆过滤器，并对布隆过滤器进行缓存。OLTP 业务大部分操作为小查询，通过小查询优化，OceanBase 数据库避免了传统数据库解析整个数据块的开销，达到了接近内存数据库的性能。当内存的增量数据达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘。同时每天晚上的空闲时刻，系统也会启动每日合并。另外，由于基线是只读数据，而且内部采用连续存储的方式，OceanBase 数据库可以根据不同特点的数据采用不同的压缩算法，既能做到高压缩比，又不影响查询性能，大大降低了成本。

SQL 引擎

OceanBase 数据库的 SQL 引擎是整个数据库的数据计算中枢，和传统数据库类似，整个引擎分为解析器、优化器、执行器三部分。当 SQL 引擎接受到了 SQL 请求后，经过语法解析、语义分析、查询重写、查询优化等一系列过程后，再由执行器来负责执行。所不同的是，在分布式数据库里，查询优化器会依据数据的分布信息生成分布式的执行计划。如果查询涉及的数据在多台服务器，需要走分布式计划，这是分布式数据库 SQL 引擎的一个重要特点，也是十分考验查询优化器能力的场景。OceanBase 数据库查询优化器做了很多优化，诸如算子下推、智能连接、分区裁剪等。如果 SQL 语句涉及的数据量很大，OceanBase 数据库的查询执行引擎也做了并行处理、任务拆分、动态分区、流水调度、任务裁剪、子任务结果合并、并发限制等优化技术。

下图描述了一条 SQL 语句的执行过程，并列出了 SQL 引擎中各个模块之间的关系。

• Parser（词法/语法解析模块）

  Parser 是整个 SQL 执行引擎的词法或语法解析器，在收到用户发送的 SQL 请求串后，Parser 会将字符串分成一个个的单词，并根据预先设定好的语法规则解析整个请求，将 SQL 请求字符串转换成带有语法结构信息的内存数据结构，称为语法树（Syntax Tree）。

  为了加速 SQL 请求的处理速度，OceanBase 数据库对 SQL 请求采用了特有的快速参数化，以加速查找执行计划的速度。

• Resolver（语义解析模块）

  当生成语法树之后，Resolver 会进一步将该语法树转换为带有数据库语义信息的内部数据结构。在这一过程中，Resolver 将根据数据库元信息将 SQL 请求中的 token 翻译成对应的对象（例如库、表、列、索引等），生成语句树。

• Transfomer（逻辑改写模块）

  在查询优化中，经常利用等价改写的方式，将用户 SQL 转换为与之等价的另一条 SQL，以便于优化器生成最佳的执行计划，这一过程称为查询改写。Transformer 在 Resolver 之后，分析用户 SQL 的语义，并根据内部的规则或代价模型，将用户 SQL改写为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化。Transformer 的工作方式是在原 Statement Tree 上做等价变换，变换的结果仍然是一棵语句树。

• Optimizer（优化器）

  优化器是整个 SQL 优化的核心，其作用是为 SQL 请求生成最佳的执行计划。在优化过程中，优化器需要综合考虑 SQL 请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、联接顺序选择、联接算法选择、分布式计划生成等多个核心问题，最终选择一个对应该 SQL 的最佳执行计划。SQL 的执行计划是一棵由多个操作符构成的执行树。

• Code Generator（代码生成器）

  优化器负责生成最佳的执行计划，但其输出的结果并不能立即执行，还需要通过代码生成器将其转换为可执行的代码，这个过程由 Code Generator 负责。

• Executor（执行器）

  当 SQL 的执行计划生成后，Executor 会启动该 SQL 的执行过程。对于不同类型的执行计划，Executor 的逻辑有很大的不同：对于本地执行计划，Executor 会简单的从执行计划的顶端的算子开始调用，由算子自身的逻辑完成整个执行的过程，并返回执行结果；对于远程或分布式计划，Executor 需要根据预选的划分，将执行树分成多个可以调度的线程，并通过 RPC 将其发送给相关的节点执行。

• Plan Cache（执行计划缓存模块）

  执行计划的生成是一个比较复杂的过程，耗时比较长，尤其是在 OLTP 场景中，这个耗时往往不可忽略。为了加速 SQL 请求的处理过程，SQL 执行引擎会将该 SQL 第一次生成的执行计划缓存在内存中，后续的执行可以反复执行这个计划，避免了重复查询优化的过程。

功能特性

分布式事务

严格支持事务的 ACID 属性，OB通过 Paxos 协议将事务日志复制到多个数据副本来保证事务的可用性和持久性。

高可用

• 提供基于日志复制技术的主备库特性，支持switchover和failover切换角色

• 提供基于数据块拷贝和事务日志拷贝的物理备份恢复特性

HTAP能力

混合事务和分析处理（Hybrid Transaction and Analytical Process，HTAP）

OB使用同一套计算引擎同时支持混合负载的能力。

多租户

OB通过租户实现资源隔离，支持公有云，私有云和混合云环境部署。

安全性

• 支持权限与角色体系
• 支持SSL
• 数据透明加密
• 审计
• Label Security
• IP 白名单

产品体系

OceanBase 产品体系中包含五款产品，即 OceanBase 数据库、OceanBase 云平台、OceanBase 开发者中心、OceanBase 迁移服务和 OceanBase 管理员工具，分别提供数据库、运维管理、数据库开发、数据库迁移等服务