给 Dify 架构做“减法”,Dify × OceanBase 解锁一体化数据库
来源:互联网
时间:2026-07-24 14:07:48
## 荐语
Dify 现已全面兼容 MySQL 作为元数据存储。感谢 OceanBase 开源团队与顺丰 AI 技术平台组在兼容性适配和能力验证上的通力协作,我们一同向更稳定、更一致、更易用的 AI 应用基础设施方向努力。
**Dify v1.10.1 于日前发布,新增基于 OceanBase 一体化数据库及 OceanBase AI 原生数据库 seekdb 简化 Agentic RAG 部署。**
- **挑战:** 传统的 Agentic RAG 依赖关系型数据库 + 向量数据库 + 全文检索多个异构组件,导致运维复杂、数据同步困难、一致性风险高。
- **开源成果:** Dify 团队、顺丰 AI 技术平台组和 OceanBase 开源团队多方共同努力,Dify 正式兼容 MySQL 作为元数据存储,极大地便利了广大的 MySQL 技术栈用户。
- **一体化及 AI 原生数据库:** 引入 OceanBase 及 seekdb 利用其分布式数据库和 AI 原生能力,将业务元数据、语义向量和全文索引统一存储检索,实现数据层彻底精简,确保事务一致性,极大简化运维负担。
- **体验路径:** 推荐通过 OceanBase 开源的轻量嵌入式 seekdb 快速体验 AI 原生部署的优势,教程附后。
前言,AI 应用的冰山之下
大模型、Agentic RAG 和 Agent 这些词几乎天天刷屏。但别光顾着看热闹,真正落地的时候,绝大多数团队都会撞上一块“看不见的冰山”——底层数据架构过于复杂
系统越复杂,人力投入就越大,风险越高。
为什么三种数据形态缺一不可?
Agentic RAG 的核心在于让 Agent 学会“查资料”——通过检索(Retrieval)获取准确、相关的上下文(Context),从而增强推理和响应的可靠性,降低 AI 幻觉。 一个高质量的 Agentic RAG 系统,其 Retrieval 阶段需要处理三种不同的数据形态: - **业务元数据**:结构化数据,用于记录文档的基本信息、权限和应用配置,具备严格的事务安全能力。 - **语义向量**:用于密集检索,通过向量匹配实现语义和概念上的相似性查找,这是 Agent 理解上下文的关键。 - **词法索引**:用于稀疏检索,通过关键词匹配进行精确的文本查找。 为什么这三种数据形态缺一不可?因为一个智能体要应对各种查询场景,需要全方位的检索能力。单纯的语义检索(Dense Retrieval)擅长理解意图和概念关联,但遇到专有名词、特定 ID、精确短语或不常见关键词时,效果可能不如关键词匹配。而关键词检索(Sparse Retrieval)恰好能弥补这个不足,确保对精确信息的快速召回。 因此,为了实现最佳的召回率和相关性,现代 Agentic RAG 都在向混合搜索(Hybrid Search)演进:同时执行语义和关键词两种检索,再通过专业的 Re-ranking 模型对结果进行融合和二次排序。这种“多维度、后融合”的策略能更全面、更精准地筛选出最优质的 Context Chunks,从而给 LLM 提供最可靠的上下文,显著提升 Agent 的推理和决策质量
一体化数据库出现之前
Dify 传统以关系型数据库 + 向量数据库 + 全文检索组合为代表的架构,正是为了满足 Hybrid Search 需求而不得不采用的工程实现。然而,这一架构在实际运行中带来了巨大的工程复杂性: - **数据同步的挑战**:当一个新文档导入时,它的元数据、向量和词法索引需要在多个独立系统中同步写入。为此需要开发复杂的自定义数据管道,来协调写入、处理失败重试和数据回滚逻辑。 - **一致性保障的缺失**:这种跨系统的写入操作本质上是非事务性的。如果其中一个组件写入失败(例如网络抖动导致向量数据库写入超时),而其他组件成功,就会出现数据不一致。修复这种不一致性本身就是一项艰巨任务,并且直接影响 Agentic RAG 的可靠性。 - **应用层负担**:应用代码本身承担起协调查询、合并多个数据库结果的复杂逻辑,显著增加了代码的维护难度和成本。 - **运维负担**:运维团队需要掌握和维护多套不同技术栈的系统,包括独立的备份策略、监控告警、高可用集群配置、灾难恢复计划和版本升级流程。这不仅需要多领域专业知识,还极大地增加了开销和潜在的故障风险。Dify v1.10.1:迈向一体化数据库简化 Agentic RAG 部署
**迈向更广泛的兼容性** 11 月 26 日,Dify v1.10.1 正式发布,Dify 的元数据存储正式兼容了 MySQL 数据库。 > “作为业界领先的开源智能体平台之一,Dify 在国内企业应用中已获得广泛部署。然而,由于官方此前缺乏 MySQL 兼容支持,大多数企业被迫在源码层面进行定制改造,导致维护困难且难以及时反馈社区。” > ——顺丰 AI 技术平台组 为了降低 Dify 部署维护的复杂程度并解决 MySQL 兼容性问题,OceanBase 开源团队与顺丰 AI 技术平台组基于 OceanBase 强大的 SQL 兼容能力,联合完成了 Dify MySQL 兼容开发,为社区及企业用户提供开箱即用的解决方案,显著降低部署运维成本。 顺丰 AI 技术平台组和 OceanBase 开源团队在推动 Dify 增强 MySQL 兼容和落地一体化数据库工作中进行了共同努力和贡献,这可以让习惯使用 MySQL 技术栈的团队能够更平滑地接入 Dify。 **引入一体化数据库** 在解决了 MySQL 兼容性问题后,Dify 也开始思考更深层次的架构优化。OceanBase 在提供 MySQL 兼容性的同时,也具备将元数据、向量和全文索引能力集于一身的能力,这为解决多组件架构带来的扩展复杂性、实现架构简化提供了新的思路。因此,在这一版本中,Dify 开始尝试一体化数据库,并选择了 OceanBase 作为首个实践对象。  _本表由 OceanBase 基于公开资料整理,仅作能力示意_ OceanBase 是开源的分布式数据库,提供 AI 应用场景所需的海量向量处理、混合检索能力。通过引入 OceanBase,Dify 实现了数据层的彻底精简,将过去分散在三个异构系统中的能力(元数据、向量、全文索引)收敛到单一系统内,确保了写入的事务一致性和运维的极度简化。  **更轻量一体化的体验:Dify on seekdb** 为了让用户更便捷地体验这种一体化数据库带来的轻量化和一体化优势,推荐从 seekdb 开始。 seekdb 是 OceanBase 开源的 AI 原生轻量嵌入式数据库,专注于为 AI 应用提供高效的混合搜索能力,支持向量、全文及多模数据的统一存储与检索。以下是使用 seekdb 开启一体化数据库体验的详细步骤: **1. 配置 `.env` 文件,启用 seekdb** 首先,进入 Dify 的 `docker` 目录,准备配置环境变量。编辑 `.env` 文件: ```bash cd dify cd docker # 复制环境变量模板 cp .env.example .env # 设置数据库类型为 mysql, 并且修改元数据库连接信息 DB_TYPE=mysql DB_USERNAME=root DB_HOST=seekdb DB_PORT=2881 DB_DATABASE=test # 设置向量存储为 OceanBase VECTOR_STORE=oceanbase # 修改OCEANBASE的连接信息为seekdb的对应连接信息 OCEANBASE_VECTOR_HOST=seekdb OCEANBASE_VECTOR_USER=root # 修改 COMPOSE_PROFILES 为 seekdb COMPOSE_PROFILES=seekdb ``` **2. 启动服务** 配置完成后,使用 Docker Compose 启动所有服务。 ```bash # 启动所有服务 docker compose up -d ```  使用 `docker ps` 可以查看各个容器的状态,启动后应该能看到各个容器都正常启动。  `docker-api-1` 容器启动后会自动执行数据库初始化和迁移。通过查看 `api` 服务的日志,确认迁移成功。  至此,你的 Dify 实例已成功运行在 seekdb 上。现在可以创建知识库、导入文档并进行 RAG 检索。 在这一架构下,seekdb 将同时扮演以下角色: - **元数据库**:存储 Dify 的应用配置、用户数据等。 - **向量数据库**:存储文档向量和进行相似性搜索。 - **全文检索系统**:负责关键词检索,支撑 Hybrid Search 逻辑。    让注意力回归应用创新
Dify 与 OceanBase 的开源生态合作,尤其是对 OceanBase 的引入和兼容 MySQL,成功地将业务数据、向量数据和全文索引融合在一个高可用、具备事务一致性的单一系统中。 对工程团队而言,这意味着可以将更多注意力从繁重的运维和底层数据同步中解放出来,重新聚焦于 Agentic RAG 本身的应用创新和业务逻辑打磨。 Dify 与 OceanBase 希望通过未来更深度的合作,为全球开发者提供一个更简单、更可靠、更高效的 AI 应用开发环境,让智能体的构建真正进入“开箱即用”的时代。 **END**-
- 关于宇宙的好的网名有哪些
- 角色扮演 | 1
- 网名