前几天看了OceanBase Hours的发布会，说实话有点小惊喜。从分布式数据库到湖库一体的 AI 数据库，AI 数据库的底座，确实需要装得下一切数据形态。

今天这篇文章，就跟大家好好聊聊，我看完这次发布会后的一些学习和思考。

1. 数据底座的变化

想想过去的上半年，公司让我们在各个系统中去接入AI能力。

于是原业务的MySQL存业务数据，Elasticsearch做全文检索，然后又新增了Milvus存向量做语义搜索，各种数据同步，多路召回融合，总之一言难尽。

美其名曰是RAG架构，实际上就是一个缝合怪，整个流程走下来，我认为数据库的一体化势在必行。

我们现在的更新流程是这样的：

1. 业务数据保存到MySQL
2. 异步生成全文索引，写到Elasticsearch
3. 异步生成embedding写到Milvus

这三步任何一步失败，数据就会出现不一致，然后尝试数据补偿，整体流程下来，整个架构复杂度很高。

怎么去解决这个问题呢？是否可以将所有的数据保存在一起呢？

OceanBase发布的湖库一体数据库则很好的去解决了这个问题，湖库一体减少了系统与系统之间的数据的复制和同步，将结构化数据、全文、向量融为一体，不仅保证了数据的一致性，同时还简化了架构的复杂性，降低了运维的成本，增强了系统的高可用。

一直以来OceanBase的产品理念是融合，打造真正的一体化平台。相信这也是AI时代的数据底座的大趋势。

2. 什么是"湖库一体"数据库?

湖仓一体这个词相信大家都听腻了吧。它主要解决的是"数据存哪"的问题，把数仓和数据湖合并，减少数据搬运。

但这次 OceanBase 提出的"湖库一体"，这是一个很大的跨越。那么湖库一体到底长什么样子呢？

先看一下官方给出的架构图

我的理解是湖库一体数据库是面向AI时代设计的一种新型数据底座，主要面向AI应用，Agent应用。它把数据湖的开放、海量存储能力，与数据库的强一致性、实时处理能力，融合到同一套引擎里，让它们真正成为可计算的资产。通俗点说就是把业务数据、做语义检索的向量数据、甚至是多模态的图片、文件等对象全部放在一起，方便我们进行数据检索、计算。

那么湖仓一体和湖库一体有什么区别呢？我们可以通过下面图片的对比清晰的看出区别。

3. AI时代的数据存储方式

上面我们探讨了数据底座的变化和湖库一体的数据库概念，然而如何将结构化数据和非结构化数据保存到一起呢？

OceanBase里面做了一个非常好的抽象叫多模表，在这个多模表里面既有能够去支持结构化数据的关系列，也有能够去支持非结构化数据的多模列或者AI列。

一说AI检索，我们最先想到的就是向量搜索。那么多模表和向量搜索有什么区别呢？在实际场景里面，多模表首先通过关系过滤来将全局的数据得到一个更小的候选集，接着把候选集里面的数据做向量搜索、全文搜索、图搜索的混合搜索，最后做rerank，通过这种方式实现的数据入库即智能，所有数据都是混合搜索，保证最高的准确率，这就是多模表的优势。

说的有点抽象，我们看下下面这个建表的SQL：

CREATE TABLE intelligent_service (
  id INT,
  biz_type VARCHAR(64),           -- 结构化字段
  raw_file LOB,                   -- 非结构化大对象：图片/音频/视频
  metadata JSON,                  -- 半结构化元数据
  embedding VECTOR(1536),         -- AI列：向量特征
  content TEXT                    -- AI列：文本摘要
);

这看起来就是一张普通的表，但背后的设计极其精妙：

针对非结构的多模态数据可以使用LOB的分级存储，对小对象直接行内存储，减少IO；大对象切片存储在对象存储或直接使用OSS，数据库表中仅存储URL地址。

在保存数据时，在同一个事务内，embedding生成要么全成功要么全失败，不会出现部分数据有向量、部分没有的不一致状态。

查询的时候，读取的是同一张表，可以同时做关系过滤、全文搜索、向量搜索、图搜索。

我们简单的看一下如何进行多模态混合检索查询：

SELECT 
    -- 基础信息字段
    id,                                          -- 记录的唯一标识
    content,                                     -- 文本内容/摘要
    biz_type,                                    -- 业务类型（用于业务维度分析）
    -- 文本相关性分数（全文检索）
    MATCH(content) AGAINST('智能家居 语音控制') AS text_score,
    -- 向量语义相似度分数
    distance(embedding, '[0.12, -0.34, 0.56, ...]') AS vector_score
FROM intelligent_service
WHERE 
    -- 全文检索匹配：只要 content 中包含 '智能家居' 或 '语音控制' 的任一关键词，就被召回
    MATCH(content) AGAINST('智能家居 语音控制')
    -- 向量语义匹配（OR 逻辑）：向量距离小于 0.8（即语义上足够相似）
    OR distance(embedding, '[0.12, -0.34, 0.56, ...]') < 0.8
ORDER BY 
    text_score DESC,     -- 文本匹配度高的排在前面（分数越大越好）
    vector_score ASC     -- 向量距离小的排在前面（距离越小越相似）
LIMIT 20;

熟悉的SQL语言，不一样的功能，让我们可以很快的学习上手。

所有的复杂度都被藏起来了——这就是OceanBase一直说的"把简单留给客户，把复杂留给自己"。

4. Agent时代的数据库需求

随着Vibe Coding的普及，应用的开发变的越来越简单，例如使用灵光，我告诉它我的想法，它就可以自动生成出应用，不需要你会Java还是Python，也不需要React还是Vue，从数据库到页面，全自动生成。

根据Gartner的预测，到2028年，超过三分之一的企业软件交付是由智能体来完成，而智能体的行为跟我们非常不一样，它需要高频数据调用、并行的执行、7×24小时不间断的运行。

在Agent时代，数据库正在从“为人类应用服务”变更为“为智能体服务”。那么Agent对数据库有什么需求呢？

4.1 Agent是搜索驱动的

Agent的执行本质，是"搜索-思考-行动"的循环。搜索不是辅助功能，而是Agent的行为方式。

混合搜索必须成为数据库的核心能力，混合搜索不仅仅需要的是数据库，agent的上下文当中包含了Memory、RAG、知识库这样的系统，也涉及到大量多模态的数据检索和召回，所以agent的上限，不仅仅是模型能力，更重要是高质量的数据，基于多模态的混合搜索是AI数据库的核心能力，这也是OceanBase基于一体化引擎打造而来的强大能力。

4.2 Agent是会犯错的

Agent就行我们日常开发一样，我们有Git分支、有测试环境，发布前备份数据，发布失败可以进行紧急回滚。

Agent也一样，它可能会改错表结构、写错数据、搞错策略等等存在异常的行为。

如果数据库级别没有沙箱机制的话，Agent的每一次试错都可能会变成生产事故。

为此，OceanBase有一个功能叫Fork DB，Fork Database，通过Fork Database，我们能够秒级创建一个数据库的实例或者是一个数据库的租户，有点相当于我们在Git上拉了一个代码开发的分支，接下来我们就可以在这个代码分支上做自己的一个AI的开发跟AI的实验，如果最终的结果符合预期，直接提交，如果不符合预期，失败回滚，基本上没有什么代价。

4.3 Agent需要记忆

说到记忆，我们首先可能想到的上下文，经常可以到，某某模型上下文可以支持到多少K，现在GLM 5.2 甚至可以支持到1M的上下文。

但上下文和记忆还是有很大的区别的。上下文更像是单次会话的历史内容，是一个短期记忆，我们开启一个新的任务时，之前的上下文会清除掉。而记忆是长期的，跨会话的用户画像、历史偏好、行为模式，这部分需要数据库以结构化 + 向量的形式持久化存储。

目前很多 Agent 框架将记忆层外置（如 Redis + PG Vector），但这引入了数据一致性和运维复杂性问题。一体化数据库的价值在于，让记忆管理和业务数据在同一个事务边界内完成，避免“记忆漂移”。

5. Agent记忆处理

上面简单的提到了Agent的记忆存储，现在OceanBase也针对这个命题，交出了一份答卷，下面让我们一起看一下。

5.1 PowerMem：把Agent记忆从堆砌变成资产

我现在使用Claude Code经常会遇到content达到很高，本着节约token的原则，我可能会进行一下/compress命令去压缩上下文。但是完整的上下文链路是否有价值呢？答案是当然！

OceanBase推出的AI智能记忆体PowerMem，以及它的云上实现seekdb M0。主打一个让Agent的记忆可进化、可治理、可复用。

可以通过下图查看PowerMem的关键特性和评测对比。

5.2 高质量的语义

高质量的语义上下文对于AI去理解企业也非常的重要，OceanBase也有一个非常重要的产品特性叫OceanBase OSI。

OceanBase OSI给出了一个全新的思路，我给总结了一下，就是基于本体论的自动语义建模。

利用大模型从原始数据中自动发现业务实体、指标、关系，构建出完整的语义网络，从底层的指标定义和计算逻辑，到中间层自动生成的上下文图谱，再到顶层的业务本体映射。

6. OceanBase Lakebase的可用性

一个数据库产品，光引擎强大是远远不够的，使用者如何更好的去开发使用，进行数据管理，这些使用层面的体验也是非常重要的。

为此，在Lakebase底座之上，OceanBase还发布了DataStudio，它是一个面向结构化和多模态数据的统一开发治理平台。它的核心价值很简单，就是把 Lakebase 的能力，真正交付给上层应用。

写在最后

十五年前，双十一的商业压力催生了原生分布式数据库，OceanBase就是那个时代的产物。

今天，蚂蚁生态下AI落地的真实场景正在催生新一代的AI数据库，这也是OceanBase最独特的优势。它不是在实验室里空想下一代数据库应该长什么样，而是在阿里、蚂蚁这些复杂的AI生产场景中，被真实的业务需求倒逼出来的。

让我们一起期待下OceanBase未来的样子吧。

今天的分享到这里就结束了，如果有对OceanBase感兴趣的小伙伴可以联系我哟~

---

每一篇文章都是我用心整理和思考的结果，希望能对你有所帮助。如果觉得内容还不错，欢迎点赞、收藏、转发支持一下～

如果你有任何问题、想法，或者单纯想交个朋友，都可以加我微信一起交流学习：

📱 微信：ai-xiaoxiaofeng

也欢迎常来我的小站坐坐：

🌐 个人网站：https://www.xiaoxiaofeng.com

我会在这里持续分享更多技术干货与成长心得。

保持热爱，奔赴山海。我们下篇文章见～ 🚀

—— 笑小枫