Dify.AI是GitHub上排名第二的热门LLM工具，已经获得超过70000颗星标和630多位贡献者的支持。作为一款领先的开源大语言模型应用开发平台，它通过直观的可视化工作流，让企业无需深厚技术背景即可创建复杂的AI应用。
然而，随着平台用户规模的快速增长，Dify.AI在数据管理层面遭遇了严重的架构瓶颈。平台需要同时处理多种数据类型，从传统的关系型数据到向量嵌入，从文档存储到对话历史记录。其多租户架构迫使团队需要管理近五十万个隔离的数据库容器，每个容器对应一个开发者独特的数据集。
管理不同数据类型的独立数据库不仅复杂，还让团队无法专注于真正重要的事情：构建更好的AI应用。Dify.AI团队如此描述当时的困境。正是这种困境，驱动了一场深刻的数据架构重构。
一、重构前的架构困境
1.1 多租户架构下的数据容器爆炸
Dify.AI作为SaaS平台，需要为全球数千名开发者提供服务。每个开发者拥有独立的数据集，这意味着平台必须维护大量隔离的数据库实例。这种多租户架构在早期是合理的设计选择，但随着用户数量从数百增长到数万，数据库容器的数量呈指数级膨胀。
当数据库容器数量逼近五十万时，运维复杂性达到了临界点。每个容器都需要独立的监控、备份、升级和故障处理流程。一个简单的数据库版本升级，可能意味着需要协调数十万个实例的变更操作。运维开销已经严重侵蚀了团队投入到核心产品开发的精力。
容器数量的膨胀还带来了资源碎片化问题。每个容器即使处于空闲状态，也需要占用最低限度的计算和存储资源。当绝大多数容器在大部分时间处于低负载状态时，资源浪费变得极为严重。从成本角度看，为五十万个容器支付的基础设施费用，远远超过了实际业务所需的资源总量。
1.2 多种数据类型的割裂管理
GenAI平台的数据管理面临着传统应用所没有的复杂性。Dify.AI需要同时处理以下数据类型：
关系型数据方面，应用配置、用户信息、工作流定义、操作日志等结构化数据需要事务保证和实时访问。这些数据的特点是写入频繁、查询模式多样，对一致性和响应时间有较高要求。
向量嵌入方面，知识库文档经过分块和嵌入模型处理后生成的向量表示，用于语义相似性搜索。向量数据的规模通常很大，一个中等规模的知识库可能包含数百万个向量，每个向量数百维。
文档内容方面，用户上传的原始文档，包括PDF、Word、表格、图片等多种格式，需要存储和检索。这些非结构化数据的体积差异极大，从几KB的文本到数百MB的扫描件。
对话历史方面，用户与AI应用的交互记录，需要持久化存储以支持上下文管理和审计追踪。对话数据的写入频率极高，且需要按会话维度进行聚合查询。
在重构前，这些数据类型往往使用不同的存储系统。关系型数据可能存储在PostgreSQL中，向量数据使用专门的向量数据库如Pinecone或Weaviate，文档存储在对象存储中，对话历史则可能分散在多个缓存和数据库中。这种割裂的存储架构带来了数据同步的复杂性、跨存储查询的困难和运维成本的叠加。
数据同步的复杂性体现在多个层面。当用户上传文档并完成向量化处理后，文档元数据需要写入关系型数据库，向量需要写入向量数据库，原始文件需要上传到对象存储。这三个操作需要保持一致，任何一个环节的失败都可能导致数据不完整。跨存储查询同样困难，例如在检索时需要同时访问向量数据库获取语义匹配结果，再从关系型数据库获取文档元信息，两次查询之间的延迟和一致性问题难以避免。
二、重构的核心决策：选择TiDB作为统一存储层
2.1 为什么是TiDB
面对上述困境，Dify.AI团队做出了一个关键决策：使用TiDB作为整个平台的核心数据库，统一存储所有类型的数据。
TiDB是一个兼容MySQL协议的分布式SQL数据库，具备水平扩展能力和强一致性保证。对于Dify.AI而言，选择TiDB的核心原因在于其多模态数据处理能力的融合。
关系型与向量的统一支持是首要考量。 TiDB原生支持向量数据类型和向量索引，能够在同一张表中同时存储结构化字段和向量字段。这意味着Dify.AI不再需要维护独立的向量数据库，知识库的文档分块、嵌入向量和元数据可以在一个统一的表中管理。当用户查询知识库时，系统可以在单次SQL查询中完成向量相似性搜索和元数据过滤，大幅简化了检索逻辑。
分布式架构的弹性扩展是另一个关键因素。 TiDB的存储层TiKV采用Raft协议实现多副本一致性，计算层TiDB Server可以独立水平扩展。这种架构天然适配多租户场景，每个租户的数据可以通过分区或分表的方式隔离，但共享底层的存储资源。当某个租户的数据量或查询负载增长时，系统可以通过增加TiKV节点或调整TiDB Server的资源配置来应对，而无需为该租户单独部署新的数据库实例。
MySQL协议兼容是迁移成本的重要考量。 Dify.AI的许多现有代码和工具链基于MySQL协议构建，TiDB的高度兼容性意味着迁移成本大幅降低。应用的连接配置和查询语句几乎无需修改即可对接TiDB。这种兼容性还体现在生态系统层面，MySQL的客户端工具、ORM框架和监控方案都可以直接用于TiDB。
2.2 TiDB Cloud Serverless的选择
在部署形态上，Dify.AI选择了TiDB Cloud Serverless，即全托管的无服务器分布式数据库版本。
这个选择的关键考量在于运维开销的进一步降低。Serverless模式下，数据库的扩缩容由平台自动管理，Dify.AI团队无需关注底层节点的容量规划和运维操作。对于快速增长的SaaS平台，这种弹性能力意味着可以随业务流量自动调整资源，在用户增长期快速响应，在低谷期自动缩容以控制成本。
Serverless模式还解决了多租户场景下的资源隔离问题。传统方案中，为每个租户分配独立的数据库实例虽然隔离性最好，但资源利用率极低。共享数据库实例虽然资源利用率高，但隔离性不足。TiDB Cloud Serverless通过资源池化和动态分配机制，在隔离性和利用率之间取得了平衡。
三、统一存储架构的四层设计
重构后的Dify.AI数据架构分为四个层次，形成了从用户交互到AI应用输出的完整数据流。
3.1 用户交互层
用户交互层是架构的入口，提供简洁易用的界面供用户输入数据和查询指令。这一层负责处理用户的输入，包括自然语言文本、文档上传和参数配置，并将请求传递给下层的数据管道。
在Dify.AI的产品设计中，用户交互层包括应用编排界面、知识库管理界面和对话交互界面。应用编排界面允许用户通过拖拽节点的方式设计AI工作流，知识库管理界面支持文档上传和处理配置，对话交互界面则提供最终用户与AI应用交互的入口。这三个界面的所有数据操作最终都会落到下层的统一存储层。
3.2 Dify数据管道
数据管道是处理原始数据的核心环节。当用户输入数据后，信息进入Dify数据管道，系统从多种来源收集原始数据，包括文档、表格、列表和图像等，并进行一系列高级处理操作，包括分块处理和命名实体识别。这些步骤为数据生成嵌入向量做好准备，使其能够被AI应用所使用。
数据管道的设计理念体现了Dify.AI对RAG能力的深度思考。分块策略的选择、命名实体的提取质量，直接决定了后续检索和生成的准确性。在2.0版本中，Dify.AI进一步引入了知识管道，提供了模块化、可扩展的知识摄入和处理工作流，支持更灵活的文档处理编排。
分块策略是数据管道中最关键的决策之一。块太大，嵌入向量的信息密度被稀释，检索精度下降。块太小，语义单元被切碎，生成的答案缺乏上下文。Dify.AI支持多种分块策略，包括固定大小分块、按段落分块和按语义分块，用户可以根据文档类型和处理需求灵活选择。
命名实体识别在数据管道中扮演着补充角色。虽然向量检索擅长语义匹配，但在处理专有名词、产品型号和代码标识符等精确术语时存在短板。命名实体识别可以提取文档中的关键实体，为后续的混合检索提供关键词维度。
3.3 TiDB统一存储层
TiDB统一存储层是整个架构的核心。所有类型的数据，包括关系型数据、向量嵌入、文档内容和对话历史，均统一存储于TiDB中。这种统一存储的设计带来了几个关键优势。
事务性数据处理方面，TiDB高效处理事务性数据和实时数据，确保应用配置、用户状态等关键数据的准确性和及时性。TiDB的分布式事务支持ACID特性，在数据分片和副本分布的情况下依然能保证事务的一致性。
向量存储与检索方面，TiDB原生支持向量索引，为知识库中的文档嵌入提供高效的相似性搜索能力。这消除了独立向量数据库带来的数据同步延迟和运维复杂性。当用户上传文档并完成向量化处理后，文档元数据和向量可以在同一个事务中写入，保证了数据的完整性。
文档与对话历史存储方面，原始文档内容和对话历史记录统一存储在TiDB中，便于在检索时进行上下文关联，也简化了数据备份和恢复流程。对话历史与用户配置、应用定义的关联查询可以在单次SQL中完成，不需要跨存储系统拼接数据。
多租户数据隔离方面，TiDB通过分区表和行级权限控制，为每个租户提供逻辑隔离的数据空间，同时共享底层的存储和计算资源。这种设计既保证了租户间的数据安全，又避免了为每个租户独立部署数据库的资源浪费。
3.4 AWS基础设施层
系统依托AWS基础设施运行，充分利用EC2提供弹性计算能力，使用S3存储海量数据，使用EBS提供持久化存储。与AWS Bedrock的深度集成使Dify.AI能够访问多个LLM供应商的预训练模型，进一步提升外部知识服务能力。
在基础设施层面，Dify.AI的架构充分利用了云原生的弹性能力。EC2实例根据负载自动扩缩容，S3为文档和备份提供近乎无限的存储空间，EBS为数据库提供低延迟的持久化存储。这种云原生基础设施与TiDB Cloud Serverless的结合，使整个系统具备了从用户请求到数据存储的全链路弹性能力。
四、重构带来的量化收益
4.1 基础设施成本降低80%
通过将数十万个数据库容器整合至单一的TiDB Cloud，Dify.AI大幅削减了基础设施成本。不再需要为每个租户维护独立的数据库实例，存储和计算资源在多租户间共享，资源利用率显著提升。
成本的降低来自多个方面。实例数量的锐减直接减少了基础的计算和存储资源开销。资源池化使空闲容量可以被其他租户复用，避免了为每个租户预留峰值容量的浪费。自动扩缩容使系统在低谷期可以释放闲置资源，进一步优化成本结构。
4.2 运维开销减少90%
运维开销的降低来自多个层面。首先，数据库实例数量的锐减直接减少了监控、备份和故障处理的复杂性。管理五十万个数据库容器需要庞大的运维团队和复杂的自动化工具，而管理单一TiDB集群的运维复杂度大幅降低。
其次，TiDB Cloud Serverless的托管特性使扩容、版本升级等操作由平台自动完成，Dify.AI团队无需投入人力管理底层数据库运维。版本升级从协调数十万个实例的变更操作，简化为平台自动完成的一次升级。
第三，统一存储架构消除了多存储系统之间的数据同步和一致性维护工作。过去需要维护关系型数据库、向量数据库和对象存储之间的同步管道，现在只需要管理单一数据源。
4.3 开发效率与平台可扩展性提升
数据管理复杂性的降低使Dify.AI团队能够将更多精力投入到核心产品能力的构建上。统一的技术栈降低了开发人员理解和管理数据层的认知负担，新功能的开发和上线速度随之加快。
从平台可扩展性角度看，TiDB的分布式架构为Dify.AI的持续增长提供了坚实基础。随着用户数量和AI应用复杂度的提升，数据库可以通过增加TiKV节点或调整TiDB Server的资源配置来应对负载增长，而无需进行架构层面的重构。这种弹性能力对于SaaS平台尤为重要，因为用户增长的速度和规模难以精确预测。
4.4 用户体验的间接改善
基础设施的优化最终会反映到用户体验上。数据库响应时间的降低使知识库检索和对话生成的延迟缩短。系统稳定性的提升减少了服务中断和错误返回的概率。成本的降低为免费版用户提供了更大的使用额度，降低了用户尝试平台的门槛。
五、对AI应用平台数据架构的启示
Dify.AI的数据架构重构实践，为GenAI平台的数据管理提供了一条可借鉴的路径。
5.1 统一存储优于分散管理
在AI应用场景中，关系型数据、向量数据和文档数据的关联性极强。知识库检索需要同时访问文档元数据、分块内容和嵌入向量。对话管理需要关联用户信息、会话状态和历史记录。将这些数据分散在多个存储系统中，会带来跨系统查询的复杂性和一致性维护的困难。统一存储层能够在单一事务边界内处理这些关联操作，简化架构并提升数据一致性。
5.2 多模态数据库成为刚需
传统数据库只支持结构化数据，向量检索依赖专门的向量数据库。TiDB在关系型数据库基础上增加了向量数据类型和索引支持，使同一套系统能够同时处理结构化查询和语义检索。这种多模态能力对于AI应用平台而言，从可选项变成了刚需。
5.3 Serverless模式降低运维负担
对于快速增长的SaaS平台，数据库的弹性能力至关重要。Serverless模式将容量规划和资源调度交给云平台自动处理，使团队能够专注于业务逻辑而非基础设施运维。这种模式特别适合用户规模波动大、增长速度快、运维人力有限的初创团队和成长型企业。
5.4 数据架构决策需要前瞻性
Dify.AI的重构实践表明，数据架构的决策需要考虑未来三到五年的业务增长预期。在早期阶段选择的技术方案，可能在用户规模扩大十倍后成为制约发展的瓶颈。在架构设计初期就考虑到多租户隔离、弹性扩展和多模态数据支持的需求，可以避免后期昂贵的重构成本。
结语
Dify.AI基于TiDB的数据架构重构，是一次从工程实践出发的深度架构演进。从管理近五十万个隔离的数据库容器，到统一存储于单一TiDB Cloud，基础设施成本降低80%、运维开销减少90%的量化成果，验证了统一多模态存储架构在GenAI平台中的价值。
这次重构的核心启示在于：AI应用平台的数据层设计，需要同时满足关系型事务处理、向量语义检索、文档存储和对话历史管理的多重需求。选择一个能够统一承载这些数据类型的数据库系统，比在多个专用存储之间构建复杂的同步管道更为可持续。当数据基础设施从复杂回归简单，团队才能真正聚焦于构建更好的AI应用。
对于正在构建或计划构建AI应用平台的团队而言，Dify.AI的实践提供了一条清晰的路径参考：在架构设计初期就选择支持多模态数据的分布式数据库，通过统一存储层简化数据管理，利用Serverless能力降低运维开销。这条路径虽然不一定适用于所有场景，但对于用户规模快速增长、数据类型多样、运维人力有限的GenAI平台而言，具有重要的借鉴意义。