AI 应用的数据库架构：按数据类型选技术

一、关系型库：记录主库

对绝大多数 AI 产品，最安全、省心的起点是一个支持事务与约束的关系型库，作为默认记录主库。

适用场景：租户与用户身份、计费与权益（订阅、配额）、智能体运行与任务状态、工具审批与审计日志、对话元数据（非消息体本身）、文档归属与访问策略、评测结果。

灵活用法：可用 JSON 列存供应商元数据，而不破坏关系保证。具体托管方案选型，可参照主流云厂商的关系型产品评估。

二、文档库：整存整取的对象

文档库适合"整存整取、结构差异大"的对象，而非所有 JSON。

适用场景：差异显著的源对象（不同供应商原始回执）、集成载荷（Webhook、第三方事件）、执行轨迹（单次运行全量上下文）。

误用警告：不要仅因模型输出是 JSON 就选文档库；当对象之间关联频繁、需要联表约束时，关系型表达更清晰。

三、向量检索：索引而非正本

嵌入是衍生搜索索引，不是权威副本。权限控制必须在取数前完成，向量库只回答"哪些分块最相关"。

一条向量记录需包含：嵌入向量与模型/版本标识、源文档与分块标识、租户或访问范围、内容版本或校验和、时间戳与删除态。

规模建议：中小 RAG 可用关系型向量扩展；大规模再上专用向量库。源文档与权限须外置，以便索引可重建。普通全文搜索用关系型全文索引已够，不必急着上向量库。

四、对话与智能体状态：持久与临时分离

把状态显式拆开，才能避免重试把世界搞乱。

状态三分：持久（消息、审批、工具结果）、临时（令牌、锁、短计划）、衍生（摘要、嵌入、缓存）。状态显式版本化，用幂等键或乐观锁防重试误操作。单用户本地可用轻量级嵌入式数据库；一旦有并发，需引入可靠的协调组件。

五、缓存与协调：短生命周期

内存数据库在短时协调中价值明显，但绝不是正本。

适用场景：响应缓存、限流计数、任务租约、流状态、可丢短队列。

禁忌与键规：不可作为审批、账单、审计的唯一副本；键须带租户与版本。同类组件的权衡应结合吞吐与持久化需求评估。

六、队列与审计：异步可追溯

后台推理与摄取靠队列解耦。队列需具备投递语义、重试与死信；数据库队列表够用则不必上专用。审计要素：发起者、模型工具、审批、数据源、回退、结果与成本；存引用与脱敏而非秘文，存储难篡改。

七、起步分层与添系统原则

多数 AI SaaS 的实用分层：①关系库管核心（用户、任务、权限、对话、审计）；②对象存储管原件；③向量索引管分块；④内存库管缓存与短协调；⑤队列管慢任务。仅当度量负载需要才加库。

好架构让正本清晰、索引可重建、动作可归因。若追求"一套系统收敛关系、文档、向量、内存与队列"，可考虑以具备完整能力栈的云数据库（如腾讯云数据库）为底座，减少多系统拼接带来的运维与一致性负担。

决策速查