核心特性

OceanBase Database AI 继承了 OceanBase 数据库经过大规模生产验证的成熟能力，包括深度兼容 MySQL、强一致性事务与高并发处理、高压缩存储等，为 AI 数据场景提供坚实的数据库底座。同时，数据库还提供了完善的安全与访问控制体系。在此基础上，存算分离架构带来极致的低成本与高可用。本文介绍 OceanBase Database AI 的核心特性。

Agent 场景原生能力

OceanBase Database AI 让 Agent 场景的隔离、记忆、试错三个核心行为都成为数据库原生能力，无需再依赖应用层实现。

集群内五层隔离

OceanBase Database AI 支持租户、数据库、Namespace、表、行/列五层隔离，满足不同场景的隔离需求，支撑千万级的应用实例。

1. 租户级隔离

   一个集群里可以创建多个租户。每个租户都有自己独立的资源配额、元数据、用户和权限，彼此互不影响。适合不同业务线、不同客户，或对 SLA、资源边界要求严格的场景。这种隔离方式隔离效果最强，但管理成本和资源开销也相对最高。

2. 数据库级隔离

   同一租户内可再划分多个数据库，各数据库的表、视图、存储过程彼此独立，互不影响，适合同一客户下不同 Agent 应用或业务域；比租户隔离更轻量，但各数据库仍需分别维护自己的 Schema。

3. Namespace 级隔离（逻辑表）

   逻辑表指在同一套物理表结构上，为不同 Agent、用户或业务域创建逻辑独立的 Namespace。各 Namespace 的数据彼此隔离，但共享同一套 Schema 和物理存储，适合 SaaS 多客户、海量 Agent 记忆库等主体多、单主体数据少的场景。不必为每个 Agent 或用户单独建物理表，从而降低元数据规模和运维成本。

4. 表级隔离

   不同 Agent、用户或业务域使用不同物理表，Schema 可各自演进，适合数据结构差异大，或需要独立索引、独立生命周期管理的场景。表数量过多会增加元数据管理成本，更适合主体数量可控的场景。

5. 行级隔离/列级隔离

   行级隔离让不同 Agent/用户在同一张表中只能访问自己的行；列级隔离控制敏感字段的可见范围，适合表结构共享，但数据权限要求严格的场景。可用应用层过滤，也可结合行级安全（RLS）、列级权限等数据库能力。

混合搜索召回记忆

Agent 记忆通常不只一种形态，召回时也常要组合多种搜索条件：用结构化条件圈定范围，用向量找语义相近内容，用全文找关键词匹配。OceanBase Database AI 支持在一条 SQL 中通过混合搜索完成记忆召回，无需跨多个系统拼接，一致性由数据库事务保证。

1. 多模数据统一存储

   Agent 记忆类型多样，包含：

   • 长期记忆：向量（知识嵌入）、文本（对话历史）、JSON（元数据/标签）
   • 短期记忆：关系表（任务状态、上下文变量）、JSON（中间结果）
   • 工具调用记录：结构化日志、文本参数、向量语义
   • 多模态输入：图片、音频、视频，以及对应的向量和描述文本

   数据库侧可统一存储关系表、JSON、TEXT、BLOB、Vector、GIS 等类型，避免 Agent 对接多套异构存储。

2. 索引混合搜索

   记忆召回常是多条件组合，例如用户 ID、会话 ID、时间范围等标量过滤，对话历史关键词的全文搜索，语义相似记忆的向量搜索，以及记忆元数据的 JSON 过滤。OceanBase Database AI 支持在一次 SQL 中基于索引完成标量 + 全文 + 向量的混合搜索，并在库内融合排序；多模数据亦可一并参与搜索，而无需在应用层拼接多个系统的结果。同时混合搜索场景还支持创建异步全文索引，可将索引维护改为后台增量刷新，以一定的可见延迟换取写入与查询性能的提升。

3. 实时一致

   对话过程中写入的新记忆，需要马上可用于下一次搜索：事务提交后，向量索引、全文索引、JSON 索引立即可见，避免多系统分别写入带来的同步延迟和数据不一致。

4. AI 原生能力

   OceanBase Database AI 提供嵌入、向量距离计算、Rerank、模型推理、文档切分等内置函数能力，减少 Agent 应用在库外单独编排数据处理链路的工作量。

5. 存储与扩展

   Agent 记忆通常量大且访问不均，可借助存算分离与冷热分层降低长期存储成本；计算与存储独立扩展，并结合独立日志服务实现 RPO=0。存算分离能力详细说明见下文。

试错：Fork Database 提供数据沙箱

Agent 的评测和调试需要反复在真实数据上试验，但直接修改生产数据风险不可接受，每次完整复制又耗时且占用存储。Fork Database 允许基于同一份基线数据快速创建多个独立副本，每个副本作为实验沙箱使用。

• 基线一致：所有副本基于同一个快照创建，实验起点相同，对比结果有意义。
• 读写隔离：各副本相互独立，一个实验中写入的错误数据不会影响其他实验或基线数据。
• 创建快、开销低：Fork 不复制全量数据，而是通过 Copy-on-Write 共享基线、只记录增量，创建速度远快于传统全量复制，存储成本也不会随实验数量线性增长。
• 可丢弃、可合并：实验未达预期时直接 DROP 分支即可，不留垃圾数据；验证通过的实验结果可以合并回主分支。
• 可对比、可追溯：各分支的实验结果（输出、评分、Bad Case）仍在各自数据库中，可以用 SQL 跨分支查询和对比，每条结果都能回溯到当时使用的 Prompt、模型参数和输入上下文。

多模一体化

OceanBase Database AI 把大对象文件、AI 模型、推理结果和业务字段纳入同一套数据库语义，便于统一存储、查询和管理，让非结构化数据从成本中心变成可计算资产。

LOB 分层存储

传统做法里，非结构化文件常放在对象存储或文件系统，数据库只存路径，常见问题包括：文件不是数据库对象，事务回滚时文件状态难以一并回滚；权限要分开管，库表权限和文件权限容易不一致；查文件要先查库拿路径，再访问对象存储，链路长、延迟高；版本和生命周期难以统一管理。

OceanBase Database AI 将 LOB（大对象）作为数据库对象管理。文档、图片、音频、视频等可与结构化字段存在同一张表中，由数据库统一处理事务、权限、版本和查询；并按数据大小和访问特征自动选择合适的存储形态。LOB 包括三种存储形态：行内存储（InRow）、行外存储（OutRow）、对象存储（Object Storage）。无论底层如何存储，应用仍用统一 SQL 操作。文件列对应用来说就是普通列，事务、索引、权限和版本由数据库统一处理。

模型元数据管理（Model in DB）

OceanBase Database AI 支持将 AI 模型及端点注册为数据库元数据对象，并通过 PL 系统包管理。可注册的类型包括嵌入、文本生成、多模态、重排序等。

模型注册后，可作为普通数据库对象进行权限控制，并在 SQL 或表定义中引用，而不必仅在应用层维护外部服务地址。由此，模型调用、推理结果写回以及权限管理可纳入同一套数据库管理体系。注册模型后，可通过 AI 函数对多模态文件做分片、向量化，并写回原表；也可基于文档建全文索引、基于向量建向量索引，像查询关系表一样搜索和分析。

多模态搜索

多模态数据入库后，可复用前述混合搜索能力，在同一条 SQL 中组合标量、JSON、全文、向量等条件。相较 Agent 记忆召回场景，多模态搜索还常涉及图像语义与空间条件。支持的主要搜索类型如下：

以上能力可由优化器按规则和代价选择执行计划，在同一条 SQL 中组合使用。

湖-仓-库一体：一套系统统一技术栈

“湖-仓-库一体”并非把三个系统简单包装在一起，而是基于同一份数据、同一套元数据、同一套 SQL 语义，通过一套引擎同时满足湖的低成本、仓的分析能力、库的事务性要求。

减少数据搬运

同一份数据同时服务 TP、AP、AI 检索，不需要在数据库、数仓、向量库、对象存储之间反复同步。离线加工、多模态数据加工数据取自 OceanBase Database AI，写回 OceanBase Database AI。

统一语义

事务、数据版本、权限、索引、查询入口统一在数据库内，避免元数据、文件、向量等存储在不同系统内的治理难题。

降低成本

对象存储承载海量冷数据，计算节点按负载独立扩展，避免为容量被迫购买计算资源。单副本模式极致降低资源成本，但仍保证 RPO=0。

简化运维

一套引擎、一套监控、一套备份恢复策略，减少多系统运维的复杂度和人员成本。

加速 AI 落地

结构化数据、非结构化文件、模型推理结果在同一套 SQL 语义下被查询，RAG、Agent 等场景的链路大幅缩短。

RAG

OceanBase Database AI 把 RAG 主链路（除文档解析）均放在数据库内完成：文档入库后，可用 SQL 完成搜索与答案生成。

文档入库

支持在数据库完成文档分割、文本嵌入和构建双索引，无需再同步到外部搜索引擎或向量库。

1. 文档分割

   长文档通常需要先切分再检索。可通过 AI_SPLIT_DOCUMENT() 函数按语义或固定长度切成文本块，既保留上下文，也便于嵌入和建索引。

2. 文本嵌入

   通过 AI_EMBED 函数为每个文本块生成向量数据，写入向量列，并由数据库构建向量索引。

3. 构建双索引

   同一批文本块可同时构建两类索引：全文索引支持关键词搜索和 BM25 排序，向量索引支持语义相似度搜索；两类索引都在库内维护，不必再同步到外部搜索引擎或向量库。

用户搜索

用户搜索时，支持在数据库内仅通过 SQL 完成搜索与答案生成，无需再编写应用代码。

1. 混合搜索

   用户提问时，一条 SQL 可同时发起多路搜索：向量搜索用问题的 Embedding 找语义相关文本块，关键词搜索用问题中的关键词找精确匹配文本块，标量过滤用业务限定条件缩小范围。

2. 加权融合

   多路搜索结果可在库内融合排序，内置多种算法，例如 RRF（Reciprocal Rank Fusion）按排名位置融合、WEIGHT_SUM 按分数加权求和、MINMAX_NORMALIZER 归一化后融合。

3. 重排和生成

   融合后的候选结果可通过 AI_RERANK() 函数调用 Rerank 模型做精排，提升最终相关性。通过 AI_COMPLETE() 和 AI_PROMPT() 函数将 Top-K 候选文本块与用户问题一并交给大模型，生成最终答案。

AI 算子可扩展

RAG 链路中的嵌入、重排、文本生成等步骤，可通过内置 AI 函数直接调用已注册模型完成。除嵌入、精排等常见能力外，还支持通过 Python UDF 扩展业务自定义算子，例如行业专用预处理、规则打分或定制后处理逻辑。

自定义算子创建后，可像普通函数一样在 SQL 中调用，并与混合搜索、融合排序、答案生成等步骤组合使用，从而在数据库内扩展 RAG 能力，而不必把关键处理逻辑下沉到外部应用服务。

存算分离架构

OceanBase Database AI 使用存算分离 + 冷热分层 + 日志与计算解耦的架构，平衡资源成本、可靠性与性能。

三层解耦

计算、日志、存储各自独立：

• 计算层（OBServer）

  OBServer 是数据库的计算节点，负责接收 SQL 请求、解析执行计划、调度并行任务、管理事务上下文、执行 AI 函数，以及维护本地热数据缓存。它只处理“计算”，不持久化全量数据，算力可以按需购买、按需调度。

  • 无状态：不保存全量数据副本，本地只有临时缓存和日志回放状态
  • 分层独立弹性扩缩：计算节点、日志服务、存储层可各自独立弹性扩展；增加或减少计算节点不需要迁移数据，新节点从对象存储加载数据、从 LogService 回放日志即可
  • 支持单副本：因为可靠性由 LogService 保证，计算节点可以单副本运行，降低成本
  • 本地 SSD 作缓存：热数据和索引缓存在本地，保证活跃查询性能

• 日志层（LogService）

  LogService 是独立部署的分布式事务日志服务，负责事务日志的提交、持久化、复制和回放。它是整个系统高可靠的基石。

  • 独立部署：与 OBServer 分开部署，资源互不干扰
  • 三副本：默认三副本，通过 Paxos 协议保证多数派确认
  • RPO=0、RTO<8 秒：事务日志在多数派副本确认后才返回成功，计算节点故障不丢已提交数据；1F 部署下 RTO 为分钟级，2F 部署下 RTO<8 秒
  • 快速恢复：OBServer 重启或扩容时，从 LogService 回放日志即可恢复一致性

• 存储层（对象存储）

  对象存储是数据的最终持久化层，保存全量数据、LOB 大对象、历史快照和备份数据。支持 S3 协议的对象存储都可以作为后端。

  • 低成本：对象存储单价远低于本地 SSD，适合海量冷数据和长期归档
  • 近乎无限容量：容量按对象存储上限扩展，不受单台服务器磁盘限制
  • 共享访问：多个 OBServer 节点共享同一份数据
  • 存储后端保证高可用：对象存储本身提供高可用，数据库层无需再维护多份数据副本

数据冷热分层

全量数据置于对象存储，显著降低存储成本。但活跃数据如果每次都从对象存储读取，延迟会难以接受。所以 OceanBase Database AI 在对象存储之上增加了一层本地 SSD 热缓存，并根据数据访问热度自动在两层之间迁移：

• 热数据：近期高频访问的数据和索引，缓存在 OBServer 本地 SSD，保证访问性能。
• 冷数据：低频访问或长期沉睡的数据，保留在低成本对象存储。
• 自动识别与迁移：系统持续监控冷热策略和数据访问模式，自动把变冷的数据从 SSD 迁出，把变热的数据加载到 SSD。