系统架构与数据库理论基础：PostgreSQL 与 pgvector

欢迎关注专栏： CSDN：AI 开发技术

关键词 ：SQL, RDBMS, NoSQL, pgvector, 混合检索, 架构选型

阅读耗时：约 12 分钟

前四篇围绕 Redis 讨论了缓存、短期状态与跨进程协调。本篇转向需要事务、约束和长期保存的数据，建立 PostgreSQL 与 pgvector 的基础，为后续关系数据和向量检索实践做准备。

结构化查询语言 (SQL) 是关系型数据库的通用交互标准。它不仅是一种查询工具，更是一种严谨的数据描述与操作规范。

在实际开发中，SQL 的核心能力可分为以下几个维度：

数据定义语言 (DDL) ：用于构建和修改系统的数据骨架，如 CREATE TABLE、ALTER TABLE。严谨的 DDL 设计（如合理的索引、精确的数据类型配置）是保障系统后期高并发性能的基础。
数据操作语言 (DML) ：负责业务数据的流转，即日常使用的 INSERT、UPDATE、DELETE。
数据查询语言 (DQL) ：以 SELECT 为核心，通过 WHERE (过滤)、JOIN (多表关联)、GROUP BY (聚合分析) 提供强大的数据洞察能力。

在 Agent 架构中，关系型数据库可以通过事务、约束和审计字段，为会话、任务与知识条目等业务数据提供明确的一致性边界。

在构建现代系统时，理解两者的核心差异是进行合理架构选型的前提：

对比维度	关系型数据库 (RDBMS)	非关系型数据库 (NoSQL)
数据结构	以表、约束和关系为核心，也可通过 JSON 等类型保存半结构化数据。	包含键值、文档、列族、图等多种模型，能力取决于具体产品。
一致性模型	支持 ACID 事务，实际隔离级别与一致性由配置和使用方式决定。	有的产品支持事务和强一致，有的偏向最终一致，不能一概而论。
扩展方式	可垂直扩展，也可通过读副本、分区、分片或分布式方案横向扩展。	部分产品以水平扩展为主要设计目标，但仍有数据模型和运维成本。
查询能力	擅长关联、聚合与声明式查询。	围绕特定数据模型优化，查询能力因产品而异。

架构建议：需要事务、约束与复杂关联时优先评估 RDBMS；需要特定访问模式、缓存或专用分布式能力时再评估合适的 NoSQL 产品。最终选择还要结合一致性要求、查询方式、容量、团队经验和运维成本。

在 Agent 与 LLM 工程实践中，PostgreSQL 与 Redis 常常作为互补组件同时存在，明确它们的职责边界至关重要。

定位：全功能的企业级关系型数据库。
优势：
1. 支持 ACID 事务和多种隔离级别，便于维护核心数据的一致性。
2. 支持关联、窗口函数、公共表表达式等丰富的 SQL 能力。
3. 通过 JSONB 保存和索引半结构化数据，同时保留关系型约束能力。
4. 借由扩展系统（特别是 pgvector），能够作为统一架构同时处理结构化数据与高维向量。
场景：Agent 的用户配置管理、持久化长期记忆存储、复杂的多维元数据混合检索。

定位：基于内存的高性能键值对 (Key-Value) 数据结构存储。
优势：
1. 数据集主要在内存中操作，常用命令通常具有较低延迟；实际性能取决于命令、数据量、网络与部署方式。
2. 支持丰富的高级数据结构（List, Set, Hash）以及发布/订阅 (Pub/Sub) 模式。
场景：Agent 架构中的短期对话上下文缓存（Session 状态管理）、高频 API 请求的限流控制、以及分布式任务队列调度。

总结：一种常见分工是由 PostgreSQL 保存需要长期一致性的业务数据，由 Redis 承担可过期缓存和短期状态。系统上限仍取决于数据模型、代码、部署和容量规划，不能简单归因于某一个组件。

PostgreSQL 是功能丰富的开源关系型数据库，优势之一是扩展机制与 SQL 能力。除传统关系模型外，它还可通过扩展支持地理空间数据（PostGIS）、向量数据等场景。

在大语言模型 (LLM) 和检索增强生成 (RAG) 架构中，数据被抽象为高维浮点数数组（Embedding 向量）。传统的纯向量数据库（如 Milvus, Pinecone）虽然专精于向量检索，但往往会在架构中引入额外的数据一致性与同步成本。

pgvector 作为一个开源扩展，直接赋予了 PostgreSQL 原生处理高维向量的能力，带来了显著的工程优势：

减少组件数量：当业务数据已经位于 PostgreSQL 且向量规模适中，可以避免额外引入独立向量数据库。
统一过滤与检索 ：可以在 SQL 中组合关系字段、JSONB 元数据过滤和向量相似度排序。若要实现严格意义上的混合检索，还需要加入全文检索结果并设计融合排序。
近似索引支持：支持 HNSW 与 IVFFlat 等近似最近邻索引。性能、召回率和资源占用需要基于真实数据量、过滤条件和参数进行压测，不能只按数据规模下结论。