OceanBase 一直沿着“一体化数据库”的方向演进从核心交易场景的分布式在线交易到 Oracle 兼容、HTAP、多模型能力和混合搜索。在刚刚过去的 OceanBase Hours 上OceanBase 正式发布了湖库一体的 AI 数据库。这不只是负载类型和数据模型的又一次升级而是一个更根本的变化——数据库的用户变了。AI 数据库不是为了支持图片、PDF 或向量而是因为数据库第一次迎来了一类新的用户——Agent。这件事带来的第一个挑战就是 Agent 的数据困境。当一个 Agent 在处理一次决策请求时它可能需要同时调用用户画像非结构化数据、历史对话摘要文本、知识库中的 PDF 原文、向量召回的语义结果以及实时业务状态。这些数据今天分散在对象存储、搜索系统、向量库、业务数据库和离线数仓中。它们之间没有统一事务没有一致性快照没有血缘关系。当 PDF 更新了但 embedding 还指向旧版本时Agent 给出的答案就可能是错的——而你甚至不知道它错了。这不是一个“多存几种数据类型”的问题而是一个数据治理问题当多模态数据进入核心生产链路后谁来保证它们版本一致、计算完整、可追溯、可信赖多模表就是在这个背景下提出的。多模表是 OceanBase 刚刚发布的湖库一体 AI 数据库中的多模态数据管理能力。它把多模态数据——图片、音视频、PDF、网页快照、向量、JSON、结构化字段——作为数据库的一等数据对象统一管理并在同一套体系内提供事务、一致性、实时高可用、混合搜索、分析计算和在线服务能力。一句话概括多模表让你像管理关系数据一样管理多模态数据像查询结构化字段一样检索非结构化内容。核心能力一览Agent 面向的业务对象天然是多模态的。它的输入可能是自然语言、图片、PDF、网页、表格或业务上下文运行时依赖的内容包括用户记忆、知识库、RAG 结果、结构化业务数据、语义画像和模型推理中间结果。这带来四个根本性变化非结构化数据进入核心生产链路。 它不再是对象存储里的附件而是 Agent 做出决策的关键输入。数据访问模式变成混合搜索。 一次请求可能同时涉及结构化查询、全文检索、向量召回和过滤分析。实时性要求陡增。Agent 需要 7×24 在线决策传统 T1 报表无法满足。特征是动态生成的。很多字段不是写入时直接给出而是由模型从原始多模态数据中异步提取。因此多模表要解决的核心问题是如何在数据库内统一管理多模态原始数据、结构化字段、动态衍生特征和异步计算结果并让它们共同服务在线交易、分析处理和混合搜索——同时保证一致性和可见性。统一管理多模态对象多模表将多模态数据纳入数据库的事务和版本管理体系。图片、音视频、PDF、网页快照等大对象支持三种存储形态行内存储 小对象或关键元数据直接存放在行内行外存储大对象脱离行内但仍由数据库管理引用关系和事务边界库外存储对象本体放在对象存储等外部系统数据库保存访问地址、版本和可见性信息。关键不在于对象存放在哪里而在于数据库管理它的唯一标识、访问地址、版本、可见性和事务边界。这保证了原始对象和它衍生出的摘要、标签、embedding、风险分等特征始终对应同一个数据版本——避免“对象已更新特征仍指向旧内容”的不一致。动态特征列多模态数据具有“富模态”特性同一份原始数据可以不断提取新的语义、结构、质量和业务特征。例如文本可以生成主题、摘要、embedding、安全标签、语言类型、质量评分图片可以不断追加 OCR 结果、标签、风险分和业务特征。传统方案下每新增一个特征都需要 DDL 变更带来缓存更新、增量写入放大和后台合并压力。多模表采用轻量的动态列机制特征扩展无需表结构变更同时保留 SQL 可查、分析可优化、混合搜索可命中的结构化语义。这不是一个退化为键值结构的方案。键值结构虽然灵活但无法自然支撑 SQL 分析和搜索优化。多模表在结构化可优化和动态扩展之间做了明确的工程取舍。异步近实时计算多模表中大量列不是用户直接写入的而是由计算任务生成——embedding、摘要、OCR、质量分、全文索引和向量索引。这些计算由数据库内置模型能力、后台任务或外部计算链路承载。模型推理耗时通常在数百毫秒到数秒不能阻塞在线写入。多模表的处理方式1.原始数据先提交保证在线写入响应时间不受影响2.后台任务根据血缘关系触发特征提取、索引构建和回填3.系统在近实时范围内让衍生数据可见4.读请求按一致性位点读取完整可用的数据视图。这里的设计判断是追求所有衍生列强同步是不现实的也是不必要的。正确的取舍是在实时性、吞吐、存储效率和一致性之间建立可控的平衡点。计算任务负责生成衍生值多模表负责让这些值成为可治理、可搜索、可分析、可一致读取的数据资产。列组级一致性异步计算引入了新的可见性难题。一行原始数据写入后特征 A、特征 B、embedding、全文索引、质量标签可能由不同任务、不同模型在不同时间完成。如果查询时看到特征 B 已完成但特征 A 未完成业务计算就可能出错。多模表通过列组级一致性解决这个问题某个业务列组只有在相关衍生列全部完成后才形成新的可见快照。查询和混合搜索读取的始终是一致性快照而不是半成品数据。存算分离与冷热一体多模态数据体量大且持续增长——文档、图片、视频、向量和衍生特征会不断累积。如果全部按在线热数据方式存放成本不可接受。基于共享存储的存算分离架构多模表实现了冷热数据一体化管理近期数据如 90 天内 缓存在 SSD 中保证低延迟访问历史数据如 90 天以上沉淀到低成本共享存储仍可被同一套查询、搜索和分析能力访问。对用户而言查询热数据和冷数据不需要切换系统也不需要在在线库、对象存储、离线数仓之间手工拼接。同一个数据视图下兼顾访问性能、存储成本和查询连续性。血缘与 Unified Catalog一个 embedding 由哪段文本生成一个安全标签由哪个审核模型打出一份摘要对应哪个 PDF 版本如果这些信息缺失系统就无法判断数据是否完整、是否可信、是否可以被业务读取。血缘与 Unified Catalog 是多模表的元数据底座它记录原始对象、结构化字段、动态特征列、模型任务、版本和权限之间的关系。这套元数据服务三个关键能力触发 后台任务根据血缘关系自动触发特征提取、索引构建和回填完整性判断系统判断某个列组或快照是否已完成全部衍生计算决定是否推进可见性可追溯性当 Agent 给出回答时可以追溯它依赖了哪些原始文档、图片、业务记录和衍生特征。一体化访问在线交易、分析处理与混合搜索多模表不是纯存储结构而是三类工作负载共同依赖的数据底座在线交易 业务写入、事务保障、一致性和高可用分析处理大规模扫描、聚合、过滤、join 和特征分析混合搜索组合结构化条件、全文检索、向量召回、标签过滤和业务排序。Agent 的访问模式天然复杂——一次请求可能先用结构化条件过滤业务对象再用全文检索查描述用向量召回找语义相似内容最后还要按标签、质量分、时间和权限排序。这是典型的混合搜索场景任何单一引擎都无法独立覆盖。核心取舍是近实时而非强同步。搜索和分析场景通常不需要衍生特征在写入事务内立刻完成但需要在较短时间内可见并且读取时看到一致的数据快照。这样同一份多模表数据可以同时支撑在线写入、混合检索和分析查询消除业务在多个系统之间反复同步和拼接的成本。多模表适合那些既有多模态数据又需要在线访问、实时更新和统一治理的场景OceanBase 多模表解决的问题不是 AI 数据库能不能存图片、PDF 或向量而是当 Agent 成为数据库的第一用户后数据库如何继续管理完整的业务对象而不是一堆彼此孤立的数据类型。从这个角度看多模表不是一个单点功能而是 OceanBase AI 数据库面向 Agent 和多模态时代的数据模型升级。它把结构化数据、非结构化数据、AI 衍生特征与业务语义统一到同一套事务、治理和计算体系让数据库真正成为 Agent 的数据底座。过去数据库统一的是数据AI 时代数据库需要统一的是数据、语义与智能运行。多模表就是 OceanBase AI 数据库向这一目标迈出的第一步。相关内容推荐了解更多添加社区小助手加入微信交流群~立即试用 OceanBase 企业版体验国产数据库能力180 天免费试用零门槛开通