大家期待的 OceanBase 4.0 发包了，很多新特性让人眼前一亮，大家可以上手测试一下了

2022 年中的 OceanBase 大会上，官方宣布了小鱼版本的发布，该版本属于业内首次推出的单机分布式一体化架构数据库。经过几个月的等待，今天（2022 年 11 月 2 日）OB 4.0 第一个版本终于发布了，大家可以从 Github 或官网社区版本下载页面，下载获取发布包进行测试啦。

• https://github.com/oceanbase/oceanbase/releases
• https://open.oceanbase.com/softwareCenter/community
  

1. 本版本的核心能力特性如下

• 架构升级与受益

  支持单机分布式一体化架构，包含自适应日志流、支持超大事务、RTO 时间降低到 8s 以内、NTP 服务依赖优化、支持分区数量能力上限等版本基础核心能力构建。

• 内核能力增强

  Online DDL 能力增强，支持租户级备份，字符集扩展，支持数据编码，支持 IOPS 隔离，LOB 规格上限扩展，支持表锁和死锁检测等。

• 兼容性增强

  支持 DDL 语句的外键约束，支持视图列信息展示，支持 DML 触发器，支持更多 SQL MODE 和函数等。扩展支持 SEQUENCE 对象，支持存储程序，支持 SQL 文本中的预处理，支持自增列做为分区键。

• 性能大幅提升

  SYSBENCH 性能优化，综合读写性能（Read Write）1024 并发测试性能相比于 V3.1 版本提升 1 倍。

  TPCH 查询性能优化，100GB 数据量顺序执行 22 条 SQL，整体性能相比于 V3.1 版本提升 5 倍。

• 运维能力提升

  支持全链路追踪，支持 SESSION 状态的监控和诊断（ASH），标准化视图优化，支持 Schema History 回收功能，支持自动清空回收站功能等。

2. 下面我们来看看官方放出的特性，诚意还是很足的

2.1 架构升级与收益

• 自适应日志流介绍

  OceanBase 早期版本的架构体系里以分区为基本单元进行操作，当系统内的分区数量达到一定程度之后，以分区为单元的操作的消耗也随之增大，逐渐形成了 OceanBase 的使用痛点：单节点支持的分区数量受到限制，单节点上涉及跨分区的数据修改也需要两阶段提交协议来保证事务的原子性等问题。

  日志流是由 OceanBase 自动创建和管理的实体，它代表了一批数据的集合，包括若干分区和有序的 Redo 日志流。在新的系统架构下，一个 Unit 内的所有分区的事务修改日志可以都记录在一个日志流中，通过日志流把修改同步到其他 Zone 的对应 Unit 上。OceanBase 的每个租户每有一个 Unit，就会有一个对应的日志流。系统会把一个日志流和其所对应的分区关系固定下来，只有迁移发生时，才会改变这个对应关系。

• 支持超大事务

  基于新的自适应日志流架构，对事务引擎进行重新设计，解决了分布式数据库普遍的大事务场景使用痛点，比如事务大、参与者数量多、事务提交卡等问题。新事务引擎能稳定应对在线业务、批处理、订正数据等多种业务场景，使得用户在各自繁杂的业务场景下可以放心的使用数据库。

• RTO < 8s

  基于全新的自动选主协议以及全面的探活机制，进一步将机器故障场景下系统恢复时间降低到 8s 以内，帮助业务系统更快恢复，最大程度减少业务影响，给业务带来持续可用的能力。

• NTP 服务优化

  基于全新的自动选主协议，取消了对 NTP 时钟的依赖，打破原来早期版本对所有节点的时钟偏差控制在 100ms 以内的强需求。OceanBase V4.0 版本允许的时钟偏差可以达到 2s，同时支持动态修改时钟，不会对数据正确性和集群稳定运行带来影响。

• 优化分区能力上限

  在自适应日志流的架构设计下，系统内部一个 Unit 内的所有分区共享一个资源组，大大降低了早期版本每个分区独立申请保存系统资源，提升系统资源的利用率，因此不再需要根据配置限制 OBServer 节点的分区上限个数，但分区上限仍受机器可用物理资源限制。

2.2 内核能力增强

• Online DDL 能力增强

  在 OceanBase 早期的版本中，由于架构设计上的限制，对数据库 Online DDL 能力进行了有限支持，例如不支持主键修改操作给业务使用带来了诸多不便。得益于新版本一体化的架构设计，OceanBase 针对涉及到数据搬迁的 Online DDL 操作进行增强支持，主要包括：

  • 支持添加主键、修改主键和删除主键

  • 支持添加外键、删除外键

  • 支持修改列名和列类型，包括字符、数值、日期等类型的相互转换

  • 支持普通表转换为分区表（很期待这个功能，属于早期版本的强需求）

  • 支持在线修改表或列的字符序

• 支持租户级备份（这个功能之前也反复被反馈，是一个强需求）

  多租户是 OceanBase 的核心价值能力之一，在大多数客户系统中，用户都选择在同一个集群中创建了多个租户，每个租户代表一个业务单元，根据业务的不同种类和对客户的重要程度，需要有不同的备份频率和策略进行细粒度支持。在 OceanBase V4.0 版本中将集群级别粒度的备份能力细化拆分到租户级别粒度，支持按租户级别的备份，也支持将备份数据恢复到新租户。优化数据备份快照保留策略，减少备份期间的磁盘空间影响。同时拆分数据备份与日志备份存储目录，支持分别接入不同性能的备份介质。

• 扩展更多字符集（字符集全面放开了，对 GBK 的支持在很多国内项目上是强需求，终于支持了）

  支持 UTF8、UTF16、GBK、GB18030 和 BINARY 字符集，新增支持 UTF8MB4_BIN、UTF16_BIN、GBK_BIN、GB18030_BIN、UTF8MB4_GENERAL_CI、 UTF16_GENERAL_CI、GBK_CHINESE_CI和GB18030_CHINESE_CI 排序规则。

• 向量化引擎开源（这个功能超级牛逼，是 OB 真正 HTAP 能力的利器）

  OceanBase 在商业版 V3.2.3 全面实现了向量化引擎，以 Architecture aware 的设计改造了全部的算子和绝大部分常用的执行表达式，充分发掘现代 CPU 的 cache 特性以及优化指令，并应用于 TPC-H 的 benchmark 中。向量化带来了大量的算法优化可能，通过在向量化的框架下进行算法和数据结构优化，实测整体执行性能相比原先非向量化执行引擎性能提升普遍在 4-5 倍，很多算子和单场景可获得 10 倍以上的性能提升。在本次版本发布中，OceanBase 将其向量化引擎能力全部开源，帮助用户在 OLAP 场景下获取更好的性能。

• 数据编码开源（压缩也是一个强需求，之前部分开放了压缩能力，新版本开放的这些能力，对客户降本增效越来越友好）

  OceanBase 通过数据编码压缩技术实现了数据的高压缩比，是帮助用户减小存储成本重要技术手段。OceanBase 本次开源多种数据编码方法，包括字典编码、RLE 编码、常量编码、差值编码、前缀编码、列间编码等，并支持每一列自动选择最合适的数据编码。通过编码和压缩，使用相同的块大小（16KB）、以及相同的压缩算法（lz4），同样的数据存放在 OceanBase 中，要比在 MySQL 5.7 中平均节省一半的空间，同时没有损失任何查询性能。

• 支持 IOPS 隔离

  OceanBase 早期的版本已经支持了租户级别的 CPU 和内存隔离，V4.0 版本开始支持租户间 IOPS 隔离，租户之间彼此感知不到对方对磁盘带宽的占用，避免租户间业务的 IO 资源争抢，实现完备的租户资源隔离能力。

  用户通过 UNIT CONFIG 设置 UNIT 的资源规格，其中 MIN_IOPS、MAX_IOPS、IOPS_WEIGHT 是 IOPS 隔离相关资源，租户的可用资源与 UNIT 绑定。通知支持动态调整租户的 IOPS 规格，修改 UNIT CONFIG 中的 IOPS 相关设置即可实时生效。在租户内部，支持通过配置项 io_category_config 分配各类别 IO（业务请求、系统日志等）请求的百分比，进而细粒度控制 IO 资源分配与调度。

• LOB 规格上限扩展

  在 OceanBase 早期的版本中，LOB 数据存储大小限制在 48MB 以内，这对客户使用 LOB 带来了强约束限制。在本次架构升级中，通过存储层将 Lob 宏块的数据拆成多条 Lob Meta 进行存储，取数据的时候再将多条 Lob Meta 中的数据聚合成一个连续 Buffer 返回给 SQL 层处理，这样突破了数据存储大小的限制，使得 LOB 存储上限扩展达到了 512MB，后续将持续优化到 TB 级别。

• 支持表锁和死锁检测

  表锁允许业务以指定的方式锁定表或分区，避免业务并发操作造成数据破坏。在 OceanBase V4.0 版本中支持了 Online DDL 操作，因此必须配套表锁保护 DDL 与 DML 并发时的正确性问题。新增支持 LOCK TABLE 语法，支持 SHARE 和 EXCLUSIVE 两种锁定模式，同时支持对锁冲突的死锁检测。

2.2 MySQL兼容性增强

• 支持 DDL 语句的外键约束

  OceanBase 数据库默认开启外键约束检查，外键约束检查开关由租户变量 FOREIGN_KEY_CHECKS 来控制，要求约束的列的值取自于另外一个表的主键列。在早期的版本中，外键约束检查仅对 DML 操作有效，DDL 操作不受影响。OceanBase V4.0 版本中支持了 FOREIGN_KEY_CHECKS 系统变量对 DDL 部分的影响，其行为保持与 MySQL 兼容。

• 支持视图列信息展示

  在 MySQL 数据库中，视图列信息和表列信息一样，被作为基础的元信息被存储在数据字典中，并通过 INFORMATION_SCHEMA.COLUMNS 显示给用户。OceanBase 数据库内部仅对表列信息进行了持久化存储，V4.0 版本通过采用动态解析视图定义的方法，避免了对视图复杂的依赖关系解析，实现在 INFORMATION_SCHEMA.COLUMNS 中展示视图列信息。

• SQL Mode 扩展支持

  扩展支持 MySQL 默认开启的 SQL Mode，新增支持 NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO 和 NO_AUTO_CREATE_USER 三个 SQL Mode，产品行为与 MySQL 兼容。针对 NO_ENGINE_SUBSTITUTION 仅支持语法兼容。

• 支持 SQL 文本中的预处理

  支持 SQL 文本中的预处理语句（Prepared Statements），Prepared Statements 接口使用二进制协议相比交互式 SQL 接口具有更高的执行效率，使用方法大体如下：

  • PREPARE 准备执行语句。PREPARE stmt1 FROM ‘SELECT SQRT(POW(?,2) + POW(?,2))’;

  • EXECUTE 执行准备好的语句。SET @a = 3; SET @b = 4; EXECUTE stmt1 USING @a, @b;；

  • DEALLOCATE PREPARE 释放一个准备好的语句。DEALLOCATE PREPARE stmt1;

• 支持自增列做为分区键

  例如：

  create table t2(inv_id bigint not null auto_increment ,c1 bigint, primary key (inv_id) ) partition by hash(inv_id) partitions 8;
  

  使用自增列作为分区键时需要额外注意，自增列的值全局唯一，但在分区内不保证始终增长，和原生 MySQL 行为不同。和其他分区方式相比，对这类分区表的插入操作性能会有一定的下降。

• 支持 SEQUENCE 对象（支持 SEQUENCE 了，也是一个经常被问到的需求）

  扩展支持 SEQUENCE 对象，满足业务系统对 SEQUENCE 对象的依赖诉求，降低客户在业务迁移过程中的适配复杂度。支持 CREATE/ALTER/DROP SEQUENCE 对象，支持获取 CURRVAL、NEXTVAL 和重置取值等对象操作，支持的对象取值范围从 INT64_MIN 到 INT64_MAX。

• 支持存储程序（开放了存储过程的支持👍）

  支持兼容 MySQL 5.7 语法的存储程序（包含存储过程和存储函数），支持游标、流程控制语句、异常处理、存储程序相关的DDL操作和视图和状态查询。同时扩展支持多个系统包，例如 DBMS_STATS、DBMS_SESSION 等。

• 支持 DML 触发器（对触发器不太感冒，多个功能总没错）

  支持在表上创建触发器，兼容 MySQL 5.6 语法。当在该表上 DML 操作满足条件时、触发用户自定义行为。

• 支持更多函数

  • 支持函数 ADDTIME()，将指定的时间间隔添加到给定的日期和时间。例如：SELECT ADDTIME(‘2007-12-31 23:59:59.999999’, ‘1 1:1:1.000002’);

  • 支持函数 DAYNAME()，返回给定日期的工作日名称。例如：SELECT DAYNAME(‘2018-01-8’);

  • 支持聚合函数 BIT_AND()/BIT_OR()/BIT_XOR()，返回表达式的按位与/或/异或的运算结果。

  • 新增函数 UUID_SHORT()，返回 64-bit 无符号整数。例如：SELECTUUID_SHORT();

2.3 运维能力提升

• 支持全链路追踪

  OceanBase 作为一款久经沙场的分布式数据库，其内部数据访问的链路已经非常复杂，当线上出现超时等问题的时候，往往无法有效快速定位问题出现的第一现场，需要依靠有经验的运维人员对追个环节进行排查，验证影响到运维效率和故障影响速度。OceanBase V4.0 版本设计了一套全链路追踪的机制，能够提升全链路问题定位的效率，贯穿从业务 APP > 客户端驱动(JDBC, OCI) > 代理（OBProxy）> 数据库节点（OBServer）到全部流程，用户通过 PL/SQL 或 OBClient 接口在应用程序 APP 中设置相关标识信息（MODULE/ACTION/CLIENT_INFO/CLIENT_IDENTIFIER）到正在使用的链接中，运维人员可以通过 PL/SQL 程序包，控制相关应用程序设置的标识信息维度是否打开全链路跟踪诊断以及设置诊断输出策略；诊断日志以 OpenTracing 数据模型输出到 OBProxy 和 OBServer 日志文件中进行保存, 通过对诊断日志解析, 即可达到追踪每个 SQL 每个事务在全链路中执行耗时等相关诊断信息。

• 支持 SESSION 状态的监控和诊断（ASH）

  OceanBase 数据库早期版本已经支持获取当前正在执行的 SQL 的状态信息，包括等待事件等信息，但只能通过 __all_virtual_session_wait 查询到 session 最近一次等待事件。OceanBase V4.0 版本支持更全面的 session 与等待事件之间的关系图（ASH），不仅包含当前执行的 SQL 的状态，还包含 SESSION、USER、SQL、WaitEvent 等多个维度状态历史信息。ASH 能够以 1s 为周期采样系统中所有 Active Session 状态，采用过程中全程不加锁不影响业务 SQL 的正常执行。OCP 通过对这些状态采样信息进行综合汇总分析，帮助用户了解过去一段时间里系统的负载以及等待状态，及时发现并预警问题。

• 支持实时执行计划监控

  OceanBase 在 SQL 执行计划的诊断中引入了 SQL Plan Monitor, SQL Plan Monitor 提供了关于逻辑执行计划、物理执行计划、算子吐行数、算子开始/结束时间点等信息, SQL Plan Monitor 信息只能在 SQL 执行完毕后获得，可以通过 GV$SQL_PLAN_MONITOR 租户级视图获取相关信息。OceanBase V4.0 版本支实时 SQL Plan Monitor，可以实时的查看当前租户各 SQL 执行计划状态，在客户实际业务场景或者是诊断分析场景, 如果存在 SQL 卡住的问题, 此时通过实时 SQL Plan Monitor 也可以查询各个执行线程执行算子的执行状态。

• 支持 Schema History 回收功能

  解决 Schema History 只增不删导致 Schema History 过多，影响 OBServer 启动慢的问题。通过隐藏配置项 _schema_history_recycle_interval 控制 Schema History 回收周期，该配置项缺省值是 0，表示关闭 schema history 回收功能。

• 支持自动清空回收站功能

  OceanBase 数据库回收站提供以租户为单位，当磁盘空闲空间不足时，按照 FIFO 策略，自动清理回收站空间的功能。增加配置项 recyclebin_object_expire_time 用于指定回收站中对象的过期时间。

3. 总结

上面给大家简单罗列了官方放出的 OceanBase 4.0 版本的新功能和改进点。相比于 OB 3.x 版本来说，有了相当大的改变。

对于我来说，开放了“压缩能力”、“向量化执行引擎”、“GBK 的支持”、“存储过程的支持”、“IOPS的隔离” 都有很大吸引力，另外还可以单机部署，保留后期扩展为分布式的能力。这些种种，都可以给业务带来无限的遐想。

接下来有时间会更多的进行测试验证，大家也可以关注我，共同交流和分享。

你对 OB 4.0 的期待点是什么呢？也可以在留言中说出来～

End～