Awesome Architecture

简体中文

English

简体中文

English

外观

向量数据库 架构模板 ​

代表产品 / 原型:Milvus、Qdrant、Weaviate、pgvector、FAISS 一句话定位:专门存储海量高维向量,并能在毫秒级找出「与查询向量最相似的 K 个」(近似最近邻 ANN)——语义搜索和 RAG 的存储底座。

1. 一句话定位 ​

向量数据库 = 一个为「找最相似」这件事专门优化的存储引擎。

普通数据库擅长「精确匹配」(查 id=123、查 name='张三');向量库擅长**「模糊的、语义的相似」**(找和这张图最像的、和这句话意思最近的)。它的看家本领是:在十亿条几百维的向量里,毫秒级返回最接近的几条。

它和 搜索引擎的倒排索引、网约车的空间索引 是同一类东西的不同形态——都是「为一种特殊的查询,专门组织数据」。

2. 业务本质:它在解决什么问题 ​

万物皆可向量化:一段文字、一张图、一段音频,都能用模型编码成一串数字(embedding),语义越接近,向量在空间里越靠近。于是「找相似」就变成了「找空间里最近的点」。

它支撑的场景:RAG 知识库 的语义检索、以图搜图、推荐(找相似商品 / 内容)、去重、人脸 / 声纹检索。AI 应用爆发后,它从「小众」变成了「基础设施」。

3. 核心需求与约束 ​

功能性需求:

  • [ ] 存储向量 + 元数据(payload)
  • [ ] 相似度检索:给一个查询向量,返回最近的 top-K
  • [ ] 带过滤的检索(如「只在『科技类』文档里找最相似的」)
  • [ ] 增删改、批量导入

非功能性需求 / 质量属性:

质量属性目标为什么对这类系统重要
检索延迟毫秒级在线检索 / RAG 都等着它
召回率高(且可调)ANN 是「近似」的,要在准和快之间平衡
规模十亿级向量AI 数据量极大
内存 / 成本可控向量很占内存,直接决定成本

关键约束(不可逾越的边界):

  • 🔴 维度灾难:向量几百~几千维,在高维空间里精确找最近邻,代价高到不可行。
  • 🔴 向量很占内存:十亿 × 上千维,内存是硬约束。
  • 🔴 相似 ≠ 相关:向量最近的,未必是业务上最该返回的。
  • 🔴 过滤 + 向量检索结合很难:「既要相似、又要满足某条件」不好同时高效满足。

4. 架构全景图 ​

═══ 写入:建索引 ═══
   ┌──────────────┐   ┌────────────────────────────────┐
   │ 向量+元数据   │──▶│ 构建 ANN 索引                    │
   │ (来自embedding)│   │ 如 HNSW(分层近邻图)/ IVF(聚类) │
   └──────────────┘   └────────────────┬───────────────┘
                                       ▼
                          ┌──────────────────────────────┐
                          │  索引存储(分片 + 副本)         │
                          │  主要在内存(大规模可落磁盘)     │
                          └────────────────┬─────────────┘
═══ 查询:近似最近邻 ═══                       │
   ┌──────────────┐   ┌────────────────────▼─────────────┐
   │ 查询向量      │──▶│ ANN 搜索:沿索引快速逼近最近的点    │
   │ (+过滤条件)   │   │ + 按元数据过滤 → 返回 top-K        │
   └──────────────┘   └──────────────────────────────────┘
        ▲                                  │
        └──────────── 最相似的 K 条 ◀───────┘

灵魂是那句权衡:用一点点精度,换巨大的速度。 精确最近邻在十亿高维向量里是灾难,ANN 算法(如 HNSW)放弃「保证 100% 找到最近的」,换来「极大概率找到很近的、而且快几个数量级」。

5. 组件职责 ​

  • 写入 / 索引构建:把向量组织成可快速搜索的索引结构(图 / 聚类)。为什么需要:不建索引就只能暴力逐个比对,十亿级根本不可行。
  • ANN 索引:近似最近邻索引(HNSW / IVF / DiskANN…)。为什么需要:这是向量库的核心,决定了快慢、准度、内存的三角平衡。
  • 查询引擎:执行相似度搜索,逼近最近邻。为什么需要:在线检索入口。
  • 元数据过滤:在向量检索的同时按条件筛(类别、时间、权限)。为什么需要:真实业务很少「纯找相似」,常要叠加约束。
  • 分片 + 副本:海量向量切片存储、副本扛查询。为什么需要:单机放不下也扛不住十亿级。

6. 关键数据流 ​

场景一:插入向量

1. 拿到向量 + 元数据(如 {类别:科技, 来源:文档7})
2. 把它插入 ANN 索引(如在 HNSW 图里建立与近邻的连接)
3. 写入分片(按 id / 随机),并复制到副本

场景二:相似度查询(带过滤)

1. 查询向量 + 条件「类别=科技」 ──▶ 查询引擎
2. 沿 ANN 索引快速逼近最近的候选点(不暴力扫全部)
3. 结合元数据过滤(只保留 类别=科技 的)
4. 返回 top-K 最相似的向量及其元数据

7. 数据模型与存储选择 ​

核心实体极简:向量记录(id + embedding + 元数据 payload)。

数据放在哪为什么
向量 + ANN 索引内存为主检索要快;HNSW 等图索引在内存里跑最快
超大规模索引磁盘(如 DiskANN)内存放不下十亿向量时,用磁盘换容量
元数据 payload随向量 / 关系型过滤、展示
原始对象(图 / 文本)对象存储向量只是「指纹」,原物按 id 取回

教学点:向量库的存储难题是内存——向量又多又占地方。所以「量化(用更省的精度存向量)」「DiskANN(放磁盘)」这些都是为了在内存这个硬约束下塞下更多向量。

8. 关键架构决策与权衡 ⭐ ​

决策 1:精确最近邻,还是近似(ANN)?⭐

  • 精确(暴力比对 / 精确索引):保证找到真正最近的,但高维 + 海量下慢到不可用。
  • 近似(ANN):放弃 100% 准确,换来快几个数量级。
  • 取向:几乎一定选 ANN。「用精度换速度」是处理海量的常见交易,关键是召回率可调、可接受。

决策 2:索引类型怎么选?(按规模和资源)⭐

  • HNSW(分层近邻图):查询快、召回高,但占内存。中小规模、追求质量的首选。
  • IVF(倒排 + 聚类):省内存,需训练、召回略低。大规模、内存敏感时用。
  • DiskANN:索引放磁盘,适合单机内存放不下的超大规模。
  • 取向:中小规模 HNSW;超大规模 / 省内存考虑 IVF / DiskANN / 量化。

决策 3:召回率 vs 延迟 / 内存,怎么平衡?⭐

  • 调高 ANN 参数(如 HNSW 的 ef、M):召回更高,但更慢、更占内存。
  • 取向:没有「最优」,只有「最适合你业务的召回 - 延迟 - 成本点」,要按场景压测调参。

决策 4:专用向量库,还是 pgvector?(不同阶段的选型)⭐

  • pgvector(给已有 PostgreSQL 装个扩展):零新增组件、和业务数据同库、事务方便。百万级够用。
  • 专用向量库(Milvus / Qdrant / Weaviate):为向量而生,十亿级、分布式、功能强,但是个要单独运维的新系统。
  • 取向:小规模、已有 Postgres → 先用 pgvector;规模大 / 要分布式 / 要高级特性 → 上专用库。详见第 12 节。

9. 规模化与瓶颈 ​

  • 第一个瓶颈:内存(向量太占地方)。 → 破解:量化(降精度)、DiskANN(放磁盘)、冷热分层。
  • 第二个瓶颈:向量量超过单机。 → 破解:分片(按 id / 随机切)+ 副本扛查询。
  • 第三个瓶颈:写入与索引重建开销。 → 破解:批量导入、增量建索引、读写分离。
  • 第四个瓶颈:带过滤的检索效率。 → 破解:针对「过滤 + 向量」的融合索引策略,避免「先全量检索再过滤」的浪费。

10. 安全与合规要点 ​

  • 多租户隔离:不同租户 / 知识库用命名空间或集合隔离。
  • 向量也可能泄露隐私:embedding 在一定条件下可被反推出原始信息,要按敏感数据对待。
  • 访问控制 + 元数据权限:检索要能按权限过滤。

11. 常见误区 / 反模式 ​

  • ❌ 追求精确最近邻 → ✅ 用 ANN,接受可控的近似。
  • ❌ 不管内存盲目上 HNSW → ✅ 大规模考虑 IVF / DiskANN / 量化。
  • ❌ 只看延迟不看召回率 → ✅ 两者一起压测权衡。
  • ❌ 几万条数据也上重型专用向量库 → ✅ pgvector / 单机 FAISS 就够,别过度设计。
  • ❌ 以为「向量相似」就等于「业务相关」 → ✅ 检索结果要按业务评测,必要时加重排。

12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置) ​

阶段向量规模怎么设置(具体)此时该操心什么
MVP< 百万直接 pgvector(在已有 Postgres 上加扩展),或单机 FAISS;用 HNSW 索引别引入新系统,先把语义检索跑起来
成长期百万~亿上专用向量库(Milvus / Qdrant / Weaviate),HNSW 索引、分片 + 副本、带过滤检索召回率、延迟、内存成本的平衡
成熟期十亿+分布式、量化 / DiskANN 降内存、冷热分层、与全文检索融合(混合检索)规模、成本、与检索系统的协同

13. 可复用要点 ​

  • 💡 「用精度换速度」是处理海量的经典交易。 ANN、采样、布隆过滤器、近似计数……都在用「差不多对」换「快得多」。
  • 💡 特殊查询要专用索引:相似度查询用 ANN,正如全文用倒排、地理用空间索引——别用通用工具硬扛特殊形态。
  • 💡 先问规模再选型。 pgvector 和分布式向量库之间,差的不是「先进与否」,是「你到底有多少向量」。
  • 💡 相似 ≠ 相关:检索结果的业务质量要单独评测,这和 RAG 的「检索质量决定上限」是一回事。

🎯 随堂检验 ​

🤔向量数据库为什么用『近似最近邻(ANN)』而不是精确查找?
  • A精确算法写不出来
  • B在海量高维向量里,用一点精度换巨大的速度
  • C纯粹为了省钱

参考原型与延伸阅读 ​

本模板基于以下真实开源项目与论文整理。下面几个是当下主流的开源向量库,可直接读代码、跑基准。

🔧 开源原型(可直接读代码):

  • milvus-io/milvus — 按 GitHub 星数最流行的开源向量库,为十亿级设计,支持 HNSW / IVF / DiskANN 多种索引。
  • qdrant/qdrant — Rust 写的高性能向量库,主打带过滤的向量检索,自托管 / 云均可。
  • weaviate/weaviate — 自带 HNSW 索引、支持灵活过滤与混合检索的向量库。
  • pgvector/pgvector — 给 PostgreSQL 加向量检索的扩展;百万级常能匹敌专用库,中小项目的省心之选。
  • facebookresearch/faiss — Meta 的相似度检索库,支持 IVF / HNSW / PQ 等大量 ANN 算法与 GPU 加速,理解 ANN 的最佳起点。

📖 论文:

📌 一句话记住向量数据库:它不是「能存数组的数据库」,而是「一台为『找最相似』专门优化、用一点精度换巨大速度的检索引擎」——所有设计都在回答『怎么在十亿高维向量里,毫秒级找出最接近的那几个』。