深入解读大模型开发工具Dify--底层数据存储

PowerData

以下文章来源于DataSpeed ，作者张文慧

[

DataSpeed .

慢慢积累，稳稳前行，用数据说话，为成长助力

](#)

导读：

在探索 Dify 这个大模型开发工具时，了解其底层数据存储方式至关重要。这不仅关系到系统的性能、可扩展性和稳定性，还直接影响到数据管理、安全性以及如何优化应用的使用体验。

一、为什么要了解 Dify 的底层数据存储？

1. 性能优化：清楚数据存储架构，有助于理解 Dify 在处理大规模数据（如对话记录、知识库、缓存等）时的效率，并能针对性地优化查询和存取速度。
2. 数据安全：存储方式决定了数据加密、访问控制和合规性策略，影响敏感信息的保护能力。
3. 故障排查：当遇到问题时，了解底层数据存储可以更快地定位故障，例如数据库连接失败、索引异常或查询超时等问题。
4. 扩展性与集成：如果希望将 Dify 与现有业务系统对接，如企业知识库、CRM、ERP等，熟悉其存储结构有助于高效整合数据资源。
5. 成本控制：存储架构直接影响存储成本，例如数据库选择、存储介质优化等，有助于做出更具成本效益的技术决策。

在接下来的内容中，我们将深入探讨 Dify 的底层数据存储架构，包括使用的数据库类型、数据组织方式以及如何优化存储策略，以便更好地利用这个强大的 AI 开发工具。

根据dify的服务，在数据层面有postgresql、redis、文件存储 storage、向量数据库存储vector，下面以此展开。

二、dify-postgresql

2.1 postgresql连接

在Dify中，postgresql默认的连接信息如下：

DB_USERNAME=postgres DB_PASSWORD=difyai123456 DB_HOST=db DB_PORT=5432 DB_DATABASE=dify

如果你使用的是docker安装方式，则在 dify/docker/ 中的 .env文件里找pg的连接信息。

如果你使用的是官方所说的 源码+docker的模式， 则在则在 dify/docker/ 中的 middleware.env文件里找pg的链接。

如果想在安装时，使用自己的pg数据库，也只需要修改dify/docker/ 中的 .env文件里修改pg的连接信息。

2.2 postgresql重点表简介

dify在使用pg时，使用了两个库dify与dify\_plugin 。

2.2.1 postgresql-dify库

在dify库中有74张表，下面挑一些重点表来聊一聊。

用户相关

• accounts 所有的用户信息

apps相关

• api\_requests
• api\_tokens  所有app的token相关信息，与下面的apps表对应 。
• app\_annotation\_hit\_histories   记录每个app的标注命中历史，需要开启app的标注[1]并命中才会有记录。
• app\_annotation\_settings  每个app的标注回复与设置。
• app\_dataset\_joins   记录app与知识库dataset 的对应关系。
• app\_model\_configs  记录每个app的设置，如model、input、prompt、dataset\_configs、创建与更新用户等。
• apps  记录每个app的信息，包含名称、模型、图标、工作流、状态等。
• installed\_apps  所有的app信息。
• sites  工作室里所有的应用包含agent、workflow等。

知识库相关

• child\_chunks  在知识库中使用父子分段模式下，记录了数据集、文档、段落、段落内容、索引id、索引哈希值。
• conversations  记录所有的对话，对话的名称、使用模型、input、对话方式、对话用户等信息。
• dataset\_collection\_bindings   记录每个知识库使用的推理模型、嵌入模型、向量索引
• dataset\_process\_rules  记录每个知识库的规则信息。
• dataset\_queries   针对知识库的对话记录。
• datasets  记录每个知识库的设置信息，如：名称、向量库、索引相关信息、模型信息、向量检索配置等。
• document\_segments   id与 child\_chunks 表的 segment\_id 字段对应。
• documents  所有的文档信息，包含：所属的知识库、文档在知识库里使用的分段模式、文档语言等。

模型相关

• providers  模型信息，详细表对应到 provider\_model\_settings与provider\_models表。

工作流相关

• workflow\_node\_executions 工作流每个节点的运行日志，包含每个节点运行的输入/输出、运行状况等。
• workflow\_runs  与 workflow\_node\_executions 表的 workflow\_run\_id 字段对应。

工具相关

• tool\_builtin\_providers  工具的具体信息。
• tool\_model\_invokes  工具与模型的调用信息。

其他

• messages  所有的对话和app的交互信息，使用的模型信息、对话id、对话记录信息、使用的tokens、对应的app\workflow信息，对话的上一个id(id=parent\_message\_id) 等。
• tenants  工作室的相关信息。

2.2.2 postgresql-plugin库

plugin库共10个库，挑几个可能会用得到的表来聊聊。

• ai\_model\_installations 模型工具插件
• plugin\_declarations 所有的查询信息，包括查询名称、版本、提供商、描述等。
• plugins  所有的插件。

三、dify-redis

与postgresql的信息相似，链接信息在 dify/docker/ 中的 .env文件里找，或在dify/docker/ 中的 middleware.env文件里  。默认链接信息如下：

REDIS_HOST=redis REDIS_PORT=6379 REDIS_USERNAME= REDIS_PASSWORD=difyai123456 REDIS_USE_SSL=false REDIS_DB=0

redis的里信息不多，大致如下：

• 登录用户的token
• 模型这个工具的api key

TIPS：使用docker部署redis时，端口没用被暴露出来，需要手动修改 docker-compose.yaml文件。

四、dify-storage

dify支持五种文件存储，包括 local（默认）、s3、azure-blob、huawei-obs、volcengine-tos 。

如果需要修改，则需要改成相应的配置，如下：

• local（默认）

本地文件存储，若选择此项则需要设置下方 STORAGE_LOCAL_PATH配置。

• s3

S3 对象存储，若选择此项则需要设置下方 S3\_ 开头的配置。

• azure-blob

Azure Blob 存储，若选择此项则需要设置下方 AZURE\_BLOB\_ 开头的配置。

• huawei-obs

Huawei OBS 存储，若选择此项则需要设置下方 HUAWEI\_OBS\_ 开头的配置。

• volcengine-tos

Volcengine TOS 存储，若选择此项则需要设置下方 VOLCENGINE\_TOS\_ 开头的配置。

默认为 storage，即存储在当前目录的 storage 目录下。若使用 Docker 或 Docker-compose 进行部署，请务必将两个容器中 /app/api/storage 目录挂载到同一个本机目录，否则可能会出现文件找不到的报错。

文件存储类型包括 images、privkeys、upload\_files 。

五、dify-vector

5.1 weaviate向量库连接

想要链接dify的weaviate向量数据库，需要把weaviate的端口释放出来，修改docker-compose.yaml ，找到关于weaviate的服务，修改如下。注意我这里接口使用的时8090代替8080，避免端口冲突。

 weaviate:     image:semitechnologies/weaviate:1.19.0     profiles:       -''       -weaviate     restart:always     volumes:       # Mount the Weaviate data directory to the con tainer.       -./volumes/weaviate:/var/lib/weaviate     environment:       # The Weaviate configurations       # You can refer to the [Weaviate](https://weaviate.io/developers/weaviate/config-refs/env-vars "Weaviate") documentation for more information.       PERSISTENCE_DATA_PATH:${WEAVIATE_PERSISTENCE_DATA_PATH:-/var/lib/weaviate}       QUERY_DEFAULTS_LIMIT:${WEAVIATE_QUERY_DEFAULTS_LIMIT:-25}       AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED:${WEAVIATE_AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED:-true}       DEFAULT_VECTORIZER_MODULE:${WEAVIATE_DEFAULT_VECTORIZER_MODULE:-none}       CLUSTER_HOSTNAME:${WEAVIATE_CLUSTER_HOSTNAME:-node1}       AUTHENTICATION_APIKEY_ENABLED:${WEAVIATE_AUTHENTICATION_APIKEY_ENABLED:-true}       AUTHENTICATION_APIKEY_ALLOWED_KEYS:${WEAVIATE_AUTHENTICATION_APIKEY_ALLOWED_KEYS:-WVF5YThaHlkYwhGUSmCRgsX3tD5ngdN8pkih}       AUTHENTICATION_APIKEY_USERS:${WEAVIATE_AUTHENTICATION_APIKEY_USERS:[e-mail]}       AUTHORIZATION_ADMINLIST_ENABLED:${WEAVIATE_AUTHORIZATION_ADMINLIST_ENABLED:-true}       AUTHORIZATION_ADMINLIST_USERS:${WEAVIATE_AUTHORIZATION_ADMINLIST_USERS:[e-mail]}     ports:        -8090:8080        -50051:50051

这里需要注意AUTHENTICATION_APIKEY_ALLOWED_KEYS参数，他是后面要用的api key。

修改后要重启docker

docker compose up -d docker compose down

先后curl的方式验证一下是否正常

curl -X GET http://YOUR_IP:8090/v1/schema \ -H "Authorization: Bearer YOUR_API_KEY"

返回一些class就说明时正常的。

url地址 http://YOUR_IP:8090/v1/docs ,验证一下是否可用。

5.2 weaviate向量库内容

下面使用python来进行交互，比较方便。

首先需要安装依赖

pip install weaviate # weaviate-client 的版本有要求，3.21.X系列 pip install weaviate-client==3.21.0

weaviate python连接demo

import weaviate # 你的 Weaviate API 服务器地址 WEAVIATE_URL = "http://YOUR_IP:8090" # 你的 API Key API_KEY = "YOUR_API_KEY" # 创建 Weaviate 客户端，带上 API Key 进行认证 client = weaviate.Client(     url=WEAVIATE_URL,     auth_client_secret=weaviate.AuthApiKey(API_KEY)  # 认证方式：API Key ) # 测试连接是否成功 if client.is_ready():     print("Weaviate 连接成功！") else:     print("Weaviate 连接失败！请检查 API Key 和服务器状态。") # 获取 Weaviate 的 Schema（测试查询） schema = client.schema.get() print("Weaviate Schema:", schema)

如果你对某个class里具体的数据感兴趣，你可以试试下面的代码

import weaviate # 查看某个class的具体向量数据 # 你的 Weaviate API 服务器地址 WEAVIATE_URL = "http://YOUR_IP:8090" # 你的 API Key API_KEY = "YOUR_API_KEY" # 创建 Weaviate 客户端，带上 API Key 进行认证 client = weaviate.Client(     url=WEAVIATE_URL,     auth_client_secret=weaviate.AuthApiKey(API_KEY)  # 认证方式：API Key ) # 查询某个 Class（如 "Book"）的所有向量数据 result = client.query.get("YOUR_VECTOR_INDEX", ["text", "document_id"]).with_additional(["vector"]).do() # 打印结果 print(result)

5.3 weaviate向量库结论

在pg datasets表 随着知识库增加一条数据，index\_struct字段记录向量库的内容，内容与向量库中的class对应。

除非采用经济模式。

dify的知识库开启父子分段时 会向向量数据库中增加一个class，也就是说每个知识库是独立的。

关于知识库-PG-向量数据库的内容，后面会单独写一篇知识库的原理文章。  关注公众号 DataSpeed 能够第一时间获取最近内容。

如果你有兴趣，或者已经在用Dify了，欢迎添加作者微信，我们组织了一个Dify交流群，欢迎来提问或者分享你的经验。

六、总结与思考

6.1 技术总结

通过对 Dify 底层数据存储的深入分析，我们可以得出以下技术要点：

1. 多类型数据库协同：Dify 采用了 PostgreSQL、Redis、文件存储和向量数据库的多层次存储架构，实现了数据的高效管理与快速访问。
2. 数据隔离与安全：通过 dify 和 dify\_plugin 两个独立数据库的设计，确保了核心数据与插件数据的有效隔离，提升了系统的安全性。
3. 灵活部署配置：支持 Docker 部署和源码部署两种模式，通过环境变量配置数据库连接信息，提供了高度的部署灵活性。
4. 性能优化机制：结合 Redis 的缓存机制和 PostgreSQL 的事务处理能力，实现了系统的高性能运行。

6.2 意义总结

理解 Dify 的底层数据存储具有重要的实践意义：

1. 系统优化：为开发者提供了优化系统性能的理论基础，特别是在大规模数据处理场景下。
2. 安全防护：明确了数据存储的安全机制，有助于制定更完善的数据保护策略。
3. 扩展集成：为系统功能扩展和第三方集成提供了技术指导，支持更广泛的应用场景。
4. 成本控制：通过理解存储架构，可以制定更合理的资源分配方案，降低运营成本。

6.3 发展思考

面向未来，Dify 的数据存储架构可能需要关注以下发展方向：

1. 云原生支持：探索与云原生技术的深度融合，提升系统的可扩展性和弹性。
2. 新型存储技术：考虑引入时序数据库等新型存储技术，满足特定场景下的数据存储需求。
3. 智能化管理：开发智能化的数据管理工具，实现存储资源的自动化优化。
4. 合规性保障：持续关注数据存储相关的法律法规变化，确保系统的合规性。

总的来说，Dify 的底层数据存储架构体现了现代 AI 开发平台的技术特点，其设计思路和技术选型为类似系统的开发提供了有价值的参考。随着技术的不断演进，持续优化数据存储架构将是提升系统竞争力的关键。

引用链接

[1] 

标注: https://docs.dify.ai/zh-hans/...

关于作者

作者重视实战与理论的结合，文章干货满满，有较为丰富的平台、数开经验，欢迎和作者一起交流，共同进步。

DataSpeed聚焦"大数据+AI"实战与资讯，技术干货和行业消息一网打尽。期待与你同行，欢迎扫码添加作者微信。

关于社区

PowerData社区是由一群数据从业人员，因为热爱凝聚在一起，以开源精神为基础，组成的数据开源社区。

社区群内会定期组织模拟面试、线上分享、行业研讨（涉及金融、医疗、能源、工业、互联网等）、线下Meet UP、城市聚会、求职内推等。同时，在社区群内您可以进行技术讨论、问题请教，届时更多志同道合的数据朋友。

社区整理了一份每日一题汇总及社区分享PPT，内容涵盖大数据组件、编程语言、数据结构与算法、企业真实面试题等各个领域，帮助您自我提升，成功上岸。可以添加作者微信（zwhuihuiz），进入PowerData官方社区群。 

往期推荐

大模型开发工具Dify-入门篇

SearXNG私有化部署与Dify集成指南