---

核心前提：向量检索的底层算法基石

在深入探讨具体数据库架构之前，我们需要明确所有向量数据库共用的底层算法逻辑。向量检索本质上是寻找高维空间中距离最近的点（Approximate Nearest Neighbor, ANN）。常见的距离度量包括欧氏距离（$L\_2=\sqrt{\sum \_{i=1}^n(A\_i-B\_i{)}^2}$）和余弦相似度（$$\begin{gathered} \text{Cosine Similarity}=\frac{\mathbf{A}\cdot \mathbf{B}}{ \\ |\mathbf{A} \\ | \\ |\mathbf{B} \\ |} \end{gathered}$$）。

不同数据库的核心差异，在于它们如何工程化地实现以下两类主流算法：

• 图算法（以 HNSW 为代表）： 构建多层级的导航图，查询时从顶层稀疏图快速跳跃，到底层稠密图精细查找。召回率极高，延迟极低，但极度消耗内存，且构建耗时。
• 量化与聚类（以 IVF-PQ 为代表）： 将空间划分为多个簇（IVF），并将高维向量压缩为低维编码（PQ）。极大降低内存占用，但会损失一定的精度和召回率。

以下是主流向量数据库架构流派的深度拆解。

---

一、关系型数据库的自然延伸：pgvector (PostgreSQL)

pgvector 并不是一个独立的数据库，而是 PostgreSQL 的一个 C 语言扩展（Extension）。它代表了**“以结构化数据为主，向量检索为辅”**的架构流派。

1. 底层技术与架构设计

• 原生集成与存储机制： pgvector 将向量作为一种原生的数据类型（vector）嵌入到 PostgreSQL 的表结构中。向量数据和普通的标量数据（如文本、时间戳、价格）存储在同一个物理行（Tuple）中，完全复用 PG 的存储引擎和缓冲池（Shared Buffers）。
• 索引实现与 MVCC 冲突： 它支持 IVFFlat 和 HNSW 两种索引。以 HNSW 为例，pgvector 在 PG 的索引 API 框架内实现了图结构的持久化。但因为 PG 采用多版本并发控制（MVCC），每次向量数据的更新或删除，实际上都会产生新的行版本。这对 HNSW 图的维护带来了极大的挑战，极易产生索引膨胀（Bloat）。
• 混合检索的执行计划： 它的技术亮点在于执行器集成。当执行包含 SQL 标量过滤和向量 KNN 排序的查询时，PG 的优化器可以利用索引扫描，实现结构化过滤与向量检索的深度融合。

2. 适用场景

• 中小型 RAG 系统与垂直知识库： 总体向量数据规模在几百万以内。
• 强事务与元数据过滤需求： 业务极其依赖复杂的 SQL 过滤（如价格区间、分类），且需要严格的 ACID 事务保证。
• 技术栈收敛： 团队已经重度依赖 PostgreSQL，不希望引入额外的系统增加运维负担。

3. 核心优缺点

• 优点： 学习成本极低，与现有 ORM 框架完美兼容；继承了 PG 强大的 ACID 特性和极其丰富的生态（如结合 PostGIS 做地理空间向量搜索）。
• 痛点： 扩展性在千万级规模崩塌，HNSW 索引构建时间呈指数级上升；内存消耗巨大，容易引发 OOM；频繁的 UPDATE 会导致表和索引极度膨胀，严重依赖 VACUUM 清理，期间性能会发生剧烈抖动。

---

二、纯内存架构的极速低延迟引擎：Redis (RediSearch)

通过加载 RediSearch 模块，Redis 化身为一个高性能的内存级向量数据库。它代表了**“极速响应、高吞吐、短生命周期”**的流派。

1. 底层技术与架构设计

• 纯内存驻留计算： 没有传统数据库复杂的存储引擎和跨层数据拷贝，其向量距离计算是在 CPU 缓存级别以极低延迟完成的。
• Flat 与 HNSW 内存图： RediSearch 的 HNSW 图完全是内存数据结构，遍历和寻路速度达到了纳秒到微秒级，免去了磁盘 I/O 的干扰。
• 过期策略（TTL）协同： 原生支持对带有向量的 Key 设置过期时间。当数据过期时，底层会自动从 HNSW 图中剔除该节点。

2. 适用场景

• 对 P99 延迟极度敏感的实时召回： 推荐系统、短视频信息流、在线广告竞价，要求响应时间在几毫秒内。
• 短期意图匹配与 Session 会话： 用户的短期搜索意图、聊天机器人的上下文缓存。
• 高频流式数据： 实时新闻的情感向量计算与匹配。

3. 核心优缺点

• 优点： 绝对的低延迟性能王者；TTL 机制使得开发者无需编写复杂的定时任务来清理陈旧向量；数据结构丰富。
• 痛点： 高昂的硬件内存成本；一旦节点宕机，重启时将海量数据重新加载进内存并重建 HNSW 图的恢复耗时极长；缺乏应对超过内存容量数据集的冷热数据分离机制。

---

三、传统搜索巨头的跨界进化：Elasticsearch

Elasticsearch 凭借其在全文检索领域的霸主地位，通过引入 dense_vector 类型，正式切入向量数据库赛道。它代表了**“全文检索与向量检索并重（混合检索先行者）”**流派。

1. 底层技术与架构设计

• 基于 Lucene 的 HNSW 实现： ES 的向量索引建立在底层 Lucene 引擎的 HNSW 实现之上。它将向量数据作为段（Segment）的一部分进行持久化。
• 预过滤与后过滤机制： 在结合标量数据（如时间、分类）进行过滤时，ES 支持通过 Bitset（位图）技术在遍历 HNSW 图之前（Pre-filtering）或之后（Post-filtering）进行高效拦截。
• BM25 + 向量的真正混合： 借助 Reciprocal Rank Fusion (RRF) 算法，ES 可以在一次查询中原生整合传统的关键词全文检索（BM25 算法）分数与向量相似度分数。

2. 适用场景

• 以文本搜索为核心，向量为辅助的系统： 传统的电商搜索、文档检索系统升级 AI 能力。
• 存量架构改造： 公司内部已经拥有庞大且成熟的 ES 集群，不想引入新的基础组件。
• 复杂的词汇与语义混合场景： 需要同时匹配特定专有名词（关键词）和广泛意图（向量）。

3. 核心优缺点

• 优点： 生态极其成熟（Kibana, Logstash）；业内顶级的混合检索能力；分布式分片机制经过了多年大厂生产环境的考验。
• 痛点： JVM 垃圾回收（GC）开销在处理高密度计算时容易带来延迟抖动；基于分片（Shard）的广播查询在海量数据下性能损耗大；比起专门设计的云原生向量数据库，资源占用（CPU、内存、磁盘）显得过于臃肿。

---

四、专门设计的云原生向量基座：Milvus & Zilliz Cloud

Milvus 是专为数十亿级向量数据设计的云原生分布式数据库，Zilliz Cloud 是其商业化全托管形态。它代表了**“海量、高可用、彻底微服务解耦”**的现代流派。

1. 底层技术与架构设计

Milvus 采用了彻底的**存算分离（Storage-Compute Separation）**架构：

• 接入层（Proxy）： 负责路由请求，提供多语言 SDK 的接口。
• 协调服务（Coordinator）： 负责集群拓扑、负载均衡和任务调度。
• 独立的工作节点（Query / Data / Index Node）： 分离计算逻辑。查询节点负责匹配，数据节点负责写入日志，索引节点专门负责极其耗时的 HNSW 等索引构建任务。这种解耦避免了建索引时拖慢查询速度。
• 基于对象存储的持久化： 底层依赖 Pulsar/Kafka 作为 WAL（预写日志），并把数据段和索引持久化到 S3/MinIO 等对象存储中，实现廉价且安全的数据落盘。
• Cardinal 引擎（Zilliz 特有）： 通过先进的量化算法、图裁剪技术以及自动化的混合检索管道，解决了开源版需要繁琐调参的痛点。

2. 适用场景

• 企业级大规模 RAG 与复杂 AI Agent： 数据量从千万跨越到百亿级别。
• 高并发的互联网级多模态搜索： 图像、音视频检索，面对突发流量需要随时动态增加计算节点。
• 恶劣环境下的高可用要求： 即使部分节点宕机，数据存于 S3 绝对安全，其他节点秒级接管。

3. 核心优缺点

• 优点： 几乎无限的弹性扩缩容能力；读写完全分离，高频插入场景下 P99 延迟依然稳定；标量过滤、多租户、RBAC 功能完备。
• 痛点： 开源版本运维复杂度极高，强依赖 Kubernetes、MinIO 等一整套分布式组件（中小团队通常直接选择全托管的 Zilliz Cloud）；在极小数据量（几万条）下单并发查询时，由于微服务 RPC 调用开销，绝对延迟可能不如单机 pgvector。

---

五、新兴专业向量数据库：Qdrant、Pinecone、Weaviate

这三者是近年来在开发者社区极其火爆的纯血统向量数据库。

1. Qdrant (Rust 驱动的高效能流派)

• 底层技术： 采用 Rust 语言编写，极其注重内存安全和性能。其核心亮点是利用了**内存映射文件（mmap）**技术，将磁盘空间映射到内存中。这使得它可以在不消耗同等容量 RAM 的情况下，处理远超内存大小的数据集，同时保持合理的查询速度。
• 优缺点： 极高的单机性能和资源利用率，特别适合中小企业以极低硬件成本实现高性能向量检索。但在百亿级以上的超大规模分布式治理上，生态积累不如 Milvus。

2. Pinecone (闭源全托管 SaaS 标杆)

• 底层技术： 采用 Serverless 架构，完全屏蔽了底层的索引构建（自动选择 pFresh 或 HNSW 的变体）、节点管理和扩容。它通过专有的底层技术实现了极高的并发更新和近乎实时的索引可见性。
• 优缺点： 极致的开发者体验，三行代码即可接入，完全零运维。痛点在于它是闭源商业产品，且在极大规模数据量下，API 调用成本较高。

3. Weaviate (以对象和图关系为核心)

• 底层技术： 用 Go 语言编写，与其他数据库不同，它更像是一个带有向量搜索能力的图形/文档数据库。它内置了与各种 Embedding 模型的对接（直接传入文本即可自动向量化），并采用 GraphQL 作为主要查询语言。
• 优缺点： 非常适合需要维护复杂对象关系链条（如知识图谱与向量结合）的应用，开箱即用的向量化能力极佳。但在纯粹的极限高并发 QPS 压测下，性能略逊于 Qdrant 和 Milvus。

---

六、架构决策的核心武器：自动化性能基准评估

摒弃厂商营销，拥抱 VectorDBBench 等开源评测平台是高级架构师的必修课。评估时需要重点关注以下几个反直觉的陷阱和核心指标：

1. 脱离“召回率 (Recall)”谈吞吐量是耍流氓： 在 HNSW 近似算法中，牺牲召回率（如从 99% 降到 90%）能成倍提升 QPS。基准测试必须要求在指定的召回率（如 95%）红线下，比较不同架构的 QPS。
2. 平均延迟 (Avg Latency) 具有欺骗性，紧盯 P99 延迟： 生产环境中，长尾延迟决定了系统的稳定性。在高频读写混合压测中，单机架构（如 pgvector）容易出现极高的 P99 尖刺，而存算分离架构（Milvus）表现平稳。
3. 冷启动与横向扩展性评估： 测试一次性灌入 1000 万条数据，从落盘到索引立即可用的时间。验证架构是否可以通过增加节点来线性提升性能。

---

总结矩阵与下一步建议

评估维度	pgvector	Redis	ES	Milvus / Zilliz	Qdrant / Pinecone
架构本质	关系型单机插件	纯内存 K-V	搜索引擎扩展	云原生微服务解耦	专有/Serverless引擎
数据极限	百万 ~ 千万级	千万级(受限内存)	亿级	十亿 ~ 百亿级海量	千万 ~ 亿级
QPS吞吐量	较低	极高	中等	极高(可横向扩展)	高
P99 延迟	较高且易抖动	极低(亚毫秒)	较高	低且稳定	低
混合检索	最强(完备SQL)	弱	极强(BM25+)	强	中等

向量数据库的选型绝非“非黑即白”，而是资源、规模与业务需求之间的艺术平衡。小规模重 SQL 选 pgvector；毫秒级实时且不差钱选 Redis；重度依赖文本搜索选 ES；要构建企业级长久发展的海量 AI 基座，Milvus/Zilliz 是终极答案。