一文看懂 RAGFlow 四层存储：元数据、对象、检索、缓存如何协作

原文：​https://mp.weixin.qq.com/s/nJWQiXoSGbzqgk8uhPj2zQ

RAG往期文章推荐

RAG效果差？7个指标让你的准确率大幅提升

RAG评测完整指南：指标、测试和最佳实践

收藏！RAG核心工具大全: 7大解析工具+向量模型+数据库+检索排序

GraphRAG开源生态全景：6大主流开源项目，微软/蚂蚁/港大项目同台PK

RAG系列：#5 RAG中的11种分块策略

企业级落地方案：Docker 部署 CodeGraph 多项目统一 MCP 网关，附源码

一文搞定Gerrit/Gitee/GitHub MCP Server，实现开发全流程自动化

面向AIGC的检索增强生成综述

智能体化检索增强生成：智能体化 RAG 的综述

github: https://github.com/infiniflow/ragflow

RAGFlow 采用多存储分离架构，将结构化元数据、原始文件、检索索引、缓存与任务队列等不同职责拆分到独立存储组件中，各组件按需选型、独立扩展，并针对各自负载特征进行优化。其核心存储分工如下：

• 元数据库：存储结构化业务元数据，是系统状态与业务关系的核心承载。

• 对象存储：存储原始文件与解析产物等非结构化二进制数据。

• 文档/向量检索引擎：存储 chunk 文本与向量 Embedding，支撑全文检索、向量检索与混合召回。

• Redis：承担缓存、异步任务队列与分布式锁等临时状态管理。

在默认的 Docker Compose 部署方案中，RAGFlow 通常组合使用 MySQL + MinIO + Elasticsearch + Redis。同时，各存储组件并非绑定单一实现，而是支持按组件替换与组合，以适应不同部署环境、成本模型和技术栈偏好。例如：

• 元数据库可替换为 PostgreSQL、OceanBase 等；

• 对象存储可替换为 S3、OSS、Azure Blob、GCS 等；

• 文档/向量检索引擎可替换为 Infinity、OpenSearch、OceanBase、GaussDB 等；

• Redis 也可根据实际部署条件选择独立服务或托管服务。

因此，RAGFlow 的多存储分离架构不仅体现在不同存储各司其职，更体现在各组件可插拔、可替换、可组合的工程化设计上。这种架构既保证了默认部署的开箱即用，也为生产环境中的规模化、国产化、云原生化部署提供了灵活的存储选型空间。

MySQL（元数据数据库)

核心定位：结构化业务元数据存储，不存原始文件、不存向量。

存储内容：

• 用户、租户、知识库、文档记录、分片元信息、对话历史、API Key、系统配置、权限、任务状态等结构化数据。

能力：

• 提供事务与关系查询能力，维护知识库与文档之间的关联关系。

• 支撑权限校验、状态流转、配置读取等业务逻辑。

• 不保存：

  • 文件二进制内容、chunk 文本、向量 embedding。

可替换：PostgreSQL、OceanBase 等。

典型场景：

• 查询某知识库下有哪些文档、创建时间、权限归属；

• 保存问答对话记录与任务状态。

MinIO（对象存储）

核心定位：原始文件二进制存储。

存储内容：

• 用户上传的 PDF、Word、图片等原始文件；

• 解析后产生的图片、附件等资源。

能力：

• 提供 S3 兼容的对象存储能力，适合大文件与非结构化二进制数据；

• 支持多知识库引用同一份文件，避免重复存储。

可替换：S3、阿里云 OSS、Azure Blob、GCS 等。

特点：

• 文件上传后放入 MinIO；

• 解析时从 MinIO 读取原始文件；

• 删除知识库不会直接删除原始文件，文件管理由独立机制控制。

数据流：

• 上传文件 → 写入 MinIO → MySQL 记录文件元信息。

文档&向量引擎（Elasticsearch / Infinity / OpenSearch / OceanBase）

核心定位：chunk 文本 + 向量 Embedding 存储，混合检索（关键词 BM25 + 向量相似度），是 RAG 最核心的检索存储。RAGFlow 将其称为 Document Engine，它不是单纯的向量库，而是全文与向量混合引擎。

Elasticsearch（默认）

• 保存内容：

  • 文档切分后的 chunk 文本、BM25 倒排索引、向量 embedding。

• 能力：

  • 全文关键词检索、向量检索、短语匹配、复合排序、hybrid 检索。

Infinity（InfiniFlow自研，推荐高性能RAG场景）

• AI 原生数据库，同时支持稠密向量、稀疏向量、全文检索；

• 针对 RAG 场景优化，向量检索性能优于 ES。

OpenSearch

• ES分支，功能接近，可替换ES

OceanBase/GaussDB

• 国产数据库，支持向量能力，适合国产化部署

检索流程：

• 用户提问 → 向量化 → 在引擎内同时做BM25关键词+向量召回 → rerank → 返回相关片段

Redis

核心定位：缓存 + 异步任务队列 + 分布式锁。

任务队列：

• 文档解析、OCR、切分、Embedding 生成等异步任务（Celery broker）；

• 文件上传后，解析任务丢进 Redis 队列，由 worker 消费。

缓存：

• 临时缓存模型结果、检索结果、会话临时数据，减少数据库压力。

分布式锁：

• 多实例部署时防止任务重复执行。

特点：

• 不持久化业务数据，属于临时状态存储。

完整数据流

1. 用户上传 PDF → 文件二进制存入 MinIO；文件元信息记录到 MySQL。

2. 解析任务推入 Redis 队列。

3. Worker 读取 MinIO 原始文件，进行解析、切分、生成 Embedding。

4. Chunk 文本 + 向量写入 ES / Infinity。

5. 用户提问：查询进入 RAG → 在 ES / Infinity 混合召回 chunk → 交给 LLM 生成答案；对话记录写入 MySQL。

架构总结

组件	存储内容	核心作用	是否持久化业务数据
MySQL	用户/知识库/对话/文档元数据	业务关系、权限、对话记录	是
MinIO(S3)	PDF/Word/图片原始文件	二进制文件持久化	是
ES/Infinity	chunk文本、向量、倒排索引	混合检索（关键词+向量）	是
Redis	任务队列、临时缓存、锁	异步任务调度、缓存	默认内存，持久化可选

RAGFlow 的多存储分离架构，本质上是按数据形态与访问模式进行职责拆分：

• MySQL 管结构化元数据与业务关系；

• MinIO 管原始文件与二进制资源；

• ES/Infinity 管 chunk 文本、向量与混合检索；

• Redis 管缓存、队列与分布式协调。

这种设计使各组件能够独立扩展、按需替换，既保证了默认部署的开箱即用，也为生产环境中的规模化、国产化、云原生化部署提供了灵活的存储选型空间。