给 Dify 架构做“减法”，Dify × OceanBase 解锁一体化数据库

推荐语

Dify 与 OceanBase 强强联合，简化 AI 应用数据库架构，让开发更高效稳定！

核心内容：
1. 传统 Agentic RAG 面临的数据库架构复杂性问题
2. Dify 与 OceanBase 合作实现一体化数据库解决方案
3. 新架构带来的运维简化与性能提升优势

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

荐语：

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 等 AI 前沿技术几乎吸引了所有目光。但无论是在测试环境还是生产环境，绝大多数团队在真正落地 AI 应用时，都会撞上一块“看不见的冰山”：底层数据架构过于复杂。

对于 Dify 这样的 LLM 应用开发平台而言，要实现 RAG 检索、知识库管理和 Agent 工作流等核心功能，传统路径上依赖多个异构数据组件，构成一个复杂的“分布式数据库集群”。

在典型实践中，为了支撑测试环境和生产环境的稳定运行，你往往需要同时管理和协调以下几大组件：

• 关系型数据库，主要用于存储用户、应用配置、Agent 任务状态、知识库文档的元数据，这些是强事务性、结构化的业务数据。

  
  

• 向量数据库，负责存储 Context Chunks 经过 Embedding Model 向量化后的高维向量。这是实现语义搜索的基础，让 Agent 能理解文本的深层含义。

  
  

• 全文检索，负责构建知识库内容的倒排索引，以支持基于关键词的稀疏检索。这保证了用户或 Agent 能进行精确的文本匹配或模糊搜索。

这些组件各自在其领域内都是成熟、专业的产品方案。但一旦被组合成一个应用的数据层，随之而来的就是巨大的运维压力和成本。你需要为每套系统独立管理备份、升级、监控。任何一个环节出问题，都可能导致整个 Agentic RAG 链路的全局性故障。系统越复杂，人力投入就越大，风险越高。

Dify 的核心价值是让 AI 应用开发“化繁为简”。但复杂的数据库架构恰恰与这个目标相悖。

为什么三种数据形态缺一不可？

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 兼容性问题，OceanBase 开源团队与顺丰 AI 技术平台组基于 OceanBase 强大的 SQL 兼容能力，联合完成了 Dify MySQL 兼容开发，为社区及企业用户提供开箱即用的解决方案，显著降低部署运维成本。

顺丰 AI 技术平台组 和 OceanBase 开源团队 在推动 Dify 增强 MySQL 兼容和落地一体化数据库工作中进行共同努力和贡献，这可以让习惯使用 MySQL 技术栈的团队能够更平滑地接入 Dify。

引入一体化数据库

在解决了 MySQL 兼容性问题后，Dify 也开始思考更深层次的架构优化。OceanBase 在提供 MySQL 兼容性的同时，也具备将元数据、向量和全文索引能力集于一身的能力，这为解决多组件架构带来的 Scale 复杂性、实现架构简化提供了新的思路。因此，在这一版本中，Dify 开始尝试一体化数据库，并选择了 OceanBase 作为首个实践对象。

本表由 OceanBase 基于公开资料整理，仅作能力示意

OceanBase 是开源的分布式数据库，提供 AI 应用场景所需的海量向量处理、混合检索能力，通过引入 OceanBase，Dify 实现了数据层的彻底精简，将过去分散在三个异构系统中的能力（元数据、向量、全文索引）收敛到单一系统内，确保了写入的事务一致性和运维的极度简化。

更轻量一体化的体验

为了让用户更便捷地体验这种一体化数据库带来的轻量化和一体化优势，我们推荐从 seekdb 开始。

seekdb 是 OceanBase 开源的 AI 原生轻量嵌入式数据库，专注于为 AI 应用提供高效的混合搜索能力，支持向量、全文及多模数据的统一存储与检索。以下是使用 seekdb 开启一体化数据库体验的详细步骤：

1. 配置 .env 文件，启用 seekdb 配置文件

首先，进入 Dify 的 docker 目录，准备配置环境变量。编辑 .env 文件，进行环境变量配置：

cd difycd docker
# 复制环境变量模板cp .env.example .env
# 设置数据库类型为 mysql, 并且修改元数据库连接信息DB_TYPE=mysqlDB_USERNAME=rootDB_HOST=seekdbDB_PORT=2881DB_DATABASE=test
# 设置向量存储为 OceanBaseVECTOR_STORE=oceanbase
# 修改OCEANBASE的连接信息为seekdb的对应连接信息OCEANBASE_VECTOR_HOST=seekdbOCEANBASE_VECTOR_USER=root
# 修改 COMPOSE_PROFILES 为 seekdbCOMPOSE_PROFILES=seekdb

2. 启动服务

配置完成后，使用 Docker Compose 启动所有服务。

# 启动所有服务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 应用开发环境，让智能体的构建真正进入“开箱即用”的时代。