在10月23日举办的 OceanBase年度发布会 上，我们怀着激动之情，正式向大家宣布了 OceanBase 4.3.3 GA 版的正式发布，这也是OceanBase 为实时分析（AP）场景打造的首个GA版本。
2024 年初，我们推出了 4.3.0 版本，作为迈向实时分析的关键一步，**引入了基于 LSM-Tree 架构的列存引擎。**经过几十个用户真实场景的打磨验证，4.3.3 版本在 AP 性能和功能方面不断进步，通过一体化帮助用户在复杂的混合负载环境中获得更快的响应时间和更优的吞吐能力。
在 4.3.3 GA 版本中，我们实现了多项关键突破。针对多工作负载场景进行了大幅性能优化，特别是在 AP 关键特性方面取得了显著提升。我们对列存引擎进行了深入优化，并扩展了应用场景，包括列存表、列存索引、行列混存表和列存副本等。
此外，向量化引擎 2.0 的引入，以及对物化视图、外部表、RoaringBitmap 和 Array 等复杂类型的支持，使系统在处理多样化数据时更加灵活。新形态的列存副本实现了 TP 和 AP 负载的物理资源强隔离，确保系统在处理事务型负载时不受分析型负载的影响，尤其在实时数据分析和决策场景中保持高性能与稳定性。
经过实际基准测试，OceanBase 4.3.3 GA 版本在 TPC-H 1TB 数据集的查询性能从 4.3.0 版本的 99 秒提升至 60 秒，实现了 64% 的性能提升。该版本能够在不同业务场景下满足数据存储和分析的多样化需求，在海量数据分析时提供更短的响应时间和更高的吞吐能力。
在 AI 支持方面，**4.3.3 引入了向量检索能力，支持向量数据类型和向量索引，**结合强大的多模一体化及分布式存储能力，大幅简化 AI 应用技术栈，助力企业高效构建 AI 应用。
这一版本的发布标志着 OceanBase 在实时 AP 场景和 AI 向量融合一体化方面的重要进展。接下来，让我们深入探讨 OceanBase 4.3.3 GA 版本的主要特性和亮点：
- 列存
- 向量化引擎 2.0
- 物化视图
- 外部表
- 数据导入导出
- 复杂类型
- 向量检索
- 全文索引
- 可靠性提升
1、AP关键特性
（一）列存
在大规模数据复杂分析或海量数据即席查询场景中，列式存储是 AP 数据库的关键能力之一。列式存储是一种数据文件组织方式，区别于行式存储，它将表中的数据按照列进行物理排列。数据为列式存储时，分析场景可仅扫描用于查询计算的列数据，避免整行扫描，减少 IO 和内存等资源使用，提升计算速度。另外按列存储也天然具备更好的数据压缩条件，更易获得较高的压缩比，减少存储空间和网络传输带宽。
OceanBase 在 LSM-Tree 架构基础上扩展支持了列存引擎，一套代码一个架构一个 OBServer，实现列存和行存数据的存储一体化，兼顾 TP 和 AP 的请求性能。围绕列存引擎，在不同的业务场景也提供了几种不同的产品方案。
- 列存表：纯 AP 业务的推荐方案，具备更好的分析性能。在此基础上有高性能点查需求时，对应表上添加行存索引即可。
- 列存索引：针对 TP 业务，有少量分析需求时，可以考虑在行存表上，为分析涉及的若干列创建列存索引。
- 行列混存表：TP、AP 业务边界不清晰，一个业务内可能既有联机事务又有实时分析时，可以创建为行列混存表，优化器基于代价自动决策 SQL 使用行存还是列存。并可借由资源组实现 USER 或 SQL 级的资源隔离。
- 列存副本：HTAP 场景，有资源物理隔离诉求时，可以基于 TP 集群扩展独立的 Zone 存储只读列存副本。TP 业务访问行存 Zone，AP 分析以弱读方式访问列存 Zone。
（二）向量化引擎 2.0
OceanBase 在早期版本已经实现了基于 Uniform 数据描述方式的向量化引擎，性能较非向量化引擎有了明显提升，但在深度 AP 场景，还有一些性能上的不足。新版本实现了向量化引擎 2.0 版本，更改为 Column 数据格式描述，避免了 ObDatum 维护带来的内存使用、序列化和读写访问开销。基于数据格式描述重构，各项算子和表达式也进行了重新实现，显著提升大数据量计算性能。
（三）物化视图
物化视图（Materialized View）通过预计算和存储视图的查询结果，减少实时计算来提升查询性能，简化复杂查询逻辑，常用于快速报表生成和数据分析等场景。
因为物化视图需要存储查询结果集来优化查询性能，而物化视图与基础表之间存在数据依赖关系，每当基础表数据发生变动时，物化视图中的数据必须进行相应更新以保持同步，所以新版本也引入了物化视图刷新机制，包括全量刷新和增量刷新两种策略。全量刷新是一种较为直接的方式，每次执行刷新操作时，系统会重新执行物化视图对应的查询语句，完整地计算并覆盖原有的视图结果数据，这种方式适用于数据量相对较小的场景。相对来讲，增量刷新仅需处理自上次刷新以来发生变更的部分。为了实现精确的增量刷新，OceanBase 实现了类似 Oracle MLOG（Materialized View Log）的物化视图日志功能，通过日志详细跟踪记录基础表的增量更新数据，从而确保物化视图能够进行快速增量刷新。增量刷新方式尤其适用于数据量庞大且变更频繁的业务场景。
周期性或手动刷新的非实时物化视图，一般可以满足大部分分析场景的查询诉求，但在一些实时性要求很高的业务场景下，实时物化视图则是更优选择。因此 OceanBase 也提供了基于物化视图和 MLOG 两部分数据实时计算的实时物化视图能力，相对普通视图具有明显的性能优势。
另外新版本也支持了物化视图改写能力。系统变量 QUERY_REWRITE_ENABLED 设置为 True 的情况下，创建物化视图指定自动改写能力，系统就可以将对原始表的查询改写为针对物化视图的查询，而不用在 SQL 中特别指定物化视图名称，以此减少业务改写成本。
为了满足物化视图数据约束需求，OceanBase 也支持了为物化视图指定主键，以此优化基于主键的单行查找、范围查询或关联场景性能。
（四）外部表
OceanBase 较早就支持了 CSV 格式的文件外部表，在此基础上新版本扩展了 GZIP、DEFLATE、ZSTD 格式的压缩文件外表的支持。除此之外，随着 AP 业务的逐渐拓展，发现一些数据湖场景中，读取 Parquet 格式的外部数据源的需求也非常普遍。因此，新版本也支持了 Parquet 文件外表，用户可通过外表将文件内数据导入 OceanBase 内表，也可直接将外表用于跨数据源的联合查询分析。
另外，新版本支持了外部表分区功能，类似普通表 list 分区的分区方式，并提供了自动/手动分区的两种语法。指定自动创建分区时，系统将按照分区键的定义方式，将文件按照分区进行分组；指定手动创建分区时，需要用户指定每个分区对应的数据文件子路径。这种情况下，外表查询可以根据分区条件实现分区裁剪，减少扫描的文件数量，提升查询性能。
同时，为了保证外表所扫描的文件目录的实效性，新版本增加文件目录自动刷新功能，建外部表时可通过 AUTO_REFRESH 选项指定文件列表的刷新方式（手动、实时、周期），并结合 DBMS_EXTERNAL_TABLE.REFRESH_ALL_TABLE(interval int) 系统包子程序管理定时刷新任务。
（五）数据导入导出
在 TP 业务中，insert values 写入较为常见，而 AP 业务中高性能数据批量导入、数据加工等是比较普遍的需求。OceanBase 目前支持旁路导入、外表导入、分区交换、覆盖写、客户端导入、普通导入多种导入方式。
- 旁路导入：旁路导入通过精简数据加载的执行路径，跳过 SQL、事务、memtable 等模块，直接将数据持久化为 SSTable 来显著提升数据导入的效率。OceanBase 目前支持全量、增量两种旁路导入方式。全量旁路导入需要将表中数据重写，因此更加适用于空表导入场景。如果数据表有多次导入的需求，可使用增量旁路导入的方式，只需处理新增数据，让多次导入像第一次导入一样具有高性能。
- 外表导入：现阶段为了获得更好的分析性能，可以通过 insert into 内表 select 外表的方式，将外部数据导入 OceanBase。外表导入同样也可以利用旁路导入能力提升导入性能。
- 分区交换：分区交换是通过修改数据字典中分区和表的定义，而无需进行数据的物理复制，可以将 A 表数据近乎瞬时地移动到 B 表某个分区下的能力。适用于区分活跃和非活跃数据，需要将非活跃数据进行归档的场景。
- 覆盖写（INSERT OVERWRITE）：数据仓库中进行数据定期刷新、数据转换、数据清洗修正的场景，数据覆盖写入是较为常见的需求。OceanBase 支持表级、分区级的覆盖写能力，原子实现表或分区内旧数据清空和新数据写入。基于全量旁路导入能力，INSERT OVERWRITE 也体现出较高的执行性能。
- 客户端导入（LOAD DATA LOCAL INFILE）：客户端导入是一种通过流式文件处理完成本地文件导入的方式，开发人员无需上传文件至服务器或对象存储也可进行本地文件导入测试，提高少量数据导入的工作效率。
- 普通导入：区别于旁路导入，普通导入是一种需要经过 SQL 优化阶段的导入方式，适用于存在较多数据约束的场景。
以上多种数据导入方式均可支撑数据实时入库，但实时导入的方式需要在导入过程中等待导入完成，不能中断会话，这在大规模数据导入的场景不够友好。所以在此基础上，OceanBase 又提供了一种异步任务调度能力，用户可通过 submit job、show job status 和 cancel job 等命令实现异步导入任务的创建、状态查询和任务取消。
除此之外，数据导出也是一种较常见的业务需求，OceanBase 内核层面提供了一种 select into outfile 导出文本文件的方式，支持并行读取数据表，并行写入外部文件。同时也提供了按自定义分区规则组织导出目录的方式。后面版本将会提供全面的外表导出（数据覆盖写入外表）能力。
（六）复杂类型
随着大数据时代的来临，企业对于用户数据的挖掘和分析需求日益增强。RoaringBitmap 凭借着其节省空间、计算高效等特点，在用户画像、个性化推荐、精准营销等业务场景发挥了重要作用。OceanBase 在 MySQL 模式下支持了 RoringBitmap 数据类型，通过存储和操作一组无符号整数，提升大数据量集合计算、去重性能。为了满足多维度分析需求，该版本支持了用于基数计算、集合运算、Bitmap 判断、Bitmap 构造、Bitmap 输出、聚合运算的二十余项表达式。
ARRAY 是 AP 业务中常用的复杂数据类型，可以储存多个同类型的元素，在涉及到管理和查询关系型数据不能有效表示的多值属性时，ARRAY 类型是个合适的选择。OceanBase 在 MySQL 模式下也支持了 ARRAY 类型，建表时可以定义某列为数值型或字符型的数组类型，并允许定义为嵌套数组；支持构造表达式用于数组对象的查询或写入，支持 array_contains 表达式和 ANY 操作符用于判断数组中是否包含某个元素；同时也支持了+/-/=/!= 等操作符进行数组元素计算和判断。
多值索引是一种适用于 JSON 文档和其他集合数据类型进行元素高效检索的有效手段。OceanBase 在 MySQL 模式下兼容了 JSON 多值索引特性，允许在包含多个元素的 JSON 数组字段上创建高效的二级索引，增强了复杂 JSON 数据结构的查询能力，兼顾了数据模型的灵活性和数据查询的高性能。
2、AP性能提升
（一）基准测试
1. TPC-H 1T，从 99s 到 60s
在 TPC-H 1TB 基准测试中，OceanBase 4.3.3 GA 版本相较于 4.3.0 版本性能大幅提升。4.3.0 版本的查询时间为 99 秒，4.3.3 GA 版本将这一时间缩短至 60 秒，实现了约 64%的性能提升。从图中可以看出，在多个查询任务上，4.3.3 GA 版本相比 4.3.0 版本均展现出显著的性能优势，进一步验证了 OceanBase 在实时分析场景下的优化效果。
|-------|-----------|-------|----------|
| | 4.2.1 LTS | 4.3.0 | 4.3.3 GA |
| 耗时（秒） | 126.32 | 99.14 | 60.41 |
| 性能提升 | | 27% | 64% |
2. 更强的 ClickBench 性能
在 ClickBench 基准测试中，ClickHouse 在 Cold Run 场景的执行时间为 139.57 秒，而 OceanBase 4.3.3 GA 版本的执行时间为 90.91 秒，性能提升达 54%。在 Hot Run 的 1 和 2 场景中，ClickHouse 的执行时间分别为 44.05 秒和 36.63 秒，而 OceanBase 分别为 34.92 秒和 34.08 秒，性能提升分别为 26%和 6%。这些数据表明，OceanBase 在多次执行过程中实现了显著的性能提升。
（二）分场景参数初始化
作为一体化数据库，OceanBase 支持多种业务类型，如 Express OLTP、Complex OLTP、OLAP、HTAP、KV 等。一套默认的系统参数不能很好地适用所有场景，例如 IO 读取方式在不同的业务场景下有不同的最佳推荐。所以基于不同的业务类型，OceanBase 区分不同场景梳理了一些关键参数的最佳配置，结合云平台、OCP 等工具进行分业务场景的参数初始化，以达到对应场景下的较优开箱性能。
3、AP稳定性增强
SQL 执行涉及的数据量过大的情况下，可能出现内存不足的问题，这时部分算子需要物化临时的中间结果。当物化的数据量过大，磁盘空间写满时，会导致 SQL 执行失败。OceanBase 支持了 SQL 临时结果压缩功能，当指定压缩时可有效降低临时磁盘空间占用，以支撑更大运算量的查询任务。
4、向量检索
随着 AI 技术应用的发展和普及，图像、视频和文本等非结构化数据呈爆炸式增长，这些非结构化数据可以通过 Embedding 算法用高维向量表示，并用于分析处理。在此过程中，向量数据库应运而生。向量数据库是一套全托管的非结构化数据处理解决方案，可用于存储、索引、检索 embedding 向量。向量索引是其中最重要能力之一，向量索引将关键词搜索转为向量化检索，从确定性搜索转为相似性检索，实现了对大规模、高维向量的检索需求。
OceanBase 在 MySQL 模式下提供了向量类型存储、向量索引、embedding 向量检索的能力。支持最大 16000 维的 Float 向量存储，加、减、乘、比较、聚合等基础运算，支持近似最近邻搜索，及最大 2000 维的 HNSW 索引。可用于支持检索增强生成（RAG），满足图像和视频检索、行为偏好推荐、安全和欺诈检测、ChatGPT 类应用的业务场景。
目前已经和 LlamaIndex、DB-GPT 等应用开发框架对接，支持快速构建 AI 应用。其他框架也在紧锣密鼓地适配中。
5、全文检索
关系型数据库中通常会使用索引来加速基于精准值匹配的查询，但普通的 B-Tree 索引无法应用于涉及大量文本数据需要进行模糊检索的场景，这时只能通过全表扫描来对每一行数据进行模糊查询，文本较大、数据量较多的情况下性能往往不能满足要求。另外一些复杂的查询场景，如近似匹配、相关性排序等，也难以通过改写 SQL 支撑。
为了解决上述问题，OceanBase 支持了全文索引功能，通过预先处理文本内容，建立关键词索引，有效提升全文检索效率。目前已支持兼容 MySQL 的全文索引能力，后续也会扩展更多满足复杂检索逻辑的功能支持，并进一步提升性能。
6、可靠性检索
新版本支持了租户克隆能力，用户可在 SYS 租户下对指定主租户或备租户快速克隆出一个新租户。租户克隆任务执行完成后，新克隆租户为备租户，也可将其转为主租户提供服务。新克隆租户和原始租户在初始状态下共享物理宏块，但新的数据变动和资源使用会按租户进行隔离。当用户需要对在线租户进行高资源消耗的临时数据分析或其他高风险操作时，为了避免对在线租户造成影响，可使用克隆租户完成分析或验证。同时也可将克隆租户作为容灾手段，若原始租户发生了难以恢复的误操作，可使用克隆租户进行数据回滚。
此外，OceanBase 还支持了一种快速恢复能力。当前的物理恢复是一个全量数据恢复过程，只有当数据(转储+基线)及日志都恢复了，物理恢复才能完成，然后用户才可以登录并使用这个恢复完成的租户。当数据量很大时，一方面数据恢复需要很长时间，另一方面，由于要恢复全量的数据，用户在一开始就需要为这个租户预留足够的磁盘空间，从而保证恢复成功。然而在某些场景下，例如用户仅是用恢复出来的租户做一些查询校验，用完之后就会销毁恢复，查询期间只会涉及少量 tablet 时，全量恢复成本太大，浪费空间、时间和网络带宽。
新版本支持的快速恢复是一种只恢复日志不恢复数据的能力，数据无需恢复到本地即可提供读服务。同时，数据备份支持了对备份的 SSTable 构建基于备份地址的中间层索引，通过该索引，OBServer 能够像读取本地数据一样随机读取备份的 SSTable。
7、写在最后
4.3.3 GA 版本是 OceanBase 在实时分析和 AP 场景上的重要突破，标志着我们在构建现代数据架构上迈出了坚实一步。未来的 4.3.x 版本中，我们将继续优化和增强 AP 功能，打造一体化产品能力，不断满足业务场景中的多样化需求。
我们衷心感谢每一位用户和开发者在 OceanBase 4.3.3 版本中的支持与贡献。你们的反馈和建议，是我们不断提升产品、攻克技术难关的动力。OceanBase 希望在未来的发展道路上，继续与用户一起，共同打造更高效、更强大的分布式数据库！
如果你感兴趣， 可以免费试用 OceanBase V 4.3.3 ，也欢迎给我更多关于产品或场景上的建议！