Skip to content

Releases: oceanbase/oceanbase

v4.3.5_CE_BP1_HF2

18 Jun 10:10
Compare
Choose a tag to compare

版本信息

项目 描述
发布日期 2025-06-18
版本号 V4.3.5_CE_BP1_HF2
Commit 号 3ee4473
RPM 版本号 oceanbase-ce-4.3.5.1-101020012025061620

缺陷修复

  • 修复 V4.3.1 升级到 V4.3.3 或后续版本,可能出现的 meta 租户 clog 盘满的问题。
  • 修复 arm 环境下查询可能出现非预期的 NULL 值的问题。
  • 修复多分区表大量空分区场景下,可能出现的频繁拉取统计信息全表的问题。
  • 修复 rebuild 向量索引时可能出现的卡住超时的问题。
  • 修复向量索引在 rebuild 索引过程中,查询不走向量索引的问题。
  • 修复分区分裂场景下,可能出现的合并 4016 的问题。
  • 修复在大数据量场景下,分裂采样的 SQL 性能耗时较高,导致建索引执行慢的问题。
  • 重建 ivf 索引后 replace into 报错 ERROR 5500 的问题。

v4.2.5_CE_BP4

06 Jun 02:33
Compare
Choose a tag to compare

版本信息

项目 描述
发布日期 2025-06-06
版本号 V4.2.5_CE_BP4
Commit 号 899693f
OBServer RPM 版本号 oceanbase-ce-4.2.5.4-104000062025053011

功能增强

  • 系统视图性能优化

    重构 information_schema.COLUMNS 视图,在大部分的点查场景下,支持从 TABLE_NAME 等字段抽取 QUERY_RANGE

  • 优化器功能增强

    部分串行计划优化为并行计划提速,并在部分场景下将子查询由延后计算更改为提前计算降低计算数据量。

  • Full Schema 刷新性能稳定性增强

    执行 DDL 操作后,刷新 Schema 的行为由 Session 级更新调整为 Server 级别更新。在同时存在大量 Session 连接的场景下,解决了执行 DDL 操作后每个 Session 连接均触发一次 Schema 刷新操作带来的性能抖动的问题。

  • 支持添加二级分区

    当二级分区为 range [columns]/list [columns] 分区时,一旦数据超过初始创建的最大分区的上限后,新行就无法插入。如果不能动态添加二级分区,就只能通过重建表的方式解决,为运维带来不少的麻烦。新版本在 MySQL 模式下扩展支持增删二级分区的新语法,提升分区管理的易用性和灵活性。

  • 空表创建索引速度优化

    大幅缩短为空表创建索引的时间,分区越多的场景提升效果越明显。非分区表大约提速两倍,16 分区提速 8-16 倍,1024 分区提速 16-40 倍。

  • 新增备库日志裁剪功能

    在一主多备架构中,当主租户发生故障时,Failover 会优先选择同步位点最高的备租户作为新主租户。然而,可能存在其他备租户的日志 SCN 超过新主租户同步位点的情况,导致这些备租户无法直接加入新主租户的同步链路。此时需要通过日志裁剪功能,移除这些备租户上超出新主租户同步位点的冗余日志,使其能够正常加入新主租户的同步组。

  • 新增日志流再均衡功能

    消除非分区表集中分布或分区表的表分区连续分布时,可能带来性能热点的隐患。非分区表在解除表组绑定后表将均匀分散到多个日志流从而避免集中分布;分区表若先减少 primary_zone/unit_num 再增加,其表分区在各日志流上将随机均匀分布。

  • 备库读功能优化与稳定性增强

    通过优化事务状态推断机制,将原本需要每个副本独立收集参与者状态的方式,改为由协调者 Leader 统一收集和缓存,显著减少消息交互次数。同时引入重试机制,在副本落后时自动转发请求至其他副本处理,以避免阻塞或对事务状态进行错误推断。

  • 旁路导入支持异步 Commit

    旁路导入分为 Write 和 Commit 两个阶段,通过将 Commit 阶段变成异步的方式可以让单个导入任务只计算 Write 阶段的时间,减少因超时导致整个导入任务回滚的情况。

产品行为变更

  • 系统视图中会话 ID 字段语义调整为 Client Session ID

    ODP V4.2.3_CE 及之后版本与 OceanBase 数据库 V4.2.5_CE 及之后版本,配套支持全局唯一的 Client Session ID,实现跨组件的会话管理。但在前期实现中,仅针对会话管理相关的视图(如 GV$OB_PROCESSLISTINFORMATION_SCHEMA.PROCESSLIST 等)做了适配,其他视图如 GV$OB_SQL_AUDITGV$OB_ACTIVE_SESSION_HISTORYGV$OB_TRANSACTION_PARTICIPANTS 等使用的均为老版本的 Server Session ID,无法针对当前会话做一些关联分析和诊断。新版本统一了系统视图的会话 ID 语义,整体调整为展示 Client Session ID。

  • sys 租户调用普通租户的部分系统包

    为提高运维便利性,支持 DBMS_STATS 的相关子过程 DBMS_RESOURCE_MANAGERDBMS_BALANCEsys 租户下调用。

函数变更

函数 变更类型 变更说明
PERCENTILE_CONT 新增 MySQL 模式下新增函数,用于计算指定列的精确百分位数。该函数会对输入列进行升序排序,并根据给定的百分位值(percentile)返回对应的插值结果。

视图变更

视图 变更类型 变更说明
DBA/CDB_OB_TENANT_FLASHBACK_LOG_SCN 新增 用于记录日志裁剪操作的相关记录。
DBA_OB_TENANTS 新增列 新增 FLASHBACK_LOG_SCN 列,用于记录租户最近一次日志裁剪的位点。
[G]V$ACTIVE_SESSION_HISTORY 等包含字段 SESSION_ID 的视图 语义变更 字段 SESSION_ID 语义在 V4.2.5 BP4 变更:
  • V4.2.5 BP4 之前版本:
    在所有连接方式(直连模式/ODP 模式)下,该字段均表示 Server Session ID。
  • V4.2.5 BP4 及之后版本:
    • 在直连模式下:
      该字段表示 Server Session ID。
    • 在 ODP 模式下:
      • 当 ODP 中的配置项 client_session_id_version = 2 时,该字段表示 Client Session ID。
      • client_session_id_version = 1 时,该字段表示 Server Session ID。

语法变更

语法 变更说明
新增二级分区增删语法 扩展 range [columns]/list [columns] 二级分区增删语法。
新增备租户日志裁剪语法 备租户日志裁剪运维命令 ALTER SYSTEM FLASHBACK STANDBY LOG TO SCN = $flashback_log_scn [TENANT = 'tenant_name']; 支持将备租户的日志裁剪到指定位点,这个指定位点一定要大于等于该备租户的同步位点。

升级说明

  • 支持 V4.2.1_CE_BP10 及之前版本先经停 V4.2.1_CE_BP11 版本后再升级到 V4.2.5_CE_BP4 版本。
  • V4.2.2_CE 版本需要经停 V4.2.2_CE_BP1 版本升级到 V4.2.5_CE_BP4 版本。
  • V4.2.3_CE/V4.2.4_CE/4.2.5_CE 版本可以直接升级到 V4.2.5_CE_BP4 版本。

缺陷修复

  • 修复部分场景下,information_schema.COLUMNSinformation_schema.KEY_COLUMN_USAGE 查询结果不一致的问题。
  • 修复分区表在数据量差异过大场景下,因分区负载不均衡导致报错 4013 的问题。
  • 修复部分场景下,select LAST_INSERT_ID() 返回的自增 ID 与 MySQL 行为不兼容的问题。
  • 修复 ARM 环境下,索引查询结果可能不符合预期的问题。
  • 修复 OBKV 在主键中包含 DATETIME/DATE 类型, 使用 Batch 做 Get 操作时,可能存在查询结果不符合预期的问题。
  • 修复部分场景下,Transfer 加表锁超时并持续重试,导致机器 CPU 持续占用较高的问题。
  • 修复部分 PL 场景下,可能存在的 ResultSet 和 SqlExecutor 模块内存泄漏的问题。
  • 修复部分场景下,磁盘性能校准数据不准的问题。

v4.3.5_CE_BP2_HF1

29 May 02:46
Compare
Choose a tag to compare

Version information

Information Description
Release date 2025-05-29
Version V4.3.5_CE_BP2_HF1
Commit ID 2291c2a
RPM version oceanbase-ce-4.3.5.2-102010012025052715

Bug fixes

  • Fixed the issue where SQL execution for split sampling takes a long time in large data volume scenarios, resulting in slow index creation.
  • Fixed the issue where the meta tenant's clog disk may become full after upgrading from V4.3.1 to V4.3.3 or later versions.
  • Fixed the issue where errors 4016 and 4377 could occur during queries on vector tables with extra information.
  • Fixed the issue where vector query results might be inaccurate in scenarios with low filter rates.
  • Fixed the issue where memory leaks occurred in the VIndexVsagADP module in some tenant deletion scenarios.
  • Fixed the issue where background tasks for vector indexes reported error 4016.
  • Fixed the issue where major compactions took excessively long in scenarios with a large number of schemas.

版本信息

项目 描述
发布日期 2025-05-29
版本号 V4.3.5_CE_BP2_HF1
Commit 号 2291c2a
RPM 版本号 oceanbase-ce-4.3.5.2-102010012025052715

缺陷修复

  • 修复在大数据量场景下,分裂采样的 SQL 性能耗时较高,导致建索引执行慢的问题。
  • 修复 V4.3.1 升级到 V4.3.3 或后续版本,可能出现的 meta 租户 clog 盘满的问题。
  • 修复带 extra info 的向量表查询可能报错 4016 和 4377 的问题。
  • 修复在向量查询在过滤率较小的场景下,查询结果可能不准确的问题。
  • 修复部分删租户场景下,VIndexVsagADP 模块内存泄漏的问题。
  • 修复向量索引后台任务报错 4016 的问题。
  • 修复 Schema 较多的场景下,合并时间过长的问题。

v4.3.5_CE_BP2

16 May 08:23
Compare
Choose a tag to compare

版本信息

项目 描述
发布日期 2025-05-16
版本号 V4.3.5_CE_BP2
Commit 号 f481a33
RPM 版本号 oceanbase-ce-4.3.5.2-102000112025051418

升级路径支持

  • 支持从 V4.3.x 各版本升级到 V4.3.5 BP2 版本。

  • 不支持 4.2.x 系列或更低版本升级到 V4.3.5 BP2 版本。

  • 自 V4.3.2 重构了多源数据的持久化格式,升级过程中需要对新旧多源数据格式进行转换,在分区数较多时预留相对充足的升级时间。

  • 对于有持续写入的向量场景,需要进行索引重建。rebuild 命令执行完成后,需要再等待 1 分钟,确保 rebuild 过程中额外使用的向量内存释放,再开始升级。

  • V4.3.0/V4.3.1 版本升级到 V4.3.5 BP2 版本时,需要提前 1 天停止 transfer 任务。通过 ALTER SYSTEM SET enable_transfer = False; 停止,升级后再设置为 True 打开。

  • V4.3.0/V4.3.1/V4.3.2 版本升级到 V4.3.5 BP2 版本混部过程中,租户 Leader 在老节点时会导致 transfer 失败,需要升级至 V4.3.5 BP2 版本才能正常执行 transfer。

  • V4.3.1 版本升级到 V4.3.3/V4.3.4/V4.3.5(BP1/BP1 hotfix1)/V4.3.5 BP2 版本过程中,可能会遇到 meta 租户满的问题,一定概率会触发。规避该问题,需要 V4.3.1 先升 V4.3.2,再升 V4.3.5。或者等该问题修复版本(预计会在 V4.3.5 BP1 hotfix6 和 V4.3.5 BP2 hotfix1 修复),再升级。

  • V4.2.5 BP3、V4.3.5 BP1、V4.3.5 BP2 增加对 X86 环境运行的指令集要求。

    OBServer 会在启动前检查当前环境是否支持 AVX 指令集,如果缺少该指令集会禁止启动。将不支持 AVX 指令集的 X86 机器上的旧版 OBServer 升级至上述版本会造成无法启动和回退的情况,请务必关注。

特性增强

  • 备份归档适配 OSS WORM

    阿里云 OSS 提供了 WORM(Write Once Read Many)特性,用户通过命令为 Bucket 配置保留策略后,在保留策略指定的 Object 保留时间到期之前,仅支持在 Bucket 中上传和读取 Object。Object 保留时间到期后,才可以修改或删除 Object。新版本 OceanBase 数据库备份归档适配了阿里云 OSS 的 WORM 特性,支持使用已配置合规保留策略的 OSS Bucket 作为备份归档目的端,帮助用户满足数据安全存储及政策合规要求。

  • 备份归档支持动态更新 ak/sk 信息

    出于安全考虑,对象存储 Access Key/Secret Key 存在变更的可能。因此新版本 OceanBase 数据库支持了在设置备份归档路径后,变更 ak/sk 信息的能力。

  • 表级恢复支持恢复列存表

    该版本前,表级恢复功能仅支持恢复成行存表。新版本完善了表级恢复功能,增加支持恢复成列存表/行列存混表。

  • 分区伪列

    为了方便业务实时查看数据对应的分区信息,OceanBase 数据库新增 6 个自有伪列(__ob_partition_id__ob_partition_index__ob_partition_name__ob_sub_partition_id__ob_sub_partition_index__ob_sub_partition_name),分别用于查询该行数据对应分区/二级分区的分区 ID 序号、分区 Index 序号及分区名称。如业务强依赖以上同名字段作为普通列名,可通过修改 _enable_pseudo_partition_id 隐藏配置项为 False 该将伪列功能关闭。

  • 复合 DDL

    支持部分场景的复合 DDL,如 ALTER TABLE 支持同时修改列名和增加 NOT NULL 约束、支持两列同时添加 NOT NULL 约束,也支持了 ALTER TABLE 更改含前缀索引的列类型。

  • 堆表旁路导入性能优化

    优化堆表旁路导入新建唯一索引过程中的唯一性校验流程,堆表全量导入非分区表性能不低于索引组织主键表性能。

  • 全量刷新物化视图支持基于外表和普通视图构建

    V4.3.5 BP2 版本前,OceanBase 数据库已经支持基于用户表和物化视图创建物化视图,新版本在全量刷新场景下增加支持基表为视图或外表的物化视图,扩展物化视图的适用场景。

  • 物化视图诊断能力增强

    新增 CDB/DBA_MVIEW_RUNNING_JOBS 系统视图用于展示正在进行的物化视图任务,如刷新任务、MLOG 清理任务等。新增 DBA_MVIEW_DEPS 系统视图用于展示物化视图的依赖对象信息。CDB/DBA_MVIEWS 系统视图增加物化视图刷新位点和刷新延迟时间记录。CDB/DBA_MVIEW_LOGS 视图增加 MLOG 清理使用的并行度和耗时信息。

  • 硬解析性能优化

    在一些 AP 场景或部分大小账号场景,关掉 Plan Cache 走硬解析的方式可以减少使用到差计划的情况。而关掉 Plan Cache 就对硬解析的性能提出了更高的要求。新版本通过优化 resolver 阶段的热点函数、将不必须全局代价验证的场景替换为局部代价验证、精简表达式内存占用、移除非必要的表达式类型推导操作等方案,提升了优化器 resolve、改写等阶段的性能。

  • 统一统计信息过期判定策略和收集内容

    如果统计信息更新机制与业务数据变化节奏不一致,如日间表数据发生重大变化时,系统采用的定时更新策略可能会存在 10+ 小时的滞后窗口,这种情况就依赖系统提供短间隔的异步收集能力来修正。而目前 OceanBase 数据库异步收集的过期标准是 10 倍数据变化,及时性不够,不收直方图,统计信息有缺失。新版本统一了异步收集和定时自动收集的过期判定策略和收集内容,优化统计信息的有效性。

  • 统计信息收集 Skip Index 的 min/max 信息排列的有序度

    FULL TABLE SCAN 通过 Skip Index 优化(行存表可自行建立,列存表默认建立),在有 Range Query 的场景下会比走一般的 b-tree 索引然后回表查询更快。为了衡量 Skip Index 优化效果,我们引入一个 Skip Index 有序度的概念,即 Skip Index 的(min,max)信息排列的有序程度,有序程度越高则可以认为 Skip Index 的过滤性越好。新版本统计信息增加收集 skip rate 有序度,便于进行更准确的计划代价估计。

  • 数据倾斜场景计划优化

    OceanBase 数据库优化器的分布式计划优化是基于 sharding(即数据的分区信息)描述,来决策合适的、最优的分布式计划。但是在表分区数过少、分区间数据严重倾斜或连接键严重倾斜的场景,还存在一些分布式计划不优的问题。新版本针对表分区数量过少的场景,选择使用 slave mapping 计划,通过分区内并行提升性能;分区间数据倾斜场景,由执行器在调度期间感知数据量,自适应分配执行线程;连接键倾斜的场景,优化器基于直方图确认倾斜,并使用 hybrid hash 自适应计划。

  • 优化器功能增强

    部分串行计划优化为并行计划提速,部分场景下将子查询由延后计算更改为提前计算降低计算数据量。强化非精确谓词和动态采样的估行策略,细化大字段类型的代价模型。支持 OR + INLIST 条件改写为 Value Table,优化 ENUM/SET 类型查询改写等。

  • Sort 性能优化

    新版本优化了 Order By 实现,定长数据类型排序键,总字节数小于 15 时,大部分场景存在明显性能提升。

  • CSV 解析性能优化

    Load Data 处理 CSV 文件或使用 CSV 外表的场景,文件解析效率不够优。OceanBase 数据库 V4.3.5 BP1 版本针对包裹符、分隔符的判断逻辑做了优化,V4.3.5 BP2 版本在此基础上,进一步优化了换行符的判断逻辑。CSV 文件解析性能相对老版本提升近一倍。

  • 向量化改造

    boolnotnot_betweencast_float_to_decimalcast_decimal_to_floatfind_in_setceilfloorround 等表达式,直方图聚合函数,Array 数据类型等完成向量化 2.0 引擎适配。

  • Map 数据类型

    Map 数据类型用于存储无序的键值对(key-value pair),例如 {a:1, b:2, c:3},常见使用场景包括保存配置选项信息、用户属性、产品信息等。OceanBase 数据库在 V4.3.5 BP2 版本实现了 Map 数据类型,并支持了 Map 构造函数及 map_keysmap_values=/!= 等函数和操作符。

  • JSON 半结构化存储

    半结构化数据当前都以二进制串的形式存储,难以利用 Encoding 进行编码压缩,每条数据为了做到自解释,实际上冗余存储了一些数据 Meta,存储压缩率比较低。而 JSON 是一种典型的半结构化数据,有较强的结构化特征,理论上可以将半结构化数据在逻辑上拆分成多个基础类型的列,不可拆解的部分则放在一个 Binary 列中,结构化列可以利用 Encoding 提高压缩率,不可拆解的部分,由于提取了数据 Meta 相比以前空间占用也会减少,我们称之为 “半结构化列的结构化存储”。OceanBase 数据库在 V4.3.5 BP2 版本支持了 JSON 类型的半结构化存储,并实现了对应的编码方式,降低了存储空间占用,并优化了针对 JSON 子列的查询过滤性能。但因为 JSON 被拆成多个子列存储,对于需要频繁读取原始 JSON 数据的场景,引入了合并开销,会有性能回退,需要根据业务类型选择是否开启该特性。

  • Plan Cache 自适应

    Plan Cache 是 TP 场景至关重要的能力,因此会默认开启。而在某些 AP 场景下,计划执行时间是计划生成时间的很多倍,这种情况下让优化器每次生成计划比计划复用往往能使用到更优的执行计划,进而获得更好的执行性能。不同场景下,尤其是 HTAP 混合负载场景中,需要提供一种方式让偏 AP 的 SQL 走硬解析,偏 TP 的 SQL 依然可以复用计划省去硬解析开销。因此,OceanBase 数据库在新版本支持了一种 Plan Cache 自适应的能力,可以根据 SQL 执行时长和耗时分布特征来决策是否使用该 SQL 的 Plan Cache。

  • 全文索引 NGRAM2 分词器

    全文索引新增内置 NGRAM2 分词器,支持基于 min_ngram_sizemax_ngram_size 范围内的 NGRAM 分词。 NGRAM2 分词器适用于对性能和存储空间相对不敏感且需要对不同长度的 token 进行检索的场景。对于定长 token 可以使用 NGRAM 分词器。

  • 宏块 Bloom Filter 持久化

    OceanBase 数据库的 Bloom Filter 是自适应创建的,当宏块空查次数达到阈值(默认 100)后,异步发 IO 读取整个数据宏块并建立全内存的 Bloom Filter 放入 cache 中。查询时如果有 Bloom Filter 存在,则会通过 Bloom Filter 做 rowkey 判空,进而提升主键过滤速度。在此基础上,新版本支持了 Bloom Filter 落盘,在 Compaction 过程中完成 Bloom Filter 计算并持久化到宏块 meta 中,向上聚合到 index tree 中间层宏块行,这样可以在查询到宏块层后直接对 Bloom Filter 进行判空。允许用户表级开启或者关闭宏块级别 Bloom Filter,对应的表属性为 enable_macro_bloom_filter

  • 内存申请释放性能优化

    新版本优化主路径内存申请释放的性能,降低主路径内存申请的 CPU 开销,进而提升系统整体性能。

  • 资源隔离能力优化

    解耦 CPU 隔离和 IO 隔离,支持不开 IO 隔离的情况下单独开启 CPU 隔离。解耦 IO 隔离和 IO 校准,支持不做 IO 校准的情况下设置 IO 资源隔离。针对 clog(日志盘)和 data(数据盘)共用同一磁盘的场景,支持单独对 clog 进行 IO 资源限制。

  • 物化视图任务接入资源隔离

    物化视图的刷新、Purge 等操作会消耗系统资源,可能因此影响前台任务的性能。新版本基于 Resource Manager 为物化视图的增量刷新、MLOG Purge 提供了资源隔离的能力,用户可以限定物化视图任务使用的资源上限。

  • 大规格国产 CPU 服务器扩展性提升

    大规格服务器,尤其是信创客户依赖的国产化 CPU 大规格服务器中,一般有多个 NUMA node。由于跨 NUMA 内存访问带来的性能开销,压测时无法做到线性扩展。新版本通过 ob_malloc 适配 NUMA 亲和性、工作线程栈内存绑定 node、请求多队列优化等方案,在海光 7490 关超线程 128c 8numa 环境,sysbench 不同场景提升 6%-35%。

  • Batch DML 性能优化

    通过在存储层实现真正的批量接口,在诸如 batch insertdelete 大量数据、insert on duplicate key update 等 Batch DML 场景的性能得到明显的提升。

  • 后台任务定期重编译过期 PL 对象

    PL 对象编译耗时随 PL 文本的增大而增加,PL Cache 或落盘的编译结果过期后,如果不能及时重新编译,调用 PL 对象时可能会存在明显的性能下降。为减少业务感知到该类问题,新版本增加后台任务定期重编译过期 PL 对象的功能,当缓存失效之后,系统会定期将失效的缓存进行自动重编译。可通过设置隐藏配置项 _enable_pl_recompile_jobTrue 来开启该功能。

  • PL 缓存匹配规则优化

    PL 会依据编译时的 INFLUENCE_PLAN 类型的系统变量做缓存匹配,如果执行期的变量和编译时的不一致,可能无法命中缓存。而 INFLUENCE_PLAN 类型的系统变量中,存在一些只影响 SQL 计划、不影响 PL 计划的变量,新版本优化了这些变量的处理,让更多场景可以命中 PL 缓存。

  • Event Scheduler

    新增 Event Scheduler(事件调度器) 功能,用于定时执行 SQL 或匿名块语句,适用于定时跑批、定期数据维护等场景。将事件调度器集成到数据库中,减少了对外部调度工具的依赖,简化了运维操作。

  • 表锁

    新增 LOCK TABLEUNLOCK TABLE 语法,上锁以后,会阻塞其他的上锁、写入或者 DDL 操作;同时增加了 LOCK TABLES 权限,用于限制可执行上述语法的用户。为了满足无锁边更工具的 Online DDL 需求,引入租户级配置项 enable_lock_priority,设置为 True 时,RENAME TABLE 语句具有最高的上锁优先级;否则 DDL 优先级均低于 DML 优先级。

  • 串行化隔离级别支持弱读请求

    在 Repeatable Read 和 Serializable 隔离级别下支持弱读请求。

  • 复制表副本选择优化

    事务内复制表做过变更场景下,查询计划选择复制表 Leader 副本。事务内有一张复制表有修改之后,整体复制表副本选择逻辑回退成普通表副本选择逻辑。

  • 动态分区管理

    业务常常会选择以日期或时间作为 Range 分区键,将不同时间段的数据划分至不同分区中,目前会要求 DBA 定期地预创建一些未来时间的分区来满足数据写入。一旦因为某些原因 DBA 忘记预创建分区,可能会导致数据因为分区不存在而写入失败,对业务造成影响。因此,新版本提供了一种动态分区管理的功能,通过为表指定动态分区管理属性,在内核层面自动预创建未来时间的分区,减轻 DBA 的负担。同时,动态分区管理也支持自动删除业务不再需要的过期分区,节省存储。

  • 快速删列

    老版本删列是 Offline DDL,需同步等待数据重整完成,随着数据量增加 DDL 耗时也会增加。新版本实现了快速删列功能,删除列过程中不重整表数据,只在 TableSchema 中标记列被删除(即 UNUSED 列)。由于没有重整数据操作,磁盘水位线并不会因为删列完成而下降。如果想要彻底移除标记删除列,需要执行 ALTER TABLE TABLE_NAME FORCE 命令等待数据重整。

  • 全局索引自动分区分裂

    全局索引的查询以范围扫描居多,因此把全局索引的分区规则设置为 Range 分区会比较合适,可以利用分布式资源加速查询。但如何给索引的分区设置上下界是个让用户头疼的问题。为了让用户无感地使用具有最佳分布的索引表,OceanBase 数据库在 V4.3.5 BP2 利用自动分区分裂的能力,默认让全局索引按照一定的数据量大小自动分裂,无须手工配置。并提供了 global_index_auto_split_policy 配置项去控制全局索引的自动分裂策略。

  • 配置项修改与部分 DDL 的执行与 RS 状态解耦

    新版本将配置项的修改、部分 DDL(如 CREATE/ALTER/DROP DATABASECREATE/CREATE_LIKE/ALTER/DROP/RENAME/TRUNCATE TABLECREATE/DROP/UPDATE STATUS INDEXTABLEGROUP/TRIGGER/PACKAGE/SYNOMYM/OUTLINE 等操作)的执行与 RS 的状态解耦,使其不依赖 RS 的上任和卸任。在 RS 不能提供服务的时候,依旧可以进行系统配置项和租户配置项的修改,也不影响用户常见的 DDL 语句,提高了系统的可用性。

  • ODPS(MaxCompute)Catalog

    为了方便查询存储在各类外部数据源中的数据,新版本支持了 External Catalog 框架,并在一期支持了 ODPS Catalog 功能。OceanBase 数据库原有的内部对象归属于 Internal Catalog;用户可自己创建 External Catalog 来连接外部数据源,获取外部数据的元信息。支持直接查询 External Catalog 下的表数据,如 SELECT col1 FROM catalog1.database1.table1; 满足权限要求时,也支持任意跨 Catalog 的表关联查询。无需再进行数据导入或一张张单独创建外表,提高了外部数据访问的易用性。

  • Load Data 导入 URL CSV 外表容错模式

    Load Data 方式导入数据,当前遇到数据类型不兼容、精度不匹配等问题时,会直接报错。新版本增加 LOG ERRORS 指令用于容错导入,会记录失败行,通过 SHOW WARNINGS; 命令查看错误数据,进行错误诊断。

  • OBKV-HBase 二级分区

    OBKV-HBase 已经支持了基于 K 或者 K 生成列的一级分区方式,这样可以保证 OBKV-HBase 的事务都是单机事务。但是 TTL 删除数据的时候需要将所有分区数据都读取出来,判断过期并执行删除,性能较差,也会给合并带来更多压力。如果 OBKV-HBase 能支持基于时间进行一级分区,然后基于 K 进行二级分区,那么就可以直接通过删除分区来更快的回收过期数据。因此新版本扩展支持了基于时间(T)进行一级 Range 分区 + 基于 key(K)进行二级 Key 分区,或基于 Key(K)进行一级 Key 分区 + 基于时间(T)进行二级 Range 分区的分区表类型。使用该特性前,需要先将 _obkv_enable_distributed_execution 设置为 True。

  • OBKV-HBase 时序模型

    新增时序 KTSV 模型,结合半结构化存储将 HBase 中的 qualify 转成 json 进行存储,同时也将多行写入转成一行写入。在性能提升的同时,结合半结构压缩,将数据进一步压缩 50%。当前版本仅支持 putgetscandelete 功能,其他接口暂不支持。

  • 稀疏向量类型

    早期版本对向量类型已经进行了全面的功能支持,这里的向量又可以称为密集向量。密集向量通常表示为连续数组,其中每个位置都有一个值(例如 [0.3, 0.8, 0.2, 0.3, 0.1])。与之对应的弈中向量类型是稀疏向量,稀疏向量是高维向量的一种特殊表示,其中大多数元素为零,只有少数维度具有非零值。稀疏向量仅存储非零元素及其索引,通常表示为键值对(例如 [{2: 0.2}, ..., {9997: 0.5}, {9999: 0.7}])。这种表示方式在处理极高维数据时大大减少了存储空间,在处理大规模、高维但稀疏的数据时也有很高的计算效率。OceanBase 数据库在 V4.3.5 BP2 版本新增支持稀疏向量类型,并支持稀疏向量类型之间进行 inner_product/negative_inner_product 距离计算。同时支持对稀疏向量列创建索引,且稀疏向量索引支持与标量过滤一起查询,计划自动选择是走 pre filter,还是 post filter。

  • HNSW_BQ 向量索引

    新增 HNSW_BQ 向量索引类型。在 HNSW 索引算法基础上,引入了 BQ 量化算法,以少量的精度损失换来更少的存储和更快的计算效率。仅支持 L2 距离计算。

  • 带有向量索引/全文索引/多值索引的表支持 Offline DDL

    新版本开始支持对带有向量索引/全文索引/多值索引的表做除分区交换和分区分裂外的所有 Offline DDL。

  • 系统诊断能力增强

    新版本重新组织 ASH Report 的展现内容,增强报告的易读性;结合 WR 数据,提供更长周期的性能报告生成能力。新增 IO 读写次数和累计读写文件大小等指标采集,增加事务语句执行数量和时间的信息统计,提升 IO 和事务问...

Read more

v4.3.5_CE_BP1_HF1

29 Apr 11:17
Compare
Choose a tag to compare

版本信息

项目 描述
发布日期 2025-04-30
版本号 V4.3.5_CE_BP1_HF1
Commit 号 0c7ffd3
RPM 版本号 oceanbase-ce-4.3.5.1-101010042025042417

缺陷修复

  • 修复部分向量场景下的查询问题和升级兼容性问题。
  • 修复部分使用 HNSW_SQ 索引时可能存在的内存问题。
  • 修复 ARM 环境的宽表场景下,CPU 原子操作容易成为热点的性能问题。
  • 修复部分全文索引场景下的内存膨胀和 core 问题。
  • 修复部分 LOB 场景下,回放慢导致合并卡的问题。
  • 修复 SELECT INTO 导出到 s3 报错 4016 的问题。
  • 修复物化视图增量刷新导致 CPU 负载高的问题。
  • 修复部分外表场景下的兼容性问题和报错问题。

v4.2.5_CE_BP3

02 Apr 11:53
Compare
Choose a tag to compare

版本信息

项目 描述
发布日期 2025-04-03
版本号 V4.2.5_CE_BP3
Commit 号 35332d1
OBServer RPM 版本号 oceanbase-ce-4.2.5.3-103000022025033117

功能增强

  • 高 TPS 场景 I/O 优化

    对事务数据表的回收策略进行优化,在高 TPS 场景下可显著降低 I/O 负载。

  • 备份速度优化

    通过支持并行补偿日志,加快备份速度。

  • 关联 UPDATE 场景下的 DML 语句执行速度优化

    扩展 PDML 的支持范围,实现对包含关联子查询的 Update 语句的并行处理,从而显著提升此类 DML 操作的执行效率。

  • MySQL 模式外键功能优化

    MySQL 模式下新增支持外键引用存在非唯一索引的列,并放宽父键与子键的类型约束,同时禁用了外键环状自引用级联的更新场景。

  • 诊断能力增强

    从用户的易读性、采集的稳定性、采集时的性能、采集指标的丰富程度以及采集数据的时间跨度等多方面对诊断能力进行了一系列的优化与增强。

    • ASH REPORT 可读性增强

      根据多重维度重构了 ASH REPORT 的展现,包括租户、节点、Top SQL 等维度,帮助用户更好的了解 OceanBase 数据库的运行状态。除此之外,ASH REPORT 还结合了从 WR 仓库中获取已持久化的 ASH 数据,为用户生成更长时间周期的报告。

    • 新增 I/O 诊断能力

      ASH 新增 I/O 相关参数的采集和配套的视图,提供了监测 ASH 采样的 I/O 读写次数和累计读写文件大小的能力。

    • ASH 采集 SQL 能力增强

      引入了新的 Feedback 机制,使 ASH 可以采集到之前版本无法采集的 SQL 语句,包括在采样点时刻处于解释阶段的 SQL 语句、优化阶段的 SQL 语句和跨级传输的反序列化阶段的 SQL 语句。

    • 新增事务相关的信息统计

      可以通过 [G]V$SYSSTAT 监控 COMMIT 和 ROLLBACK 语句的执行数量和执行时间。

    • 稳定性增强与性能优化

      在 Intel CPU 的机器上结合主频做时间采集以提供更精准的时间采集功能、解决部分指标未被正确采集、ASH REPORT 弹窗展示宽度自适应等稳定性问题;降低 RPC 协议路径下的内存分配开销。

    • SQL 计划查询能力增强

      DBMS_XPLAN 包中的 DISPLAY_CURSOR 函数和 DISPLAY_SQL_PLAN_BASELINE 函数在 [G]V$OB_SQL_PLAN 表中的数据为空的情况下,可以在 WR 仓库中查询已保存的历史计划。

产品行为变更

  • DBMS_XPLAN 包在视图 [G]V$OB_SQL_PLAN 中查询不到计划时,会使用视图 DBA_WR_SQL_PLAN 中的数据进行查询。

  • 指定备份路径到对象存储的场景下,支持更改备份目的端不重新输入 Access key 和 Secret key。

视图变更

视图 变更类型 变更说明
CDB/DBA_WR_ACTIVE_SESSION_HISTORY 新增列 新增字段 DELTA_READ_IO_REQUESTSDELTA_READ_IO_BYTESDELTA_WRITE_IO_REQUESTSDELTA_WRITE_IO_BYTES 用于描述两次采样点之间的读写次数和读写文件累计大小。
CDB/DBA_OB_TABLE_SPACE_USAGE 新增 表级存储容量视图,用于展示所有用户表(多副本环境下以 Leader 副本为准)的大小。

配置项变更

配置项 变更类型 变更说明
temporary_file_max_disk_size 新增 新增租户级配置项,用于设置租户的单个节点内临时文件最大可占用的磁盘空间大小。

升级说明

  • 支持 V4.2.1_CE_BP10 及之前的 V4.2.1_CE 版本先经停 V4.2.1_CE_BP11 版本后再直接升级到 V4.2.5_CE_BP3 版本。
  • V4.2.2_CE 版本需先经停 V4.2.2_CE_BP1 版本后再升级到 V4.2.5_CE_BP3 版本。
  • V4.2.3_CE/V4.2.4_CE/V4.2.5_CE 版本可以直接升级到 V4.2.5_CE_BP3 版本。

缺陷修复

v4.2.1_CE_BP11

01 Apr 06:17
Compare
Choose a tag to compare

Version information

Information Description
Release date 2025-04-01
Version V4.2.1_CE_BP11
Commit ID 6605612
RPM version oceanbase-ce-4.2.1.11-111000162025032610

Feature and stability enhancements

  • Support for specifying backup or archive source nodes

    OceanBase Database is commonly deployed in configurations such as three IDCs in one region, three IDCs across two regions, or five IDCs across three regions. In these deployment modes, cross-data-center and cross-region network bandwidth resources are typically more limited than local bandwidth. Database backups generate significant network traffic. To manage the usage of scarce network bandwidth resources during backups, the new version introduces options to configure paths for data backup and log archiving. You can specify the zones, IDCs, and regions of accessible paths to define the range of nodes available for backup and archiving.

  • Pre-expansion

    This release introduced the concept of an "expansion factor", which defines the number of log streams that a single log stream will be split into. Additionally, new log stream maintenance commands are provided to adjust the location and primary_zone settings of a log stream, laying the groundwork for future cluster expansions.

Syntax changes

Syntax Description
Added the syntax for specifying the source of tasks for backup or archiving
  • The data_backup_dest and log_archive_dest parameters can be configured at the zone, region, and IDC levels.
  • Syntax: `ALTER SYSTEM {alter
Added the syntax for modifying the attributes of log streams
  • A maintenance command for log streams is added, which allows you to change the location and primary zone of a log stream.
  • Syntax: ALTER SYSTEM MODIFY LS $ls_id [UNIT_GROUP $unit_group_id] [PRIMARY_ZONE '$zone_name'] [TENANT = '$tenant_name'];

Bug fixes

版本信息

项目 描述
发布日期 2025-04-01
版本号 V4.2.1_CE_BP11
Commit 号 6605612
RPM 版本号 oceanbase-ce-4.2.1.11-111000162025032610

功能及稳定性增强

  • 支持指定备份/归档源端

    OceanBase 集群常见的部署模式包括同城三中心、两地三中心和三地五中心等,这些模式下,跨机房和跨地域的网络带宽资源通常比本地带宽更加稀缺。数据库备份过程往往会产生大量的网络流量,为了控制备份对稀缺网络带宽的占用,新版本提供了数据备份及日志归档的路径配置选项,通过配置可访问路径的 zone、idc 和 region,指定可用于数据备份和归档的节点范围。使用说明见备份路径和归档路径源端配置案例

  • 预扩容

    引入扩容系数概念,定义了一个日志流需要拆分出的日志流个数,同时新增日志流运维命令,修改日志流的位置和 primary_zone 信息,为扩容做前期准备。

语法变更

语法 变更说明
新增备份归档限制可执行任务源端的语法
  • data_backup_dest/log_archive_dest 配置项支持 zone/region/idc 三个层级的配置。
  • 语法:`ALTER SYSTEM {alter
新增修改日志流属性的语法
  • 新增日志流运维命令,修改日志流的位置和 primary_zone 信息。
  • 语法:ALTER SYSTEM MODIFY LS $ls_id [UNIT_GROUP $unit_group_id] [PRIMARY_ZONE '$zone_name'] [TENANT = '$tenant_name'];

缺陷修复

v4.3.5_CE_BP1

21 Mar 07:46
Compare
Choose a tag to compare

Version information

Information Description
Release date March 21, 2025
Version V4.3.5_CE_BP1
Commit ID b6d5706
RPM version oceanbase-ce-4.3.5.1-101000042025031818

Upgrade notes

  • Upgrades from V4.3.x to V4.3.5 BP1 are supported.
  • Upgrades from the V4.2.x series or earlier versions to V4.3.5 BP1 are not supported.
  • Starting with V4.3.2, the persistence format for multi-source data was restructured. During the upgrade process, the system needs to convert between the old and new multi-source data formats. If there are many partitions, ensure sufficient time is reserved for the upgrade.

Feature enhancements

  • Heap-organized table mode

    OceanBase Database adopts a clustered index table model, which performs exceptionally well in OLTP environments. This model stores the primary key and main table data in the same table, optimizing primary key query speed and unique value verification performance. However, it has certain limitations in OLAP scenarios that require efficient data import and complex data analysis. The import process necessitates sorting the entire dataset, and queries must involve primary key row merging, both of which impact performance. The new version introduces support for the heap-organized table mode. In this mode, the primary key is used for uniqueness constraints, while queries rely on the main table. When user data is sorted by time, skip indexes can be leveraged to enhance query efficiency. Furthermore, by decoupling the primary key from the data, the need to sort main table data during the import process is eliminated, significantly improving data import performance.

  • Support for the STRING data type

    Some analytical processing (AP) workloads are more tolerant of column lengths and often use variable-length strings to store data, which may also need to serve as primary keys or index keys. In OceanBase Database, the CHAR and VARCHAR types can store strings and be used as primary keys or index keys, but their lengths must be explicitly specified. The MEDIUMTEXT and TEXT LOB types can store variable-length strings but cannot serve as primary keys or index keys. To better meet the requirements of AP workloads, the STRING data type has been introduced. This type does not require a specified length and defaults to a maximum length of 16 MB. Columns of this type can be used as primary keys or index keys if their length is less than 16 KB and does not exceed the lob_inrow_threshold.

  • Optimization of vector indexes

    Since V4.3.3, OceanBase Database has supported HNSW indexes. These graph-based vector indexes provide excellent indexing performance but require resident memory, leading to high costs. When the data volume becomes large, it is challenging to store the entire index in memory. The new version introduces HNSW_SQ indexes, which maintain similar construction speeds, query performance, and recall rates as HNSW indexes but reduce overall memory usage to just 1/3 to 1/4 of the original. This makes HNSW_SQ indexes well-suited for scenarios with high performance and recall rate requirements. Additionally, the new version supports IVF indexes, which do not require resident memory. These are ideal for scenarios with large data volumes, lower performance requirements, and higher cost sensitivity. Furthermore, the new version enhances vector query capabilities with filtering conditions, achieving a 40% improvement in vector index performance for partitioned table scenarios. It also allows users to create both vector and full-text indexes on the same table.

  • Performance and resource optimization for table-level restore

    The table-level restore process consists of three steps: physical restore of the auxiliary tenant, cross-tenant table import, and auxiliary tenant cleanup. Currently, the physical restore of the auxiliary tenant uses a full restore method, which restores all data from backup media to the auxiliary tenant. This approach introduces the following two issues:

    1. Users must reserve sufficient CPU, memory, and disk resources in the cluster to support the temporary auxiliary tenant restore.
    2. Restoring all data from backup media to the auxiliary tenant consumes significant time and network bandwidth.

    The new version optimizes the physical restore mechanism for the auxiliary tenant, replacing the full restore method with a quick restore approach. This reduces the disk resources required for the temporary auxiliary tenant during table-level restore, shortens the auxiliary tenant restore time by an order of magnitude, and significantly improves table-level restore performance.

  • Support for incremental direct load for heap tables with unique indexes

    Direct load is divided into full direct load and incremental direct load. When data already exists in the table, incremental direct load performs better than full direct load. Previously, incremental direct load did not support importing data into heap tables with unique indexes. The new version introduces support for importing data into heap tables with a local unique index using incremental direct load.

  • Support for HASH partitioning and concurrent partition import in direct load

    Starting from V4.3.5 BP1, HASH partitioning is supported for partition-level direct load. Incremental direct load now supports concurrent imports across multiple partitions. However, partition parallel import is not supported when multiple import tasks involve overlapping partitions.

  • Performance optimization for direct load

    Through vectorization optimizations, streamlined temporary file processes, and stage-by-stage computing performance enhancements, the import performance for clickbench tables has been improved by 17% compared with V4.3.5.

  • Tenant-level disaster recovery

    All changes related to replicas, such as permanently removing members, adding or deleting replicas due to locality changes, and replica or unit migration during scaling or failover, are currently managed by the disaster recovery (DR) module of the Root Service (RS). If the DR service of the RS encounters a failure, it may impact the disaster recovery needs of all tenants. In the new version, the disaster recovery service has been split into individual services for each tenant, allowing each tenant to independently manage its own disaster recovery. This eliminates mutual interference between the RS and tenants or among tenants themselves.

  • Decoupling of parameter modifications and some DDL operations from RS status

In the new version, modifications of parameters and the execution of certain DDL operations (such as CREATE/ALTER/DROP DATABASE, CREATE/CREATE_LIKE/ALTER/DROP/RENAME/TRUNCATE TABLE, CREATE/DROP/UPDATE STATUS INDEX, as well as operations on TABLEGROUP, TRIGGER, PACKAGE, SYNONYM, and OUTLINE) have been decoupled from the status of the RootService (RS). These operations no longer depend on the leadership or availability of the RS. This allows system and tenant parameter modifications to proceed even when the RS is unable to provide services, without affecting common DDL statements used by users, thereby improving system availability.

  • Enhanced DDL performance diagnostics capability

    Offline DDL operations often take a long time to complete. To facilitate the diagnosis of performance issues during DDL execution and provide better visibility into DDL execution progress, the new version enriches the output information of the [G]V$SESSION_LONGOPS view. It now includes details such as the number of rows processed by operators, processing progress, and the estimated time of completion.

  • Support for adding subpartitions

    When subpartitions are created using the RANGE [COLUMNS] or LIST [COLUMNS] partitioning method, new rows cannot be inserted once the data exceeds the upper boundary of the initially defined maximum partition. Without support for dynamic subpartition addition, the only solution is to rebuild the table, which introduces significant operational challenges. The new version introduces syntax for adding and dropping subpartitions, improving the usability and flexibility of partition management.

  • Optimization of statistics collection

    The new version introduces targeted adaptations for columnstore statistics to improve the performance of statistics collection for columnstore tables. It also implements a progressive automatic statistics collection strategy: when a table has many partitions, statistics collection is batched at the partition level. Additionally, a failure marking mechanism has been introduced for asynchronous statistics collection. If statistics collection for a large table fails three times, no further asynchronous collection scheduling will be performed for that table, preventing a single large table from blocking the entire collection window.

  • Decoupling of PX compute nodes and data nodes

    In the current system architecture, storage resources and compute resources are tightly coupled. The existing PX scheduling mechanism assigns tasks for non-leaf DFOs only to machines where the data is located, which can limit the full utilization of machine resources in certain scenarios. To allow large SQL queries to leverage more machines for computation, the new version supports the decoupling of PX compute nodes and data nodes. You can specify a candidate resource pool for non-leaf DFOs through configuration options or the PX_NODE_POLICY hint. Additionally, hints such as PX_NODE_ADDRS and PX_NODE_COUNT can be used to explicitly specify the exact machines or the number of machines for task allocation to non-leaf DFOs.

  • Performance optimization for CAST, IN, and logical expressions

    In columnar storage scenarios, the new version achi...

Read more

v4.2.5_CE_BP2_HF1

28 Feb 05:59
Compare
Choose a tag to compare

版本信息

项目 描述
发布日期 2025-2-28
版本号 V4.2.5_CE_BP2_HF1
Commit 号 ddf7890
OBServer RPM 版本号 oceanbase-ce-4.2.5.2-102010012025022610

缺陷修复

周边配套

在 OBKV 场景下,需要搭配 OBKV-Table 客户端 V1.4.1 及之后版本使用。

v4.2.1_CE_BP10_HF1