在探索 Dify 这个大模型开发工具时,了解其底层数据存储方式至关重要。这不仅关系到系统的性能、可扩展性和稳定性,还直接影响到数据管理、安全性以及如何优化应用的使用体验。
一、为什么要了解 Dify 的底层数据存储?
- 性能优化:清楚数据存储架构,有助于理解 Dify 在处理大规模数据(如对话记录、知识库、缓存等)时的效率,并能针对性地优化查询和存取速度。
- 数据安全:存储方式决定了数据加密、访问控制和合规性策略,影响敏感信息的保护能力。
- 故障排查:当遇到问题时,了解底层数据存储可以更快地定位故障,例如数据库连接失败、索引异常或查询超时等问题。
- 扩展性与集成:如果希望将 Dify 与现有业务系统对接,如企业知识库、CRM、ERP等,熟悉其存储结构有助于高效整合数据资源。
- 成本控制:存储架构直接影响存储成本,例如数据库选择、存储介质优化等,有助于做出更具成本效益的技术决策。
在接下来的内容中,我们将深入探讨 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的标注并命中才会有记录。
- 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) 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:-hello@dify.ai}
AUTHORIZATION_ADMINLIST_ENABLED: ${WEAVIATE_AUTHORIZATION_ADMINLIST_ENABLED:-true}
AUTHORIZATION_ADMINLIST_USERS: ${WEAVIATE_AUTHORIZATION_ADMINLIST_USERS:-hello@dify.ai}
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 能够第一时间获取最近内容。
六、总结与思考
6.1 技术总结
通过对 Dify 底层数据存储的深入分析,我们可以得出以下技术要点:
- 多类型数据库协同:Dify 采用了 PostgreSQL、Redis、文件存储和向量数据库的多层次存储架构,实现了数据的高效管理与快速访问。
- 数据隔离与安全:通过 dify 和 dify_plugin 两个独立数据库的设计,确保了核心数据与插件数据的有效隔离,提升了系统的安全性。
- 灵活部署配置:支持 Docker 部署和源码部署两种模式,通过环境变量配置数据库连接信息,提供了高度的部署灵活性。
- 性能优化机制:结合 Redis 的缓存机制和 PostgreSQL 的事务处理能力,实现了系统的高性能运行。
6.2 意义总结
理解 Dify 的底层数据存储具有重要的实践意义:
- 系统优化:为开发者提供了优化系统性能的理论基础,特别是在大规模数据处理场景下。
- 安全防护:明确了数据存储的安全机制,有助于制定更完善的数据保护策略。
- 扩展集成:为系统功能扩展和第三方集成提供了技术指导,支持更广泛的应用场景。
- 成本控制:通过理解存储架构,可以制定更合理的资源分配方案,降低运营成本。
6.3 发展思考
面向未来,Dify 的数据存储架构可能需要关注以下发展方向:
- 云原生支持:探索与云原生技术的深度融合,提升系统的可扩展性和弹性。
- 新型存储技术:考虑引入时序数据库等新型存储技术,满足特定场景下的数据存储需求。
- 智能化管理:开发智能化的数据管理工具,实现存储资源的自动化优化。
- 合规性保障:持续关注数据存储相关的法律法规变化,确保系统的合规性。
总的来说,Dify 的底层数据存储架构体现了现代 AI 开发平台的技术特点,其设计思路和技术选型为类似系统的开发提供了有价值的参考。随着技术的不断演进,持续优化数据存储架构将是提升系统竞争力的关键。