背景
管理的现状：数据孤岛，滞后，效率低
技术实现：
- 文件监控：Python脚本监控共享文件夹
- 数据解析：Pandas库读取多Sheet的Excel
- 数据清洗：处理空值、统一格式、关联数据
- 数据存储：PostgreSQL 建立历史数据湖
| 数据库名称 | 支持的数据类型（Dify 相关） | 推荐/最低版本 | 数据库类型 | 优点 | 缺点 | 是否被 Dify 官方支持 | 适用场景（在 Dify 中） |
|---|---|---|---|---|---|---|---|
| SQLite | 基础类型（TEXT, INTEGER 等），不支持 JSONB、ARRAY、UUID、向量类型 | 任意（但无意义） | 文件型嵌入式数据库 | • 零配置，单文件部署 • 适合本地轻量工具或测试脚本 | • 写操作全局锁 ，无法并发 • 不支持 Dify 所需的 PostgreSQL 特有类型 • 无用户管理、网络访问、高可用机制 • 无法作为向量数据库（即使使用扩展如 sqlite-vss，性能极差） | 不支持 | 仅可用于与 Dify 无关的本地原型验证；不可用于 Dify 任何组件 |
| Hive | 结构化/半结构化数据（通过 HiveQL），不支持向量类型或高效相似度搜索 | Hive 3.x（支持 ACID） | 分布式数据仓库（基于 Hadoop） | • 适合 PB 级离线批处理 • 与 Hadoop 生态无缝集成 • 可存储大量静态文本/日志 | • 查询延迟高 （秒~分钟级） • 不支持实时事务或行级更新 • 无原生向量索引或 ANN 检索能力 • 无法满足 Dify 元数据或 RAG 的低延迟要求 | 不支持 | 可作为外部数据源： • 导出静态知识 → 上传至 Dify 知识库 • 通过 Custom Tool + 中间 API 间接查询聚合结果 |
| MySQL | 基础类型 + JSON（8.0+），不支持 JSONB、ARRAY、原生向量类型 | 8.0+（需 InnoDB 引擎） | 关系型数据库（C/S 架构） | • 部署简单，社区广泛 • 高并发读性能优秀 • 与 Web 应用（LAMP）深度集成 • 支持基本事务（InnoDB） | • Dify 未官方适配：代码依赖 PostgreSQL 特性（如 JSONB、GIN 索引） • JSON 查询效率低于 JSONB • 向量支持弱（8.0+ 有 VECTOR 类型但生态不成熟） | ⚠️ 部分社区尝试（生产环境不推荐） | 理论上可尝试作为元数据存储，但存在兼容性风险；不能用于向量检索 |
| PostgreSQL | 完整支持 Dify 所需类型 ： • JSONB（可索引） • UUID • ARRAY • 自定义类型 • 通过 pgvector 支持 VECTOR |
≥ 12（推荐 14+） | 对象-关系型数据库（功能强大） | • Dify 官方唯一推荐元数据数据库 • 完整 ACID + MVCC，高并发写友好 • JSONB 高效存储与查询 • 通过 PGVector 扩展可直接作为向量数据库（减少组件） • 支持函数、触发器、扩展（如 PostGIS） • 开源协议宽松（BSD） |
• 简单高频读略慢于 MySQL（可通过缓存优化） • 内存/CPU 占用略高（但现代硬件可忽略） | ✅ 完全支持 • 元数据存储（必须） • 向量存储（通过 PGVector） | • Dify 默认部署方案的核心 • 适用于所有场景：开发、测试、生产 • 尤其适合需要 RAG + 结构化数据一体化的场景 |