亡羊补牢
先补一个迟（yí）来（lòu）的 V4.3.5_CE 版本的产品发布信息。
V4.3.5_CE
版本信息
- 版本号：V4.3.5_CE
- RPM 版本号：oceanbase-ce-4.3.5.0-100000202024123117
版本概览
OceanBase 数据库 V4.3.5 是面向 AP 场景第一个 LTS 版本。在 V4.3.4 的基础上，新版本继续完善产品能力，新增了对嵌套物化视图的支持，并完善了全文索引和向量索引功能。此外，数据导入导出的能力也得到了增强：支持指定分区旁路导入、外表支持读取 ORC 格式文件，以及 SELECT INTO OUTFILE 现在支持导出 Parquet 和 ORC 格式。优化器能力的增强包括基于基线优先策略的 SPM 演进、优化器估行系统的改进、递归公用表表达式 (CTE) 的抽取与 INLINE 代价验证优化，此外，对 Query Range 提取能力也进行了强化。
在性能优化方面，V4.3.5 对表级恢复性能、旁路导入性能、DML 性能以及 DDL 性能都做了不同程度的优化，新版本不仅支持行存与列存的在线转换，还实现了快速中间加列，并且扩展了并行 DDL 操作。同时，通过将统计信息和 CLOG 日志提交集成到资源隔离机制中，并实现了 IO 层级的隔离，进一步增强了 OceanBase 数据库的资源隔离机制。此外，新版本还支持 SQL 级别的内存使用限制，并优化了存储过程的内存使用，以及通过共享线程池来减少租户的内存资源消耗，提升了多种场景下的稳定性。在易用性方面，对 ASH 和 WR 的诊断能力做了增强，支持日志流副本并行迁移优化，以及通过实现日志传输链路的监控视图来增强日志同步链路的可观测性，让 OceanBase 数据库更加好用。新版本支持了更丰富的 ARRAY 和 XML 表达式，对 JSON/XML/GIS 类型数据执行过程中内存占用进行了优化。同时对 OBKV-HBase 和 HBase 的兼容能力做了增强，并支持了 OBKV 的 P95/P99 指标观测。
关键特性说明
内核增强
-
支持嵌套物化视图V4.3.5 之前的版本只支持在普通用户表上构建物化视图，而在数据仓库场景下，会使用物化视图来做数据加工，为了支持好轻量级实时数仓场景，V4.3.5 版本支持基于已有物化视图创建新的物化视图，即嵌套物化视图。嵌套物化视图所支持的刷新方式和非嵌套物化视图一样，都包括全量与增量刷新，所以 V4.3.5 支持基于物化视图创建物化视图日志。嵌套物化视图中数据的新鲜度与基表数据的新鲜度有关，为了保证上层物化视图数据的新鲜度，需要用户先刷新底层的物化视图。
-
支持指定分区旁路导入在 V4.3.5 版本之前 OBServer 仅支持整表数据导入走旁路导入路径，从而加速导入。如果用户想要只导入部分分区的数据，可以通过分区交换的方式，即先通过全量旁路导入将分区的数据导入到非分区表中，然后将对应非分区表与目标分区做分区交换，这个操作对用户来说比较麻烦。为了更好的支持分区级的数据导入，V4.3.5 支持
LOAD DATA和INSERT INTO SELECT语法指定分区走旁路导入路径，不过不支持指定最后一级分区类型为 Hash/Key 的分区。 -
全文索引功能增强V4.3.5 在 V4.3.4 的基础上对全文索引功能持续做了功能完善，主要包括：
- 支持通过
CREATE FULLTEXT INDEX或ALTER TABLE ADD FULLTEXT INDEX语句后建全文索引。 - 支持基于代价的全文索引计划选择，对于存在包含
MATCH AGAINST的多个 filter（过滤）的 SQL，支持根据代价选择开销较小的索引进行扫描。 - 支持 Functional Lookup：
- 支持查询语句中包含多个
MATCH AGAINST表达式。 - 支持走全文索引的同时走其他索引。
- 支持不含 filter 语义的
MATCH AGAINST作为投影列进行输出。 - 支持 filter 语义的
MATCH AGAINST使用 <=/< 等符号进行过滤。 - 支持 filter 语义的
MATCH AGAINST，和其他 filter 语义的逻辑进行 AND/OR 链接。
- 支持查询语句中包含多个
- 支持通过
-
SELECT INTO OUTFILE 功能增强V4.3.5 对
SELECT INTO导出功能进行了完善，支持了SELECT INTO导出 Parquet 和 ORC 类型，支持了SELECT INTO导出 CSV 类型时指定压缩算法，为SELECT INTO增加了新语法。- 使用 format 语法设置导出选项。
- 导出 CSV 格式文件指定压缩算法。
- 导出 Parquet 格式文件。
- 导出 ORC 格式文件。
-
外表增强在 V4.3.5 版本中，外表支持读 ORC 格式文件。
-
LOAD DATA 普通导入支持目录导入以及通配符匹配文件V4.3.0 已支持
LOAD DATA走旁路导入时支持通配符匹配文件，而普通导入只支持单个文件导入，当有多个文件需要导入时，需要写多条LOAD DATA语句。V4.3.5 支持普通导入的多文件导入，同旁路导入一样，支持逗号分隔多文件与通配符多文件描述格式。 -
通过 Hint 控制 Hash/NL CONNECT BY在
CONNECT BY层次查询中，可以选择两种连接方式：Nest-Loop Join 和 Hash Join。目前，系统根据规则自动选择连接方式，只有在没有可用索引时才会选用 Hash Join。然而，在某些情况下，即使存在索引，Hash Join 仍然可能是更优的选择。在 V4.3.5 版本中，可以通过 use_hash Hint 来手动控制层次查询使用 Nest-Loop Join 还是 Hash Join，同时也可以绑定 Outline 进行更精确的调整。 -
ALTER SEQUENCE 正确性治理SEQUENCE 的执行需要内部表和本地的 Cache 配合来执行，内部表确保全局生成的值是唯一的，而本地 Cache 用于加速生成值。在
ALTER SEQUENCE时如果不清除本地缓存，会导致本地缓存与 SEQUENCE 参数不一致，使用新的参数在老的缓存上取值，容易出现正确性问题。为了解决这一类问题，OceanBase V4.3.5 版本支持在ALTER SEQUENCE时清除本地缓存，并把缓存中剩余的值同步回内部表，以减少序列值空洞。 -
全局索引绑定主表 SHARDING = NONE 表组V4.3.4 之前的版本，全局索引没有加入表组，绑定了表组的主表和其全局索引不保证在一个节点。V4.3.5 开始和全局索引相关的 DDL 操作如
CREATE TABLE、CREATE TABLE LIKE、CREATE INDEX、ALTER TABLE ADD INDEX、TRUNCATE TABLE、TRUNCATE PARTITION等，如果主表在SHARDING = NONE的表组，强制要求全局索引表的分布和主表一致。同时如果通过ALTER TABLE语句将主表放进了SHARDING = NONE的表组，则全局索引表会绑定主表进行表组对齐。 -
Query Range 抽取能力强化V4.3.5 实现了新版 Query Range 抽取逻辑，扩展了谓词下压场景，使向量形式谓词的 Range 抽取更加精准，也解决了旧版 Query Range 的一些内存放大的场景问题。除了优化 Range 抽取性能，同时也增强了 Range 抽取能力。如：修改了
NOT IN表达式生成 Query Range 的方式，优化了 Range 抽取性能；支持 Range Graph 裁剪，减少最终 Query Range 的抽取数量，降低内存消耗；扩展 Index Hint；支持 Interesting Ordering 索引路径按规则裁剪，LIMIT重计算等策略优化，解决ORDER BY LIMIT场景因计划选择不优导致的性能问题；支持对空间类型列的 Range 抽取，增加了隐式转换的支持以及在 Nest-Loop Join Rescan 场景抽取快速路径的支持；同时 Query Range 裁剪对接了代价模型，根据代价来选择 Query Range 应该抽取到第几列以及抽取的 Query Range 的范围；支持含有 exec_param 的常量抽取、NVL 表达式抽取。 -
优化器估行系统改进优化器代价估计依赖对每个算子的准确估行，准确估行则依赖估计策略选择和统计信息的准确性。V4.3.5 对在已有能力的基础上对估行系统进行了进一步强化，提升了估行系统在部分场景下的准确性：
- 通过界定包含多种类型的连接条件或涉及多张表的环状连接等复杂连接的选择率下界，设定当
INNER/OUTER JOIN的连接条件复杂时，小表的每一行都至少连接大表一行，即选择率不低于大表当前行数分之一，解决环状连接估行过小的问题。 - 通过修正连接在 filter 后的行数，提高连接行数估算的准确性。
- 对于带有谓词过滤的基于
t1和t2的ANTI JOIN查询，对于t1上的谓词带有较强过滤性的场景，将基于简单包含的假设调整为基础包含假设，提升该场景下的估行准确性。
- 通过界定包含多种类型的连接条件或涉及多张表的环状连接等复杂连接的选择率下界，设定当
-
CTE 抽取/INLINE 代价验证改进CTE 的抽取和 INLINE 是我们在处理公共计算模块时的两种选择。CTE 抽取将 CTE 的计算结果物化下来（
WITH子句），使用时直接引用其计算结果。CTE INLINE 不物化 CTE 的计算结果，各自在使用的上下文中进行计算。V4.3.5 抽象了一个公共的 INLINE/MATERIALIZE 代价验证模块，加强 CTE INLINE 的代价验证，提升了局部代价验证的准确性。 -
基线优先的 SPM 演进V4.3.4 及之前版本 SPM 演进采用的是在线演进的方案。即当新的计划出现时，总是立即与基线计划演进，当演进验证新计划是优于基线的计划（以计划执行的平均 CPU 时间判断）的情况下，会使用新的计划并把新计划也记为基线计划。在线演进的方式能解决大多数计划走偏问题，但是也遇到了一些 bad case。典型的场景是新计划产生的时候刚好数据量很小，在这个场景下 SPM 会误判新的计划比老计划要好。一旦当数据量激增，新生成的计划就不再适用。V4.3.5 新增了一种优先使用基线计划的 SPM 演进模式。在这个模式下优化器总是会使用基线计划，除非所有的基线都无法还原。在这个模式下，所有的基线都会被认为是 Fixed。
-
代价走偏率和耗时改进查询改写规则分为规则改写和代价改写两大类。不同于规则改写，代价改写后的结果并不是对所有场景都是最优的，通常和数据分布以及是否有合适的索引相关。因此，和规则改写相比，代价改写额外多了代价验证的过程。代价验证的不完善引入了两个代价改写最主要的问题：硬解析耗时高和改写走偏。V4.3.5 通过优化单次代价验证耗时以及给代价改写的尝试次数增加兜底机制，降低代价改写耗时。同时解决了分组上拉、or 展开和分组下压三种场景代价改写走偏的问题。
-
DAS 路径选择优化本特性扩大了 batch rescan 的支持范围，优化了 batch rescan 的代价计算方式，针对 batch rescan 添加了基于规则的计划裁剪。同时调整了 rescan 计划 DAS 路径生成策略以及 DAS rescan 路径代价计算方式，具体为对 DAS rescan 过程的 RPC 开销进行了拟合，调整 DAS 动态分区裁减代价计算，从而让优化器能够选择更优的执行计划。
-
Union Parser 优化及 Explain 参数化展示为了解决一些复杂查询的硬解析过程耗时占比高导致业务硬解析超时的问题，V4.3.5 针对表达式 same_as 和 equal sets 相关接口做了优化，降低硬解析耗时。且在 V4.3.5 版本中，通过新增报错检查或者 explain 信息来及时暴露如：非参数化和参数化的计划不一致、约束错误或者约束膨胀、改写不收敛等一系列问题，来提升解析和改写的质量。
-
优化器功能优化V4.3.5 为了让生成的执行计划更优，对 SQL 优化器功能做了如下的优化：
- 包含窗口函数的查询下推
GROUP BY。 -
GROUP BY下推至UNION ALL内部。 -
RUNTIME FILTER的分配策略优化。 -
SUM聚合改写。 - 重复值不敏感判定。
-
HASH INTERSECT DISTINCT计划下推DISTINCT。 -
DISTINCT聚合改写。
- 包含窗口函数的查询下推
-
自动分区分裂V4.3.4 版本支持的自动分区分裂功能为实验特性，在 V4.3.5 版本中对此功能做了稳定性增强，在 V4.3.5 此功能已达到 GA 要求。
-
只读列存副本V4.3.3 版本支持的只读列存副本功能为实验特性，经过 V4.3.4 和 V4.3.5 版本的迭代，在 V4.3.5 此功能已达到 GA 要求。
MySQL 兼容
-
Latin1 字符序完善V4.1 开始支持
Latin1字符集，提供了latin1_swedish_ci、latin1_bin字符序的支持。为了更好的兼容 MySQL，V4.3.5 扩展了Latin1字符序的支持范围，新增latin1_german1_ci、latin1_danish_ci、latin1_german2_ci、latin1_general_ci、latin1_general_cs以及latin1_spanish_ci字符序。 -
SELECT … FOR UPDATE SKIP LOCKED 功能V4.3.5 兼容支持 MySQL
SELECT ... FOR UPDATE SKIP LOCKED语法，表示存在锁冲突时不等待，跳过被其他事务锁定的行，立即执行查询返回结果。 -
Enum/Set 类型重构Enum 和 Set 类型通常用来存储有限种类的字符串，不仅能够节省存储空间，还提高了数据的处理效率。Enum 和 Set 类型存储时使用数值表示，创建类型时则配以字符数组来解释数据。当前特性对 Enum/Set 类型的元信息存储进行了重构。通过在 subschema ctx 中保存复杂的字符数组信息，减少了开发者对 Enum/Set 元信息传递的关注度。此外，通用化的类型转换逻辑使得 Enum/Set 类型的类型推导更为简单和高效。
-
中间快速加列V4.3.5 将中间加列的 DDL 操作从 Offline DDL 改为 Online DDL，提升了中间加列的性能。支持中间
ADD COLUMN以及中间ADD COLUMN与MODIFY COLUMN复合两种场景的 Online DDL。
性能提升
-
下压谓词 filter 排序目前，OceanBase 的 SQL 层在处理 filter 排序时依赖的是估计值，而未能利用实时信息。此外，存储层在处理下压谓词 filter 的排序时同样没有利用实时信息，这可能导致查询性能不佳。在 V4.3.5 版本中，支持了在存储层收集与 filter 相关的实时统计信息（例如 filter 执行的开销和过滤的行数），并基于这些实时统计信息对 filter 进行重排序，从而优化查询性能。
-
行存转列存操作支持异步 Online DDLV4.3.0 版本支持了三种表存储格式：行存、纯列存和行列混存。将行存表转换为行列混存表或列存表的操作为 Offline DDL，可能会对客户造成影响。为此，V4.3.5 版本支持行存表异步转换为列存表，实现 Online DDL。用户在执行 DDL 语句时只需指定关键字
delayed，即可实时修改表的 Schema 信息，而不会阻塞数据写入。此外，列存的基线数据重整将在基线数据合并时异步执行。V4.3.5 版本现已支持将行存表转换为列存表和行列混存表的 Online DDL。 -
旁路导入写入路径向量化在 V4.3.5 版本之前，旁路导入的实现并未进行向量化，写入的函数均按行处理，导致函数调用开销较大。此外，写 SSTable 的过程是后台执行的，缺乏针对性的优化措施。V4.3.5 版本针对旁路导入路径进行了向量化，同时优化了列存 encoding，从而提升了旁路导入的性能。经过验证，无主键列存表的旁路导入性能提升约为 2 倍。
-
DML 性能优化OceanBase 已经支持通过 PDML 的并行执行机制来提高对大型表和索引执行插入、更新、删除等操作的性能。但是仍然存在部分场景是 PDML 暂未覆盖的，如
REPLACE INTO ...、INSERT ... ON DUPLICATE KEY、INSERT ALL ...、MERGE INTO ...更新主键、INSERT包含自增列、多表UPDATE等。以上场景在之前版本会使用单线程写入方式，在数据量较大时响应时间较长，影响客户体验。为了解决大数据量的这些场景的性能瓶颈，V4.3.5 版本新增支持 DAS 层并发写入能力，通过类似 PDML 的并发控制机制，显著提升 DML 执行性能。并且对INSERT ... VALUES ... ON DUPLICATE KEY UPDATE ...和REPLACE ... VALUES ...两类语句，支持 MULTI QUERY 场景下的BATCH处理，提升 DML 执行性能。同时MERGE INTO语句更新UNIQUE KEY支持 PDML，提升大数据量下场景下的执行效率。 -
Insertup/Replace 性能优化Insertup（指
INSERT ... VALUES ... ON DUPLICATE） 和 Replace（指REPLACE INTO ... VALUES ...）语句在 V4.x 版本中不会逐行做分区裁剪，因此涉及多 Tablet 写入的 SQL 会统一选用 DISTRIBUTED 执行计划，在语句执行前获取一次 GTS。小数据量入库场景下，尤其是存在较多主键/唯一键冲突时，GTS 获取操作会带来明显的性能损耗。新版本细化了写入场景，在写入表不涉及 Unique Global 索引或涉及 Unique Global 索引但写入数据位于同一日志流等场景，省略了 GTS 获取操作，优化了执行流程，显著提升 Insertup/Replace 性能。 -
表级恢复性能优化表级恢复整体流程分为以下三步骤：
- 第一步：先从备份数据中恢复出辅助租户到指定时间点（物理恢复）。
- 第二步：将指定的表从辅助租户跨租户导入到目标租户（跨租户导表）。
- 第三步：最后，清理辅助租户。在 V4.3.5 之前的版本，跨租户导表步骤流程里面表导入任务调度器的任务发送策略，限制了多个表导入任务只能串行执行。同时主表补数据阶段、索引重建阶段并行度都较低。为了提升表级恢复性能，V4.3.5 版本分别在跨租户导表的表导入任务发送阶段，主表补数据阶段和索引创建阶段进行了并行优化：
- 通过提供的租户配置项
recover_table_concurrency可以控制最大允许 K 个表的表导入任务同时执行，提升多表导入并行度。 - 利用 DDL 提供的表级恢复并行控制参数，提升索引创建的并发度。
可靠性提升
-
配置项及租户资源配置支持备份V4.3.5 版本支持了集群级以及租户级配置项的备份。集群级配置项可以通过
ALTER SYSTEM命令指定路径信息单独发起备份。租户级配置项会在包含在备份数据集中，执行数据备份时租户级配置项就会一起备份。执行租户级物理恢复时，建议目标租户的资源配置与源租户相同来有效的保证物理恢复的成功率以及后续生产业务的稳定性，为了给目标租户资源配置做参考，V4.3.5 版本还支持了备份租户的资源配置信息以及副本分布信息。 -
S3 对象存储访问新增参数 addressing_modelV4.3.0 版本开始支持 AWS S3 对象存储，并且支持兼容 S3 的对象存储，在 V4.3.5 之前 OceanBase 仅支持 virtual-hosted style 的地址格式，而很多自研对象存储厂商兼容S3协议时只支持了 path-style，导致一些兼容S3的对象存储无法通过 OceanBase 访问。V4.3.5 支持 S3 路径配置可选参数 addressing_model，可选参数值：virtual_hosted_style/path_style，让业务根据对象存储的实际兼容情况选择格式的模式来访问。
资源优化
-
IO manager 实现层次隔离OceanBcase 资源隔离的 IO 调度算法具备三个功能：保留带宽、共享带宽和限制带宽。目前，保留和限制带宽功能的表现非常出色，但共享带宽方面仍有改进空间。例如，小租户的大资源组在调度时可能优先于大租户的小资源组，这不利于真正实现无服务器架构。这是因为已有的调度方式是基于资源组的度，即将所有租户的资源组进行扁平化处理来分配 IO 资源。 因此，在 V4.3.5 版本中，调整可 IO 调度逻辑，实现了真正的 IO 资源共享。调度方式从资源组的平级调度改为系统 → 租户 → 资源组的树状层次调度。
-
通过共享线程池方式降低租户的内存资源消耗为满足 serverless 需求，需要优化 OBServer 线程数以降低资源消耗。在 V4.3.5 之前每个 ObTimer 实例都是一个线程，且每增加一个租户，都会新增几十个线程。而这些线程并不总是在工作，这就造成了一定程度的浪费。V4.3.5 通过支持 Timer 池化来解决线程数多的问题，即每个租户共享一个线程池，通过 timer 调度的任务，最终由该线程池中的线程来执行。Timer 线程池有动态伸缩能力，可以根据负载自适应伸缩线程数量。另外，对于非租户模块，共用一个全局的 Timer 线程池。
-
统计信息及clog日志提交接入资源隔离在高性能计算环境中，资源的合理分配与隔离对于确保系统稳定性和提升效率具有决定性作用。有效的资源隔离策略可以预防任务间的资源争夺和相互干扰，从而提升资源利用效率和整体服务质量。目前，OceanBase 已实现了通过租户 Unit 规格来配置 租户间的资源隔离，通过 resource manager 来配置租户内的资源隔离，涵盖了 CPU 和 IO 两大重要资源。为了降低后台任务对前台用户请求造成的影响，需要对租户内的后台任务进行隔离，此前大部分的后台任务已经接入资源隔离。V4.3.5 将统计信息收集及 clog 日志提交接入资源隔离，进一步强化了 OceanBase 的资源隔离机制，降低了后台任务对前台用户请求的影响。IO 资源隔离配置有 3 个参数
MIN_IOPS、MAX_IOPS、WEIGHT_IOPS，分别表示最小 IOPS，最大 IOPS 以及 IOPS 权重，IO 调度策略是优先满足MIN_IOPS，在不超过MAX_IOPS的情况下按照WEIGHT_IOPS进行调度。具体隔离策略如下：- 限制 clog 日志提交的
MAX_IOPS为 10，表示最大允许 10% 的 IOPS 用于 clog 日志提交。 - 限制统计信息收集的
MAX_IOPS为 20，表示最大允许 20% 的 IOPS 用于统计信息收集。 - 限制前台任务及统计信息收集
WEIGHT_IOPS。通过将前台任务的WEIGHT_IOPS默认值为 100，统计信息收集的WEIGHT_IOPS值为 20，按照权重的调度策略，前台任务的带宽与统计信息收集带宽的比应该是 5:1。需要注意的是后台资源隔离允许对 CPU 和 IO 进行隔离，CPU 隔离需要开启 cgroup 功能，但是即使没有开启 cgroup 功能，IO 隔离能力仍然能够生效。
- 限制 clog 日志提交的
-
SQL 级内存使用控制OceanBase V4.3.4 不支持追踪单条 SQL 查询过程中的内存使用情况，在一些大 SQL、烂 SQL 或者优化器计划生成不优等场景，可能因为单条 SQL 内存占用过高影响系统的整体稳定性。因此 OceanBase V4.3.5 支持追踪单条 SQL 查询过程中的内存使用情况，当内存使用超过一定阈值后也能采取一些操作，如终端执行报错或打印 WARN 日志提醒，从而预防 OOM 或者排查 OOM 原因。新增租户级配置项
query_memory_limit_percentage用于指定单个 SQL 可使用的租户内存百分比。 -
存储过程内存优化V4.3.5 将存储过程中使用的通用内存分配器替换为定制的存储过程内存分配器，不仅实现内存主动释放，还缩短了存储过程内存生命周期。同时优化了符号表设计、基础类型的内存使用、record 和数组复杂类型内存管理、表达式内存管理等逻辑，解决了多种场景的内存堆积问题、提升了存储过程内存使用的稳定性，同时提升了部分表达式计算的性能。
-
去掉 cgroup 生效需要重启集群的限制目前云上，cgroup 的开启和关闭都是在集群部署之后才修改，而 cgroup 的开启/关闭生效需要重启集群，会影响云上业务，V4.3.5 去掉了cgroup 生效需要重启集群的限制，保证业务的连续性。
-
锁冲突管理增强优化本地执行锁冲突管理，解除对兜底唤醒机制的依赖，消除不必要的等待延迟。将远程执行锁冲突纳入管理，通过源端主动探测和目标端唤醒通知相结合的方式，避免了远程执行多冲突盲目重试，降低远程锁冲突造成的 CPU、网络开销。在热点行场景，对于多个加锁方，尽可能按请求顺序进行唤醒，避免新请求插队导致老请求阻塞以及多个请求同时重试导致的 CPU 抖动，同时尽可能减少异常场景唤醒的延迟。
-
系统资源优化
- meta 租户和用户租户内存共享。解决大规格租户 meta 内存不够用、小规格租户 meta 租户内存利用率低的问题。
- OceanBase 常用线程池支持动态创建线程。线程数从静态设置方式更改为根据请求队列自适应增加或减少，同时将部分后台线程池修改为使用该线程池。
- 线程局部内存精简。通过去除不必要的线程局部变量、降低局部变量的内存占用，最小化局部变量的生命周期等措施降低线程局部内存使用。
安全强化
- 全面适配 Rocky linux 9 操作系统。
易用性提升
-
ASH 和 WR 的诊断能力增强OceanBase V4.2.1 版本开始支持了 WR（Workload Repository）框架，实现了对统计项等内部视图的持久化采集，并对 ASH 功能做了增强，通过分析 ASH 数据，我们可以方便定位到长时间等待事件、慢 SQL 语句、活动会话的资源利用率等问题，从而进行性能优化。在此基础上，V4.3.5 加强了 ASH 和 WR 的诊断能力，增加了更多的统计项、指标和诊断信息；支持了新的一些诊断框架：SQL STAT、分 SQL 类型的直方图统计等。这些功能特性显著增加了 OceanBase 的易用性。
-
日志流副本并行迁移优化在 V4.3.5 之前，对补副本和删副本等需要修改
paxos_replica_num的负载均衡任务，RS 层需要等到该日志流上一个成员变更结束，拿到准确的paxos_replica_num后，才能进行下一次任务的生成，因此限制了一个日志流的多个副本任务（例如迁移任务）只能串行执行。该限制导致部分负载均衡任务和运维操作效率较低。例如：用户同时迁移两个 zone 的两个 unit 时，位于这两个 unit 上的同一个日志流的两个副本需要顺序迁移，无法并行。从 V4.3.5 版本开始，支持一个日志流在不同 zone 上的副本可以并行迁移，可以加快扩缩容速度、提升负载均衡效率以及降低备库副本 rebuild 概率。同时主备租户对于日志流副本并行迁移的需求不同：主租户主要需求为 POC 场景时用于加速扩缩容速度，在常规使用时可能并不会开启并行迁移，这是因为多个副本同时迁移时拷贝数据量较大，有可能影响主副本的 IO 性能。备库对并行迁移是有强需求的，通过并行迁移可以有效降低备库副本 rebuild 概率。并行迁移优化提供租户级配置项replica_parallel_migration_mode用于控制日志流副本并行迁移功能模式。 -
主租户下游的日志同步链路（CDC/备租户）监控基于网络直连的主备租户在设计时考虑到主租户不感知备租户，因此主备租户之间没有 Connection 或者 Session 这样的概念，主库也不太好直接感知到备租户的状态；考虑到下游日志同步链路在请求日志时会占用主租户资源，而目前来说没有直观的办法来观测到主租户承载了多少下游同步链路的请求，因此也难以在主库上对下游的日志请求进行限制；本特性通过实现日志传输链路的监控视图来增强日志同步链路的可观测性。
OBKV/多模
-
Roaringbitmap 表达式性能优化-二阶段优化由于业务想用
rb_build_agg及rb_cardinality替换count distinct做 UV 计算。但是目前rb_build_agg未实现两阶段，在复杂查询中，无法重复利用并行，导致性能不够好。为此在 V4.3.5 支持rb_build_agg表达式两阶段聚合，以提高rb_build_agg性能。 -
Json 多值索引支持复杂 DMLV4.3.5 Json 多值索引完善了对复杂 DML 语句的支持，在
UPDATE、DELETE等语句中可以支持多值谓词，同时支持了带多值索引回表的复杂 DML。 -
支持更丰富的 ARRAY 表达式OceanBase 在 V4.3.3 版本中支持了
ARRAY数据类型，为了更好的支持业务对ARRAY类型的使用，在 V4.3.5 版本支持了更多的ARRAY表达式，以满足业务多元化业务场景的需求。新版本新增了array_append、array_distinct、arrayMap、array_remove、cardinality、element_at、array_contains_all、array_overlaps、array_to_string、array_to_string、array_agg、unnest、rb_build等ARRAY表达式。 -
向量索引功能增强在 V4.3.3 版本中支持了向量索引基础能力。为了更好的满足用户诉求，V4.3.5 版本除了对向量索引已有功能做了稳定性增强外，将向量索引支持的最大向量维度从 2000 维提高至 4096 维，并且新增支持了 cosine 距离算法，用户在随表建/后建索引时可以指定 cosine 距离算法，在执行
SELECT查询时可以指定cosine_distance表达式过滤条件。 -
OBKV-HBase 兼容增强OceanBase 在 V4.3.4 兼容了 Hbase 1.x 的大部分功能，V4.3.5 继续完善 Hbase 1.x/2.x 的兼容性，包括多 namespace 支持 /ColumnRangeFilter/ColumnValueFIlter/CheckAndMutateBuilder/ 混合 Batch/CheckAndMutateBuilder 等。
-
JSON/XML/GIS 内存优化V4.3.5 对 JSON 表达式执行过程中内存占用进行了优化，对 JSON 类型进行查询操作（
JSON_KEYS、JSON_LENGTH、JSON_SEARCH等）时，内存占用减少至 1 倍；对 JSON 类型进行输出操作（JSON_PRETTY、JSON_UNQUOTE等）时，内存占用减少至 3 倍左右。在插入更新 XML 和输出 XML 的场景也进行了内存优化。输出 XML 操作（GetClobVal、XmlCast等）内存占用减少到 2-3 倍左右；插入更新 XML（UpdateXml、InsertChildXml等）时减少了不必要的解析。V4.3.5 同时对 GIS 类型数据输入、输出以及部分查询场景进行了内存优化。GIS 输入（st_geomfromtext/st_geomfromwkb/st_geogfromtext/geometrycollection等）内存占用减少到 3 倍左右；GIS 输出（st_astext/st_aswkb等）内存占用减少到 1 倍左右；查询场景（st_crosses/st_overlaps/_st_touches等空间关系查询表达式、st_geometrytype/st_iscollection等 GIS 属性获取表达式）也明显降低了内存放大程度。 -
OBKV 响应时间统计直方图在 V4.3.4 版本响应时间直方图功能基础上，新版本在
[G]V$OB_QUERY_RESPONSE_TIME_HISTOGRAM系统视图中增加了 OBKV 相关的统计类别，包括TABLEAPI SELECT、TABLEAPI INSERT、TABLEAPI DELETE、TABLEAPI UPDATE、TABLEAPI REPLACE、TABLEAPI QUERY AND MUTATE、TABLEAPI OTHER、HBASE SCAN、HBASE PUT、HBASE DELETE、HBASE APPEND、HBASE INCREMENT、HBASE CHECK AND PUT、HBASE CHECK AND DELETE、HBASE HYBRID BATCH等。
周边配套
OceanBase 数据库 V4.3.5 推荐使用的平台工具版本如下:
| 组件 | 版本 |
|---|---|
| ODP | V4.3.2_BP1 |
| OCP | V4.3.3_BP1 |
| OBD | V3.0.1 |
| ODC | V4.3.2_BP2 |
| OBCDC | V4.3.5 |
| OMS | V4.2.7 |
| OBClient | V2.2.8 |
| LibOBClient | V2.2.8 |
升级说明
- 支持 V4.3.0 Beta 及之后小版本、V4.3.1 Beta 及之后小版本、V4.3.2 Beta Hotfix1 及之后小版本、V4.3.3 GA 及之后小版本、V4.3.4 GA 及之后小版本，平滑升级到 V4.3.5。
- 暂不支持 V4.2.x 系列或更低版本升级到 V4.3.5，随着版本演进，后续会增加 V4.2.x 到 V4.4.x 升级路径支持。
- 自 V4.3.2 重构了多源数据的持久化格式，升级过程中需要对新旧多源数据格式进行转换，在分区数较多时需要预留相对充足的升级时间。
