# 向量数据库 架构模板 > **代表产品 / 原型**:Milvus、Qdrant、Weaviate、pgvector、FAISS > **一句话定位**:专门存储海量高维向量,并能在毫秒级找出「与查询向量最相似的 K 个」(近似最近邻 ANN)——语义搜索和 RAG 的存储底座。 --- ## 1. 一句话定位 向量数据库 = **一个为「找最相似」这件事专门优化的存储引擎**。 普通数据库擅长「精确匹配」(查 id=123、查 name='张三');向量库擅长**「模糊的、语义的相似」**(找和这张图最像的、和这句话意思最近的)。它的看家本领是:在十亿条几百维的向量里,毫秒级返回最接近的几条。 它和 [搜索引擎的倒排索引](../search-engine/README.md)、[网约车的空间索引](../ride-hailing/README.md) 是同一类东西的不同形态——**都是「为一种特殊的查询,专门组织数据」**。 ## 2. 业务本质:它在解决什么问题 万物皆可向量化:一段文字、一张图、一段音频,都能用模型编码成一串数字(embedding),**语义越接近,向量在空间里越靠近**。于是「找相似」就变成了「找空间里最近的点」。 它支撑的场景:[RAG 知识库](../rag-knowledge-base/README.md) 的语义检索、以图搜图、推荐(找相似商品 / 内容)、去重、人脸 / 声纹检索。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](../rag-knowledge-base/README.md) 的「检索质量决定上限」是一回事。 ## 🎯 随堂检验 --- ## 参考原型与延伸阅读 > 本模板基于以下**真实开源项目**与**论文**整理。下面几个是当下主流的开源向量库,可直接读代码、跑基准。 **🔧 开源原型(可直接读代码):** - [milvus-io/milvus](https://github.com/milvus-io/milvus) — 按 GitHub 星数最流行的开源向量库,为十亿级设计,支持 HNSW / IVF / DiskANN 多种索引。 - [qdrant/qdrant](https://github.com/qdrant/qdrant) — Rust 写的高性能向量库,主打带过滤的向量检索,自托管 / 云均可。 - [weaviate/weaviate](https://github.com/weaviate/weaviate) — 自带 HNSW 索引、支持灵活过滤与混合检索的向量库。 - [pgvector/pgvector](https://github.com/pgvector/pgvector) — 给 PostgreSQL 加向量检索的扩展;百万级常能匹敌专用库,中小项目的省心之选。 - [facebookresearch/faiss](https://github.com/facebookresearch/faiss) — Meta 的相似度检索库,支持 IVF / HNSW / PQ 等大量 ANN 算法与 GPU 加速,理解 ANN 的最佳起点。 **📖 论文:** - [HNSW: Efficient and robust approximate nearest neighbor search (Malkov & Yashunin)](https://arxiv.org/abs/1603.09320) — 主流向量库默认索引 HNSW 的原始论文。 --- > 📌 一句话记住向量数据库:**它不是「能存数组的数据库」,而是「一台为『找最相似』专门优化、用一点精度换巨大速度的检索引擎」——所有设计都在回答『怎么在十亿高维向量里,毫秒级找出最接近的那几个』。**