6.6
深览指数
科技量子位··AI 生成
OceanBase湖库一体，重新定义AI数据库
OceanBase CTO 杨传辉在文中提出，AI Agent 成为数据库新使用者后，传统数据库架构已无法满足需求。文章系统阐述了 OceanBase 湖库一体（Lakebase）的设计思路：通过多模表统一结构化与非结构化数据、存算分离架构支撑 Agent 的弹性负载、混合搜索作为一类原生负载、Fork Database 与逻辑表解决 Agent 的版本控制与规模问题。核心观点是，AI 时代需要一套技术栈解决离在线统一、多模态数据管理与高一致性治理，而非多个系统缝合。文末介绍其上下文层产品（PowerMem、OSI 语义层），声称通过语义质量提升 AI 应用准确率。适合关注数据库架构演进、AI Infra 选型的技术决策者阅读。原文 ↗
核心观点
- ▍AI 时代数据库需从面向人类应用和结构化数据，转向面向 Agent、多模态数据与混合负载的‘湖库一体’架构，通过一套技术栈实现离在线统一与一致性治理。
- 01Databricks、Snowflake 从湖仓/数仓向 OLTP 补充；OceanBase、Oracle 从交易库向 OLAP/大数据提升；MongoDB、Milvus、Elasticsearch 从专用库向通用数据库演进——各路线均向统一数据底座靠拢。
- 02OceanBase 湖库一体底层采用存算分离架构，数据存于对象存储，计算层独立伸缩，以应对 AI Agent 突发式工作负载。
- 03多模表作为核心数据结构，支持结构化、半结构化与非结构化数据（含 LOB 对象）的统一管理，并引入实时 AI 列（写入时自动触发 Embedding/打标，具备事务一致性）。
- 04基准测试显示，HNSW 算法下 OceanBase 向量搜索性能（768/1536 维）领先 Milvus、ES、pgvector；MS MARCO 数据集上混合搜索性能比 ES 提升 30% 以上。
- 05Fork Database 可在 PB 级规模下秒级创建副本（Copy-on-Write，仅占增量空间），配合 DIFF/MERGE 实现数据版本控制。
- 06逻辑表设计将千万级 Agent 各自的独立逻辑表映射至同一物理表，解决 Agent 场景下的 Schema 爆炸问题。
- 07基于 PowerMem 的 seekdb M0 在 AppWorld 实验中，通过率 39%（Hermes 22%），完成步骤 6.2（Hermes 10.4），Token 消耗降低 32%。
- 08OceanBase OSI 语义层基于 Ant-OSI 标准，在客户 POC 中声称准确率远好于业界其他产品，核心差异在于语义上下文质量。
反方 / 局限
- — 文章未讨论 OceanBase 湖库一体在 PB 级混合负载下的实际性能瓶颈、与 Databricks/Snowflake 等成熟产品的详细对比盲区，以及多模式混合查询优化（如向量+关系过滤）在高并发场景下的退化风险。
- — PowerMem 与 OSI 语义层的效果数据基于内部测试（AppWorld 实验、POC 反馈），缺乏第三方独立验证或开源基准的可复现性。
- — 文中‘AI Agent 将成为数据库主要使用者’这一核心前提在当前阶段仍属预测性判断，短期内企业实际 Agent 的生产级部署规模与复杂度远未达到文中所描述的‘千亿级 Agent’场景。
OceanBase杨传辉DatabricksSnowflakeMongoDBMilvusElasticsearchPowerMemseekdb M0OSIHNSW多模表湖库一体Fork DatabaseAppWorld
13 分钟 · 5 卡片 · 14 资料
读原文 →