摘要：OceanBase OBCA认证学习笔记大全

OceanBase数据库是由蚂蚁集团完全自主研发的企业级分布式关系数据库，始创于 2010 年。具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。至今已成功应用于支付宝及阿里巴巴全部核心业务。并从 2017 年开始服务于广泛行业客户，包括南京银行、西安银行、天津银行、苏州银行、东莞银行、常熟农商行、广东农信、中国人保等近四十家银行、保险和证券机构，以及印度最大支付公司Paytm。
OBCA （OceanBase 数据库认证专员）认证主要讲解 OceanBase 的发展历程、应用案例、产品架构、核心功能、部署安装等知识。
以下内容是对OBCA在线课程内容进行的整理，与课程大纲一致共分为6个章节。

• 分布式数据库与集中式数据库的差异
• OceanBase数据库产品简介
• OceanBase产品家族及基础概念
• OceanBase集群技术架构
• OB Server的SQL引擎和存储引擎
• OCP及ODC工具介绍

1 分布式数据库与集中式数据库的差异

1.1 传统集中式数据库特点

优点：成熟稳定、行业适配性强、生态完善
劣势：成本高、无法横向扩展

1.2 中间件分库分表特点

优点：水平扩展、技术成本低
劣势：侵入应用、跨库分布式事务、全局一致性、负载均衡、跨库复杂SQL

1.3 OceanBase分布式原生数据库特点

数据高可靠+服务高可用，RPO=0、RTO<30s
线性扩容
低成本
全局一致性
灵活的部署
对业务透明

图1 OB与传统数据库的对比

2 OceanBase数据库产品简介

OceanBase完全自主研发，拥有100%的知识产权，由蚂蚁集团控股独立运作。

2.1 发展历程及产品简介

发展历程
2010年，产品第一个项目是淘宝收藏夹，主要提供分布式存储功能；
2013年，产品开源，开始支持SQL；
2014年，正式进入蚂蚁金服，支撑金融业务，网商银行；
2016年，发布1.0版本，增强分布式事务能力，支付宝核心模块迁移到OB；
2017年，正式应用到外部客户，南京银行等金融机构；
2019年，发布2.0版本，在兼容MySQL基础上添加了对Oracle的兼容，支持HTAP，TPC-C登顶6088万；
2020年，成立独立独立公司，TPC-C取得新记录7.07亿。

OceanBase核心特性

• 高扩展，支持在线扩容、缩容，单集群突破100台服务器
• 高可用，基于Paxos协议，强一致性，RPO=0，RTO<30s
• 多租户，DBaaS架构，资源隔离，自动负载均衡
• 高性能，峰值6100万次/秒，单表最大3200亿行
• 高兼容，Oracle/MySQL两种兼容模式
• 高透明，全局一致性快照，自动事务两阶段提交，全局索引

资质

• 信创评估完成
• 等保三级
• CNAS（ISO 9001、ISO 27001）

2.2 TPC-C认证成果

OceanBase是第一个通过认证的国产数据库，同时也是全球第一个通过认证的分布式数据库。
OB集群规模1557节点，客户端规模400节点，性能为70735万tpmC，持续负载运行8小时，性能抖动不超过0.5%，性价比3.98￥/tmpC。

图2 对TPC-C的误解

2.3 内外部应用案例

OB关系型数据库的定位，可广泛应用于各个行业，如金融交易、电信计费、保险及初创互联网企业。目前蚂蚁集团关键核心系统均运行在OB上。

内部应用

• 支付宝：承载2019年双11峰值6100万次/秒的数据库访问（TPS+QPS）
• 淘宝：月活8亿用户，日活最多达3亿，收藏夹数据读取量达100万次/秒，其中最大表包存数千亿条记录；
• 网商银行：承载网上银行全部交易，三地五中心（杭州、上海、深圳）架构确保数据安全；
• 国际业务：Paytm（印度）主站核心数据库，世界三大电子支付商OB占第二。

金融场景

OB于2017年开始拓展外部业务，在金融场景积累了众多客户。

图3 OB的金融客户

3 OceanBase产品家族及基础概念

3.1 产品家族及安装部署

OB数据库内核是最核心的部分，关于Paxos等内容在后两章介绍。※

• OCP是图形化管理平台，面向运维人员。※
• ODC是图形化开发平台，面向开发人员。
• OMS，数据库迁移平台，初级课程不涉及。
• ODP，数据中间件，初级课程不涉及。
  

图4 OB产品家族

部署方式

部署方式支持云（公有、专有）部署和独立部署，为保证性能，建议使用独立部署的方式。
试用版可通过2C8G的服务器安装学习。
生产环境建议使用3台以上32C/128G/1.2T及以上的设备进行部署，为保证性能需要使用SSD及万兆网。

拥抱国产生态

• CPU
• 海光（Hygon 7185）
• 海思（鲲鹏920）
• 飞腾（FT1500a、FT2000）

操作系统

• AliOS
• 中标麒麟NeoKylin V7u5
• 银河麒麟Kylin 4.0.2

OB部署流程

图5 OB部署流程

客户端工具

客户端工具上支持黑屏（命令行）和白屏工具（图形化），OceanBase客户端可同时兼容两种实例，因此推荐使用。同时也可根据需求使用图形化工具OCP和ODC。

图6 客户端工具

3.2 基础概念

首先需要理解OceanBase集群、Zone、OB Server、资源池、租户、分区等概念。

管理员角度

数据库集群会有多个Zone，每个Zone的服务器数量一般是一致的，比如Zone1、Zone2、Zone3分别都对应2台服务器，将所有Zone的资源整合。
管理员将资源池划分成多个小资源池、或可理解为虚机，再按需分配给租户使用。

开发者角度

根据业务规划，向管理员申请指定配置资源，后续也可进行升级配置。

图7 基本概念

集群、Zone、和OB Server的关系

一个集群由多个Zone组成，给集群内的一批服务器打上同一个tag，则属于同一个Zone；
不同的Zone可以对应不同的城市、一个城市的不同机房、或者一个机房的不同机架；
Zone个数>=3，建议是奇数；
每个Zone均有且只有一份完整的副本；单Zone的故障不影响业务；
每台OB Server相对独立，有独立计算和存储引擎。

RootService总控服务（RS）

RS相当于集群的大脑，负责集群资源的分配、调度等。RS无需单独部署，一般建议在Zone中与OB Server合用、每个Zone都部署RS服务。

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

多租户机制

在上面“基础介绍”的内容中我们了解可以根据业务的需求创建不同的租户，租户和传统数据库实例的概念类似，我们可以在租户上创建指定的用户、表等。
租户的CPU和内存是强制的隔离。

图8 多租户机制

租户拥有若干资源池

OB可以为不同类型的应用分配不同类型和不同数量的Unit来满足不同的需求。
资源并不是静态的，后续可根据业务的发展不断调整（升配或者降配）。

Unit

每个Unit描述了位于一个Server上的一组计算机和存储资源，每个Unit只能属于一个租户；
每个Unit可以理解为一个轻量级虚拟机，包括若干CPU资源、内存资源及磁盘资源等。

租户资源池

一个租户拥有若干个资源池。这些资源池的集合描述了这个租户所能使用的所有资源。
一个租户在同一个Server上最多有一个Unit。实际从概念上讲，副本是存储在Unit中，Unit是副本的容器。

3.3 实验

实验1：部署OceanBase集群
实验2：创建租户
实验3：检查集群状态
实验4：系统“参数”和“变量”
实验5：创建用户及管理用户权限
实验6：查看系统日志

4 OceanBase集群技术架构

4.1 Paxos 协议与负载均衡

在学习Paxos协议前，先理解数据分区与分区副本的概念。

图9 数据分区与分区副本

多副本一致性协议

以分区为单位组建Paxos协议组：每个分区都有多副本（Replica），自动建立Paxos组，在分级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便；
自动选举主副本：OB自动生成多副本，多副本自动选举主副本，主副本提供服务（下图中黄色副本接受业务请求，蓝色副本用于备份）。

图10 多副本示例

自动负载均衡与智能路由

自动负载均衡：各个服务器中，使得各个服务器都能承载业务流量。（应用1、2、3读请求分布路由到不同的OB Server）；
每台OB Server互相独立：每台OB Server均可以独立执行SQL，如果应用需要访问的数据不在同服务器上，OB Server自动将请求路由至数据所在的服务器，对业务完全透明（应用2->P6->P7/P8）。

多副本同步Redo Log确保数据持久化

图11 多副本同步

OB Proxy为应用提供智能路由服务，应用透明访问

OB Proxy高效路由转发

对SQL做基本解析，确定对应Leader所在服务器；

反向代理，将请求路由至对应的Leader；Leader位置无法确定时随机选择OB Server；

轻量SQL解析+快速转发，保证高性能，单OB Proxy每秒转发100w次请求。

非计算节点，无状态

每个OB Proxy是一个“无状态”的服务进程，不做数据持久化，对部署位置无要求；

OB Proxy不参与数据库引擎的计算任务，不参与事务（单机or分布式）处理；

不需要独立服务器，可以与OB Server共用一台服务器，如果应用对实时性要求高，也可以将OB Proxy部署到应用服务器中。

图12 OB Proxy

OB Proxy与中间件区别较大，它是无状态、不记录session信息。

4.2 数据可靠及高可用

RPO(Recovery Point Objective)，恢复点目标：这是一个过去的时间点，当灾难或紧急事件发生时，数据可以恢复到的时间点，是业务系统所能容忍的数据丢失量。
RTO(Recovery Time Objective)，恢复时间目标：在故障或灾难发生之后，数据库停止工作的最高可承受时间，这是一个最大可容忍时限，必须在此时限内恢复数据。
OceanBase RTO<30s，意味着当少数派故障时，OceanBase能够在30s内恢复业务，且不丢任何数据。

图13 业界对于恢复能力的定级

Leader或Follower副本故障，通过Paxos协议实现自动选举，整个过程无需人工干预。

传统数据库与OceanBase高可用方案对比

图14 高可用方案对比

4.3 分布式事务、MVCC、事务隔离级别

分布式事务跨机执行时，OB通过多种机制保证ACID

• Atomicity 原子性：依赖两阶段提交协议保证分布式事务的原子性；
• Consistency 一致性：保证主键唯一等一致性约束；全局快照；
• Isolation 隔离性：采用MVCC进行并发控制；所有修改的行加互斥锁，实现写-写互斥；读操作读取特定快照版本的数据，读写互不阻塞；
• Durability 持久性：Redo-Log使用Paxos协议做多副本同步。

OB两阶段提交协议特点

事务协调者和所有参与者都是高可用的；

协调者不写Redo-Log，无持久化状态；

Commit操作延时低（所有参与者都prepare成功即认为事务进入提交状态，立即返回客户端commit）；

全自动处理异常情况。

多版本并发控制（MVCC），解决读写互斥问题

图15 MVCC

事务隔离级别（Isolation Level）

OB支持以下两种隔离级别，应用系统可以根据需求进行选择：

Read-Committed：避免脏读，存在不可重复读和幻读（默认）；

Serializable：避免脏读、不可重复读、幻读。

4.4 实验
实验1：创建数据库、表、分区及管理数据
实验2：查看表和分区的分布情况
实验3：MVCC-分布式环境下保持全局（跨机）一致性

5 OB Server的SQL引擎和存储引擎

5.1 SQL 引擎

OB的SQL引擎支持MySQL和Oracle兼容模式。

MySQL兼容模式

MySQL 5.6语法完全兼容；

兼容MySQL通讯协议，MySQL应用可直接迁移至OceanBase。

Oracle兼容模式

兼容Oracle 11g语法；

支持90%的Oracle数据类型和内置函数，还在持续完善中；

支持分布式执行的存储过程（PL/SQL）。

图16 Oracle兼容性

5.2 存储引擎与备份恢复

传统磁盘库面临的问题

大量随机写：buffer pool和表空间页面“一一对应”，数据更新时会在磁盘上产生频繁的随机写（checkpoint）;
写放大：随机写导致SSD的写放大问题，影响性能及减少磁盘寿命。

OB准“内存数据库”+LSMTree，避免随机写

相比传统数据库的写频率，OB会尽量减少checkpoint的次数，增量数据会直接写入内存，我们都知道内存的容量是有限的，OB对于增量数据的转储与合并可通过如下机制进行，每次写盘是大数据量的操作。

达到内存使用阈值自动触发，无需人工介入

定时触发，如凌晨2点

人工干预

图17 准内存数据库设计

技术优势

这样的好处是内存中的增量数据是顺序写到磁盘，效率比随机写更高、同时延长了磁盘寿命。另外基于LSMTree的设计，数据在磁盘上默认是按主键有序排列，内存中的增量数据与磁盘的基线数据进行合并时，数据会重新被排列，可避免存储空间碎片问题，提高利用率。

LSMTree存储高数据压缩率，降低存储需求

OB会对数据进行2次压缩，第一次压缩是encoding，第二次是通用压缩。
使用同样的数据、块大小，OB相比MySQL 5.7会节省50%的存储空间。
支付宝其中的一块业务由Oracle迁移到OB，100T的数据存储在OB中仅用33T。
数据虽做到了压缩，但查询性能基本没有变化，写入（合并）性能有较大的提升。

备份/恢复，全局一致性的数据备份/恢复

支持全量备份和增量恢复：直接对存储层基线数据做全量备份，通过redo-log实现增量备份；在线备份对业务无影响；

最小粒度为租户：备份恢复目前支持的最小粒度是租户，备份灵活、节省空间；

全局范围内保证数据一致性：所有节点数据分别备份，统一管理；可恢复至全局统一的时间点，确保全局数据的一致性；

支持数据库上的任何操作：支持的数据包括用户权限、表定义、系统变量、用户信息、视图信息等逻辑数据以及所有的物理数据；

支持多种备份介质：可以备份至普通NFS，也可备份至阿里云对象存储（OSS）；备份恢复也可以恢复到任意时间节点；

性能：备份速度可以达到硬件处理能力上限；恢复速度取决于并发度，实测可达500MB/秒。

5.3 实验

实验1：查看SQL的执行计划-EXPLAIN命令
实验2：使用JDBC连接OceanBase
实验3：查看内存使用情况
实验4：查看磁盘空间使用情况
实验5：检查集群合并状态

6 OCP及ODC工具介绍

6.1 OCP简介

OCP(OceanBase Cloud Platform)是一款以OceanBase为核心的企业级数据管理平台，通过可视化的体验可高效管理OceanBase集群，支持高可用性、最多可同时管理500台主机、响应速度可达到秒级。

图18 OCP产品说明

图19 OCP核心功能

下面附上可视化界面的截图，对于运维人员来说可以用图形界面快速的完成各项运维管理工作。

图20 集群概览

图21 图形化创建集群

图22 合并管理

告警

OB定义了5个级别的告警，告警的范围包括集群、租户、服务、主机等。通过可视化界面可配置告警的范围、触发器条件、检测周期及告警信息等信息。
关于5个告警级别说明如图23所示。

图23 告警级别

6.2 ODC简介

ODC(OceanBase Developer Center)是为OceanBase数据库量身打造的企业级数据库开发平台，可通过B/S或C/S架构为开发者提供日常开发操作、WebSQL、SQL诊断、会话管理和数据导入导出等功能。

图24 ODC核心功能

工作台是数据库开发者编辑SQL或PL语句的工作区，界面及功能如下图。

图25 ODC工作台

数据导入导出

为便于开发者维护数据库中的数据，ODC提供整库导入导出和单表导出功能。

通过整库导入导出用户可以批量选择数据库中的表导入或导出其中的数据；

通过单表导出，用户可以导出目标表中的数据；

支持导入导出SQL文本和ODC格式的文件。

以上6大部分内容是对OBCA认证内容的整理，希望对备考OBCA的小伙伴有帮助，如有问题请联系tankdba@outlook.com，祝大家一次通过！

备注
文章封面及截图内容均来自OBCA线上课程。

参考资料
OBCA官方线上学习视频
https://www.oceanbase.com/training/detail?level=OBCA