关系型数据库

关系型数据库适合用户账户、订单记录等结构固定的场景，非关系型数据库适合内容管理、实时日志等数据结构多变的场景

图数据库将关系作为一等公民存储，使多跳关系查询可通过图遍历算法在毫秒级完成，无需执行代价高昂的多表JOIN操作

向量数据库相比传统关系型数据库，存储和查询开销更高，且通常按向量维度、索引规模和查询次数计费。

对于刚开始构建AI应用的团队，从已有的关系型数据库加向量扩展起步是风险最低的选择；对于检索规模已明确达到亿级以上且以语义召回为核心的团队，专用向量数据库的性能优势值得承担额外运维复杂度。

数十年技术债、脆弱的代码依赖关系和僵硬的关系型数据库，使遗留系统在支撑实时数据摄入、向量索引和低延迟API交互时力不从心。

关系型数据库虽然支持JOIN，但在深度可变的多跳路径查询上需要递归CTE，性能和表达力都不如图数据库。

传统关系型数据库表达多跳关联需要多次JOIN操作，且随着关联深度增加性能急剧下降；图数据库将关系作为一等公民存储，多跳查询延迟与路径长度近似线性。

递归 SQL 在多跳查询时每一跳都需要对同一张大表做自连接，中间结果随深度指数膨胀，并伴随临时表、排序和哈希索引开销。

传统关系型数据库用乐观锁（版本号比对）或悲观锁（行级锁定）来防止丢失更新问题。

Agent记忆系统更合理的做法往往是混合架构：结构化元数据存关系库，语义内容用向量索引辅助检索，再通过规则过滤决定信息回流

结构化过滤是基于关系型数据库中已有的列（如合同编号、客户 ID、日期、状态字段）做等值或范围查询，本质是 WHERE 子句。

B-tree索引在关系型数据库中广泛使用，因为它们支持等值比较、范围条件和有序检索，适用于标识符、时间戳、频繁过滤的列以及许多外键查找。

传统关系型数据库擅长精确匹配（如 WHERE 条件），但缺乏高效回答“哪些已存向量离查询向量最近”的能力，因为这是几何问题。

关系型数据库在企业核心业务系统中仍是主流选择，原因在于事务支持、数据一致性保障和成熟的查询优化机制

结构化存储（如关系型数据库或 Redis）适合保存失败次数、时间戳、用户类型等元数据

文档型数据库倾向于将相关数据内嵌在同一文档中，以牺牲部分一致性换取查询效率，而关系型数据库强调数据规范化