都 2024 年了还只会 MySQL 么？OceanBase 了解一下

OceanBase 概述

OceanBase 数据库（OceanBase Database）是一款完全自研的企业级原生分布式数据库，在普通硬件上实现金融级高可用，首创“三地五中心”城市级故障自动无损容灾新标准，刷新 TPC-C 标准测试，单集群规模超过 1500 节点，具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性。

核心特性

「高可用」独创 “三地五中心” 容灾架构方案，建立金融行业无损容灾新标准。支持同城/异地容灾，可实现多地多活，满足金融行业 6 级容灾标准（RPO=0，RTO< 8s），数据零丢失。

「高兼容」高度兼容 Oracle 和 MySQL，覆盖绝大多数常见功能，支持过程语言、触发器等高级特性，提供自动迁移工具，支持迁移评估和反向同步以保障数据迁移安全，可支撑金融、政府、运营商等关键行业核心场景替代。

「水平扩展」实现透明水平扩展，支持业务快速的扩容缩容，同时通过准内存处理架构实现高性能。支持集群节点超过数千个，单集群最大数据量超过 3PB，最大单表行数达万亿级。

「低成本」基于 LSM-Tree 的高压缩引擎，存储成本降低 70% - 90%；原生支持多租户架构，同集群可为多个独立业务提供服务，租户间数据隔离，降低部署和运维成本。

「实时 HTAP」基于“同一份数据，同一个引擎”，同时支持在线实时交易及实时分析两种场景，“一份数据”的多个副本可以存储成多种形态，用于不同工作负载，从根本上保持数据一致性。

「安全可靠」12 年完全自主研发，代码级可控，自研单机分布式一体化架构，大规模金融核心场景 9 年可靠性验证；完备的角色权限管理体系，数据存储和通信全链路透明加密，支持国密算法，通过等保三级专项合规检测。

OceanBase 发展历程

OceanBase 数据库是随着阿里巴巴电商业务的发展孕育而生，随着蚂蚁集团移动支付业务的发展而壮大，经过十多年各类业务的使用和打磨才终于破茧成蝶，推向了外部市场。本章节简述 OceanBase 数据库发展过程中一些里程碑意义的事件。

• 诞生

2010 年，OceanBase 创始人阳振坤博士带领初创团队启动了 OceanBase 项目。第一个应用是淘宝的收藏夹业务。如今收藏夹依然是 OceanBase 的客户。收藏夹单表数据量非常大，OceanBase 用独创的方法解决了其高并发的大表连接小表的需求。

• 关系数据库

早期的版本中，应用通过定制的 API 库访问 OceanBase 数据库。2012 年，OceanBase 数据库发布了支持 SQL 的版本，初步成为一个功能完整的通用关系数据库。

• 初试金融业务

OceanBase 进入支付宝（后来的蚂蚁集团），开始应用于金融级的业务场景。2014 年"双 11"大促活动，OceanBase 开始承担交易库部分流量。此后，新成立的网商银行把所有核心交易库都运行在 OceanBase 数据库上。

• 金融级核心库

2016 年，OceanBase 数据库发布了架构重新设计后的 1.0 版本，支持了分布式事务，提升了高并发写业务中的扩展，同时实现了多租户架构，这个整体架构延续至今。同时，到 2016 年"双 11"时，支付宝全部核心库的业务流量 100% 运行在 OceanBase 数据库上，包括交易、支付、会员和最重要的账务库。

• 走向外部市场

2017 年，OceanBase 数据库开始试点外部业务，成功应用于南京银行。

• 商业化加速

2018 年，OceanBase 数据库发布 2.0 版本，开始支持 Oracle 兼容模式。这一特性降低应用改造适配成本，在外部客户中快速推广开来。

• 勇攀高峰

2019 年，OceanBase 数据库 V2.2 版本参加代表 OLTP 数据库最权威的 TPC-C 评测，以 6000 万 tpmC 的成绩登顶世界第一。随后，在 2020 年，又以 7 亿 tpmC 刷新纪录，截止目前依然稳居第一。这充分证明了 OceanBase 数据库优秀的扩展性和稳定性。OceanBase 数据库是第一个上榜 TPC-C 的分布式数据库，也是第一个上榜的中国数据库。

• HTAP 混合负载

2021 年，OceanBase 数据库 V3.0 基于全新的向量化执行引擎，在 TPC-H 30000GB 的评测中以 1526 万 QphH 的成绩刷新了评测榜单。这标志着 OceanBase 数据库一套引擎处理 AP 和 TP 混合负载的能力取得了基础性的突破。

• 开源开放

2021 年六一儿童节，OceanBase 数据库宣布全面开源，开放合作，共建生态。

MySQL 兼容性

OceanBase 数据库的 MySQL 模式兼容 MySQL 5.7/8.0 的绝大部分功能和语法。由于产品架构不同，或者客户需求不大，有些功能并没有被支持。

「从 MySQL 到 OceanBase，应用迁移 0 改造」

「无缝 & 完整兼容 MySQL 生态」

没有最强只有更强

立足当下，面向未来，企业需要背负哪些数据库方面的KPI?

「降本、提升效率、稳定性、痛点解决、技术创新」

基础架构负责人：今年需要完成基础架构的30%降本KPI，不然就要扣绩效！！！

开发：再也不想熬夜做无休止的分库分表改造了！！！

DBA：问题到底出在哪里了？是业务还是数据库？定位问题的时间太长了！！！

业务：这个SQL查询怎么跑的这么慢，DBA 你赶紧过来解决下，别影响我们辅助安全驾驶计算啊！！！

SRE：数据库别宕机，网络别抖动，千万要撑住这个高峰期啊，不然又要写总结了！！！

OceanBase 给出的答案：

多租户

OceanBase 数据库采用了单集群多租户设计，天然支持云数据库架构，支持公有云、私有云、混合云等多种部署形式。

OceanBase 数据库通过租户实现资源隔离，让每个数据库服务的实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性，配合 OceanBase 数据库强大的可扩展性，能够提供安全、灵活的 DBaaS 服务。

租户是一个逻辑概念。在 OceanBase 数据库中，租户是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于云数据库的运维有着重要的影响。租户在一定程度上相当于传统数据库的"实例"概念。租户之间是完全隔离的。在数据安全方面，OceanBase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险。在资源使用方面，OceanBase 数据库表现为租户"独占"其资源配额。总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器。

HTAP 混合负载处理

一套系统同时处理 TP 和 AP，不会干扰关键业务，也不会产生额外的成本。 解决了 TP 库和 AP 库是不同数据库，要处理其中数据导入的问题，极大的简化了开发和系统复杂性。

OBKV – 多模处理

OceanBase = SQL + Redis + HBase 。

OceanBase 在最初的 KV 存储基础上发展为了关系型数据库，依然保留了 KV 存储的能力。

极致数据压缩

海量数据的存储设备成本是非常高的 , OceanBase 在不影响性能前提下，节约高达70-90%的存储成本。

OceanBase 数据库的高级压缩功能采用全新设计的行列混合存储结构，以及高效的数据编码技术与一系列综合的数据压缩算法结合的方法，实现了在使用相同后端进行压缩的场景下，存储空间大幅减少。

「通用压缩」

通用压缩指的是在压缩算法对数据内部的结构没有了解的情况下，直接对数据块进行压缩。这种压缩往往是根据二进制数据的特征进行编码来减少存储数据的冗余，并且压缩后的数据不能随机访问，压缩和解压都要以整个数据块为单位进行。对数据块的压缩，OceanBase 数据库支持 zlib、snappy、lz4 和 zstd 四种压缩算法，zstd 和 lz4 的压缩等级是 1，zlib 的压缩等级为 6，snappy 使用默认的压缩等级。在 OceanBase 数据库内部对默认16 KB 大小的微块进行压缩的测试中，snappy 和 lz4 压缩速度都比较快，但压缩率比较低，zlib 和 zstd 压缩率比较高但是压缩速度更慢一些。lz4 和 snappy 的压缩率相似但 lz4 压缩解压的速度会更快一些，同样，zstd 的压缩率与 zlib 相似但压缩解压速度都更快。

在 MySQL 模式下，支持用户指定单独选择 zlib、snappy、lz4 或 zstd 压缩算法；在 Oracle 模式下，兼容 Oracle 数据库的压缩选项，仅支持用户选择 lz4 或 zstd 的压缩算法。

「数据编码」

在通用压缩的基础上，OceanBase 数据库自研了一套对数据库进行行列混存编码的压缩方法（encoding）。和通用压缩不同，Encoding 建立在压缩算法感知数据块内部数据的格式和语义的基础上。OceanBase 数据库是一个关系型数据库，数据是以表的形式来组织的，表中的每一列都有固定的类型，这就保证了同一列数据在逻辑上存在着一定的相似性；而且在一些场景下，业务的表中相邻的行之间数据也可能会更相似，所以如果将数据按列进行压缩并存储在一起就可以带来更好的压缩效果。因此 OceanBase 数据库引入了一种 encoding 格式的微块。与所有数据逐行序列化到块中的 flat 格式的微块不同，encoding 格式的微块是行列混存的，逻辑上仍然是一组行的数据存在微块里，但微块会按列对数据进行编码，编码后的定长数据存储在微块内部的列存区，部分变长数据还是按行存储在变长区。并且在 encoding 微块中，数据是可以随机访问的，当需要读取微块中的某一行数据时，可以只对这一行数据进行解码，避免了有些解压算法读一部分数据需要解压整个数据块的计算放大；在向量化执行的过程中也可以对指定的列进行解码，降低了投影的开销。

极致高可用

高可用性（High Availability）通常指一个系统经过专门的设计，减少停工时间，从而保持其服务的高度可用性。假设系统可以一直提供服务，那么系统的可用性是 100%。如果系统每运行 100 个时间单位，会有 1 个时间单位无法提供服务，那么系统的可用性是 99%。

单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。从方法论而言，高可用保证的原则是“集群化”，或者叫“冗余”。只有一个单点，该单点宕机了会使服务受影响；而如果有冗余备份，一台机器宕机后还有其他备份能顶上。

为保证系统高可用，架构设计的核心准则是冗余，但只有冗余还不够，故障每次出现都需要人工介入恢复一定会增加系统的不可服务时间。因此，我们往往通过“自动故障转移”来实现系统的高可用。

ODP 的高可用特性就包含两个维度：

实现 ODP 服务高可用特性

发生故障后可及时恢复 ODP 的服务。

保证 OceanBase 数据库的高可用

如探测和识别 OceanBase 数据库节点的故障并加入黑名单，通过合理路由对应用端屏蔽数据库故障，当数据库节点故障恢复后及时洗白 OBServer 节点，充分利用每一台机器资源。

弹性扩缩容

随着用户业务的发展或衰退，同时业务在不同时段的峰值往往也不同，需要数据库提供弹性的服务能力，OceanBase 数据库通过租户扩缩容功能来支持业务的弹性服务能力。

租户扩/缩容可以提升/降低计算能力和存储容量，OceanBase 数据库提供了提高/降低资源规格、增加/减少服务节点两种途径来实现扩缩容：

• 提高单节点的服务能力：调大租户的资源规格（Unit Config），从而达到单节点的服务能力提升。

• 增加服务节点：通过增加 Unit Number 和增加 Primary Zone，从而增加服务节点，达到租户总服务能力的提升。这里的扩容操作可以抽象为：将 N 个服务单元扩容为 M 个服务单元，其中，M > N。

• Unit Number 由 N 变为 M 时，表示每个 Primary Zone 上，需要新增 M - N 个日志流，分布在 M - N 个新增的 Unit Group 上。

• Primary Zone 个数由 N 变为 M 时，表示每个 Unit Group 内，需要新增 M - N 个日志流，其 Leader 分布在 M - N 个新增的 Primary Zone 上。

缩容是扩容的反操作，本质上是降低租户的服务能力，包括计算能力和存储容量。可以是调小资源规格，从而降低单节点的服务能力；也可以是通过减少服务节点，包括减少 Primary Zone 个数和减少 Unit Number，从而降低租户的总服务能力。

性能优化

同等硬件环境下提供更好的性能，显著降低数据计算成本。

多核线性扩展的同时，确保性能做到线性增长，让每一份资源充分发挥最大作用。

单机分布式一体化

OceanBase 数据库为单机分布式一体化架构，支持单机在线转分布式部署。一套系统，从单机到分布式对用户完全透明，覆盖业务从小到大的增长需求，降低运维管控成本。

OceanBase （MySQL兼容模式） vs MySQL

典型应用场景

多租户场景

多点 DMALL。资源隔离、灵活管理。

业务痛点 ：

• 运维复杂度高：数据库 500+，规模持续增长
• 海外业务增长快，水平扩展需求增多
• 小商家共享资源，业务增长后经常需要搬迁

引入 OceanBase 后的解决方案：

• 多租户，内置资源隔离
• 内置资源扩展能力
• 高压缩率，极大降低成本

高并发场景

海底捞火锅。传统分库分表方案替换，按需弹性扩缩容，从容应对流量洪峰。

业务痛点:

• 业务上云，七夕双旦流量井喷，稳定性挑战大
• 持续分库分表增加开发运维成本

引入 OceanBase 后的解决方案：

• 高并发场景下的稳定可靠
• 内置资源扩展能力
• 弹性扩缩容，减少资源浪费

历史库场景

携程客服业务。基于 OceanBase 高压缩能力，成本降低 70-90%。

MySQL 历史库痛点：

• 数据量大，分库分表，水平扩容需要人工干预
• 分库分表方案多样，设计不合理容易出现数据不均问题
• 进一步降低存储成本

引入 OceanBase 后的解决方案：

• ODC 定期搬运数据
• MySQL 保留热数据(通常为一年内)
• OceanBase 保留全量冷数据
• 存储成本相比 MySQL 降低 85%

欢迎加入 DevXTalk 的技术交流群,在这里你可以和大佬们一起交流分享技术,行业经验,提升自我。总之期待你的加入...

「看完本文有收获？转发给更多的朋友吧」

「DevXTalk 不止于技术」