【OceanBase专栏】OB背景知识

OceanBase && Oracle 相关文档，希望互相学习，共同进步

1.OceanBase产品简介

OceanBase 是巴巴集团自主研发的分布式关系型数据库，支持高并发、高可用、强一致性等核心特性，适用于金融、互联网等关键业务场景完全自主研发，支付宝长期内部使用，验证可用。

分布式企业版：原生分布式架构，通过分布式数据库安全可靠测评，适用于大规模核心业务系统。

单机企业版：集中式架构，兼顾性能与成本，适合中小规模业务。 ‌

社区版：开源免费，兼容MySQL语法，支持云上部署。
2020 产品立项第一个用户

2016 支付宝核心交易

2021 版本3.0发布，2022 版本4.0发布

1.1 OceanBase 分布式架构

Paxos协议 + 无共享架构 + 分区级高可用

多副本：一般部署为三/五个 zone, 每个zone 由多个服务器节点 observer 组成

基于 paxos 协议，数据全局强一致

原生多数据副本，支持跨地域容灾

RPO=0(少数成员故障) RTO<8s

所有节点均支持读写

两地三中心、三地五中心等多种落地方案。

单机分布式一体化：

1.2 核心特性

低成本：编码压缩+通用压缩，存储空间大幅减少

历史数据归档成本 OCeanbase:mysql = 1:12

1.3 OceanBase 数据库内核

（5高1多）

高扩展：水平扩展，在线扩容、缩容、不停服务；单集群突破100台服务器

高性能：峰值6100万次/s, 单表最大3200亿行，准内存处理性能

高可用：一个节点多个副本，少数副本故障数据不丢RPO=0 数据同步速度 >500MB/s

paxos协议投票, 根据zone 的优先级自动选 leader

高兼容：oracle 、mysql 两种兼容模式，降低业务迁移改造成本

可使用 MySQL 周边工具操作OceanBase, 如Navicat、dbeaver、datax.canal 等

高透明性：全局一致性快照，全局索引，自动事务两阶段提交

多租户：每个应用租户有专属的资源池，资源隔离、数据隔离、弹性调整

当Leader副本收到‌**多数派（Majority）**‌而非全部Follower副本的Redo Log落盘确认后，即可认为写操作成功，并向用户返回DML执行成功的响应.这种基于Paxos协议的多数派确认机制，在保证数据强一致性的同时，也兼顾了系统的可用性和性能.

1.4 OceanBase 工具体系

1.4.1 安装部署工具 OBD (OceanBase Deployer)

1.4.2 运维管理工具 OCP

1.4.3 数据迁移工具 OMS

OceanBase 迁移服务（OceanBase Migration Service，OMS）是 OceanBase 提供的一种支持同构或异构数据源与 OceanBase 数据库之间进行数据交互的服务，具备在线迁移存量数据和实时同步增量数据的能力

1.4.4 开发者工具 ODC

ODC 是OceanBase 量身定制的开发平台。

对象管理 : 支持完整的数据对象和数据类型，引导式创建数据库对象，可视化对象修改，支持回收站机制。
Web 控制台:帮助开发人员使用 OceanBase 的各种特性和功能，支持 MySQL和 Oracle语法高亮、格式化、智能提示、友好的 snippets 等特性，提供类似 Excel 的可视化数据编辑能力。

导入导出 : 量身打造的高效数据导入导出工具，具备动态负载均衡 和断点恢复等能力。

安全审计 :支持 14 类审计事件，确保安全合规，重要事件可追踪，审计报告可下载

流程管控:根据任务类型限制用户发起的变更内容、定制不同的审批流程，达到数据库变更安全的作用。

1）风险管控的能力：可配置脱敏

2）数据生命周期管理：可配置归档

场景：部分历史数据基本上不会有业务使用，为了降低业务库磁盘的使用并保障业务表数据的轻量，需要定期给业务库瘦身，如何在不影响业务稳定的前提下周期进行历史数据迁移呢?

1.5 OceanBase 数据库代理 ODP（obproxy）

ODP 是一个反向代理，可以在任意个节点上部署，也可以部署在任意节点（OBServer 服务器、应用服务器、网络中其他服务器等）。ODP 是通过第一次启动的时候指定 OceanBase 集群的 RootService 地址完成集群注册的，因此可以不关注具体部署在哪些服务器上。

ODP作为OceanBase数据库的访问入口，确实采用了无状态架构设计，这种设计意味着ODP服务进程本身不会存储任何持久化数据--> 无状态架构为ODP带来了显著的扩展性优势，能够轻松实现水平扩展。

ODP其核心职责是作为连接路由组件，负责接收SQL请求并智能转发至合适的OBServer节点，而非执行计算‌。

2.与传统数据库的对比

3.学习笔记

1）OBD 常被用来部署测试环境，或者演示环境，相比 OCP 更加轻量。

2）OBD 仅在部署集群时支持白屏化操作，但是集群部署完成之后的运维操作，如监控告警、备份恢复，就不支持白屏化了。

如果是要部署和运维一个生产环境，推荐直接使用 OCP，因为 OCP 自始至终的全部操作都是白屏化的。且 OCP 有一个在后台常驻的进程，可以用于监控和告警，并且 OCP 可以展示的监控数据也更多、更清晰。

3）OceanBase 通过 Paxos 协议同步事务日志，只需要多数派（不需要全部）副本的 redo 日志落盘成功，就会认为写操作执行成功。

4）ODP 不会直接对 SQL 进行计算，只需要解析 SQL 并转发，没有 SQL 执行模块。且解析 SQL 模块使用的是 ODP 自己定制的 Parser 模块，只会解析出 DML 语句中的数据库名、表名和 Hint，不需要通过其他复杂的表达式推演。然后再通过 location cache（路由表）获取分区的位置信息，根据路由规则确定要转发到的 observer 即可。ODP 的整个 SQL 转发逻辑是非常轻量的。

5）在 OceanBsae 里，每个 zone 中最多有一份全功能副本，租户有 3 个 zone，所以租户内最多有 3 份全功能副本。

6）在 OceanBase 里，每个 zone 中最多有一份全功能副本。在一个 5 个 zone 的集群里创建租户，租户可以有 1 到 5 个 zone，所以租户内可以有 1 到 5 份全功能副本。注意这里的用户租户不一定要在集群中每一个 zone 中都有副本，在创建用户租户时，可以选择让这个租户只涉及集群中的一个 zone 或几个 zone。

先到这里吧。。。

知识共享，欢迎大家点赞、收藏、共同探讨。ok 就这些吧