OceanBase官方文档阅读笔记（一）

什么是OceanBase?

OceanBase
数据库是阿里巴巴和蚂蚁集团不基于任何开源产品，完全自研的原生分布式关系数据库软件，在普通硬件上实现金融级高可用，首创“三地五中心”城市级故障自动无损容灾新标准，具备卓越的水平扩展能力，全球首家通过
TPC-C 标准测试的分布式数据库，单集群规模超过 1500 节点。 产品具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性，
承担支付宝 100% 核心链路，在国内几十家银行、保险公司等金融客户的核心系统中稳定运行。

• TTPC（transaction processing performance council）被称为事务处理性能委员会，负责定义诸如 TPC-C、TPC-H&TPC-R 和 TPC-W 基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC- C主要针对在线事务处理，模拟了以下五种食事物
• 在普通硬件上实现金融级高可用。
• 云原生特性在我看来非常有用，可进行容器化部署，便于运维。

产品优势

业务连续性

高可用

OceanBase
数据库的每个节点都可以作为全功能节点，将数据以多副本的方式分布在集群的各个节点，可以轻松实现多库多活，少数派节点出现故障对业务无感知。OceanBase
数据库的多副本技术能够满足从节点、机架、机房到城市级别的高可用、容灾要求，克服传统数据库的主备模式在主节点出现异常时 RPO>0
的问题。确保客户的业务系统能够稳定、安全运行。

OceanBase 数据库支撑了支付宝 100% 的核心链路，并且在多家商业银行的核心业务中稳定运行，久经考验。

可扩展

传统数据库受限于单机的处理能力极限，高昂的扩展成本，使得很多系统在面临高并发，或者数据量达到一定程度后显得力不从心。OceanBase
数据库独创的总控服务和分区级负载均衡能力使系统具有极强的可扩展性，可以在线进行平滑扩容或缩容，并且在扩容后自动实现系统负载均衡，对应用透明，完成对海量数据的处理。对于银行、保险、运营商等行业的高并发场景，OceanBase
数据库能够提供高性能、低成本、高弹性的数据库服务，并且能够充分利用客户的 IT 资源。此外，OceanBase
数据库还经历过多次双十一的流量洪峰考验。

从这里可以看出oceanbase的稳定性，一般数据库优先维持强一致性，通过集群部署的方式达到高可用，希望在后续的文档中能看出其高可用的独特具体实现形式。
平滑扩缩容兼具的kubernetes的一些特性，估计是使用到了其上文提到的总控服务。分区级负载均衡这个概念在eureka和nacos等注册发现中心中都有所提及。若是没有将数据库作为单独集群部署出来，会对其扩缩容能力和负载均衡能力影响有多大呢。
应用易用性

HTAP

OceanBase 数据库独创的分布式计算引擎，能够让系统中多个计算节点同时运行 OLTP 类型的应用和复杂的 OLAP
类型的应用，真正实现了用一套计算引擎同时支持混合负载的能力，让用户通过一套系统解决 80%
的问题，充分利用客户的计算资源，节省客户因购买额外硬件资源或软件授权所带来的成本。

兼容性

OceanBase 数据库针对 MySQL 和 Oracle 数据库生态都给予了很好的支持。对于 MySQL，OceanBase 数据库支持
MySQL 5.6 版本全部语法，可以做到 MySQL 业务无缝切换。 对于 Oracle，OceanBase 数据库能够支持绝大多数的
Oracle 语法和几乎全量的过程性语言功能，可以做到大部分的 Oracle 业务进行少量修改后自动迁移。帮助客户降低系统的开发、迁移成本。

低成本

OceanBase 数据库可以在通用服务器上运行，不依赖于特定的高端硬件，能够有效降低用户的硬件成本。

OceanBase 数据库使用的基于 LSM-Tree 的存储引擎，能够有效地对数据进行压缩，并且不影响性能，可以降低用户的存储成本。

低风险

OceanBase
数据库不基于任何开源数据库技术，完全自主研发，对于产品有完全的掌控力，能够避免客户使用开源技术所带来的潜在合规、知识产权、SLA 等风险。

OceanBase 数据库目前完成了与国产硬件平台、操作系统的适配，降低客户对国外硬件、操作系统的依赖。
为什么是 HTAP？
在互联网浪潮出现之前，企业的数据量普遍不大，特别是核心的业务数据，通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构，所有的线上请求 (OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。

随着互联网的发展，企业的业务数据量不断增多，单机数据库的容量限制制约了其在海量数据场景下的使用。因此在实际应用中，为了面对各种需求，OLTP、OLAP 在技术上分道扬镳，在很多企业架构中，这两类任务处理由不同团队完成。当物联网大数据应用不断深入，具有海量的传感器数据要求实时更新和查询，对数据库的性能要求也越来越高，此时，新的问题随之出现：

OLAP 和 OLTP 系统间通常会有几分钟甚至几小时的时延，OLAP 数据库和 OLTP 数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。
企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。
因此，能够统一支持事务处理和工作负载分析的数据库成为众多企业的需求。在此背景下，由 Gartner 提出的 HTAP（混合事务 / 分析处理，Hybrid Transactional/Analytical Processing）成为希望。基于创新的计算存储框架，HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外，HTAP 基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

目前，实现 HTAP 的数据库不多，主要有 PingCAP 的 TiDB、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是国内首家开源的 HTAP 分布式数据库，接下来，本文将以此例进行深入分析。

集群架构

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

OceanBase 数据库的整体架构如下图所示。

　总的来说，shared nothing降低了竞争资源的等待时间，从而提高了性能。反过来，如果一个数据库应用系统要获得良好的可扩展的性能，它从设计和优化上就要考虑 shared nothing体系结构。Share nothing means few contention.它在oracle数据库设计和优化上有很多相同之处。

OceanBase 数据库支持数据跨地域（Region）部署，每个地域可能位于不同的城市，距离通常比较远，所以 OceanBase
数据库可以支持多城市部署，也支持多城市级别的容灾。一个 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 语句。

有k8s那味了，说明OB集群得单独部署，方便让OB更大限度的控制服务器，进行资源调度。

OceanBase 数据库支持数据跨地域（Region）部署，每个地域可能位于不同的城市，距离通常比较远，所以 OceanBase
数据库可以支持多城市部署，也支持多城市级别的容灾。一个 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
数据库可以根据不同特点的数据采用不同的压缩算法，既能做到高压缩比，又不影响查询性能，大大降低了成本。

有eureka的感觉，在第一次下载注册表的时候全量下载，其次增量下载，保证迭代稳定性，和docker的overlay存储技术很相似，底层镜像相同，修改时修改上层，最后合并成修改后，节省了一定的空间。

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 第一次生成的执行计划缓存在内存中，后续的执行可以反复执行这个计划，避免了重复查询优化的过程。