什么是向量数据库？

前言传统数据库在 AI 时代的“力不从心”在关系型数据库如 MySQL、PostgreSQL或传统检索引擎如 Elasticsearch统治的时代数据检索的核心逻辑建立在标量精确匹配Exact Match与倒排索引Inverted Index之上查询用户 ID 等于 10001 的记录B Tree 索引点查毫秒级查询包含关键字“退款”且金额大于 500 的订单范围索引 组合过滤模糊匹配商品名称中包含“手机”的文本分词 倒排索引。然而随着大语言模型LLM、多模态大模型和 RAG检索增强生成技术的爆发人类产生的数据超过 80% 转化为文本、图片、音视频、代码片段和用户行为等非结构化数据。计算机无法直接对一段自然语言或一张图片建立 B 树。深度学习技术通过 Embedding 模型将非结构化数据映射为高维连续空间中的特征向量如 768 维、1536 维。此时业务查询的需求变成了“从数据库的 5000 万个向量中找出在空间距离上与当前提问最接近的前 10 个向量。”如果使用传统数据库执行该查询系统只能发起全表扫描将每一行记录的高维数组取出并计算距离算法复杂度为O(N * D)N 为数据量D 为向量维度。在千万级数据量下单次查询可能耗费数十秒乃至数分钟直接导致系统崩溃。向量数据库Vector Database正是为解决高维空间海量特征向量的高速持久化、索引与语义相似度召回而生的专用基础设施。一、 核心概念解构向量数据库究竟在存什么、查什么1.1 向量表征与语义空间当一段文本输入到 Embedding 模型如text-embedding-3-small或bge-m3后模型会输出一个固定维度的实数数组文本 A我非常喜欢这款轻薄便携的笔记本电脑 ➔ Embedding 向量 A: [0.024, -0.015, 0.341, ..., 0.089] (共 1536 个浮点数) 文本 B这台电脑很轻出差携带非常方便 ➔ Embedding 向量 B: [0.021, -0.018, 0.338, ..., 0.091] (共 1536 个浮点数) 文本 C今天午餐吃的牛肉拉面味道很正宗 ➔ Embedding 向量 C: [-0.412, 0.521, -0.009, ..., -0.211] (共 1536 个浮点数)在数学几何空间中语义含义相似的文本其向量在空间中的夹角越小、距离越近语义无关的内容距离越远。高维语义空间映射示意 维度 2 (便携性) ▲ │ ● 文本 A (轻薄笔记本) │ ● 文本 B (便携电脑) │ (空间距离极近) │ │ ● 文本 C (牛肉拉面) │ (空间距离极远) └───────────────────────────────► 维度 1 (科技属性)1.2 空间相似度度量标准Metrics向量数据库根据配置的距离度量标准判断向量之间的相似性。常见的度量指标包括以下四种1. 余弦相似度Cosine Similarity度量两个高维向量之间夹角的余弦值关注向量的方向指向而非长度大小取值范围在[-1, 1]之间1 表示方向完全相同Cosine_Similarity(A, B) (A · B) / ( ||A|| × ||B|| )2. 点积 / 内积Dot Product / Inner Product如果向量已经过单位长度归一化||A|| 1且||B|| 1点积等价于余弦相似度计算时不包含开根号除法硬件执行效率最高Dot_Product(A, B) A · B ∑ (A_i × B_i)3. 欧几里得距离Euclidean Distance / L2 Distance度量高维空间中两点之间的绝对几何直线距离值越小表示两点越相近L2_Distance(A, B) sqrt( ∑ (A_i - B_i)^2 )4. 曼哈顿距离Manhattan Distance / L1 Distance度量各个坐标轴绝对差值的总和L1_Distance(A, B) ∑ |A_i - B_i|二、 算法内核ANN近似最近邻搜索技术演进传统搜索要求绝对精确匹配KNNk-Nearest Neighbors但在高维空间中维度灾难Curse of Dimensionality使得任何传统树状索引如 KD-Tree、R-Tree退化为线性全表扫描。为了将查询耗时压缩到数毫秒向量数据库全面采用了ANNApproximate Nearest Neighbor近似最近邻搜索算法在允许极小精度损失例如 95%~99% 召回率的前提下将搜索时间复杂度从O(N)降低至O(log N)。┌────────────────────────────────────────────────────────────────────────┐ │ 主流 ANN 算法族系演进图 │ ├──────────────────┬─────────────────────────────┬───────────────────────┤ │ 算法类型 │ 代表算法 │ 核心优缺点 │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 1. 暴力穷举 │ Flat (Brute-Force) │ 100% 召回率速度极慢 │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 2. 空间划分/倒排 │ IVF-Flat / IVF-SQ8 │ 内存适中建索引快 │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 3. 基于图拓扑 │ HNSW / NSW │ 检索极快召回率极高│ │ │ │ 内存消耗大建索引慢 │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 4. 向量量化压缩 │ PQ / SCaNN │ 内存占用极低精度略损│ └──────────────────┴─────────────────────────────┴───────────────────────┘2.1 Flat暴力全量计算原理不建立任何索引结构Query 进来后逐个向量进行点乘计算并排序。适用场景10 万以内规模的小型数据集或作为离线评估其他算法召回率的基准Ground Truth。2.2 IVFInverted File Index倒排文件索引原理通过 K-Means 聚类算法将高维空间中的所有向量聚合成若干个 Voronoi 单元格Centroids 质心。检索流程查询时先计算 Query 向量与所有聚类中心的距离挑选出距离最近的nprobe个中心单元仅在这几个单元格内部的候选向量中进行精确比对。特点通过跳过大量无关空间单元检索速度提升几十倍但如果跨边界向量未被聚类覆盖可能丢失部分边界召回。IVF 空间划分示意 ┌─────────────────┬─────────────────┐ │ 单元格 1 │ 单元格 2 │ │ ● │ ▲ │ │ (中心点 A) │ (中心点 B) │ │ ● ● ● │ ▲ ▲ ▲ │ ├─────────────────┼─────────────────┤ │ 单元格 3 │ 单元格 4 │ │ ★ │ ◆ │ │ ★ ★ │ ◆ ◆ ◆ │ └─────────────────┴─────────────────┘ Query 先匹配离谁最近再仅扫描对应单元格内部的点2.3 HNSWHierarchical Navigable Small World分层可导航小世界图HNSW 是目前工业界使用最广泛、吞吐量和召回率平衡最好的图索引算法。灵感来源跳表Skip-List的多层稀疏网络设计 六度空间小世界理论。算法结构底层Layer 0包含全量数据点每个点与距离最近的若干个邻居建立边构成一张密集图。高层Layer 1 ~ Layer N向上按指数概率逐渐抽稀节点层数越高节点越稀疏节点之间的跨度越大。检索流程从最高层的入口节点Entry Point进入执行贪心搜索Greedy Search快速在大尺度上“跳跃”逼近目标区域找到本层局部最优解后向下穿透到更细密的一层逐层下沉至 Layer 0在极小的局部候选邻居中锁定 Top-K 结果。代价构建索引时需要为大量节点维护双向连接指针内存占用通常是原始向量数据的 1.5 到 2 倍。HNSW 多层跳跃图解 Layer 2 (超稀疏图): [Entry] ────────────────────────► [Node A] │ │ ▼ (下沉) ▼ (下沉) Layer 1 (稀疏图): [Entry] ────► [Node X] ──────────► [Node A] ──► [Node B] │ │ │ │ ▼ (下沉) ▼ (下沉) ▼ (下沉) ▼ (下沉) Layer 0 (密集全量图): [点密集网状互联包含所有向量数据做最终精确局部收敛搜索]2.4 PQProduct Quantization乘积量化在拥有上亿规模向量的场景中如果全部将 1536 维的 Float32 向量单条占用 6KB 内存常驻内存数千万条数据即可耗尽几百 GB 显存/内存。原理将高维向量例如 1024 维横向切分为多个低维子向量例如 8 个 128 维的子空间在每个子空间中分别训练聚类中心字典如 256 个质心最终用 1 个 Byte8-bit存储质心索引编号。收益原本 1024 个 Float324096 字节被压缩为 8 个 Byte内存压缩比高达 500:1可以在消费级硬件上常驻数亿向量进行粗筛。三、 选型争论专用向量数据库 vs 传统数据库外挂向量扩展在技术选型讨论中工程师经常争论“我们已经有 PostgreSQL / Elasticsearch 了装个插件就能支持向量为什么还要费劲部署专门的向量数据库”这是一个典型的“专精Specialized与通用Generalized”路线之争。┌────────────────────────────────────────────────────────────────────────┐ │ 专用向量数据库 vs 关系型外挂插件架构对比 │ ├──────────────────┬─────────────────────────────┬───────────────────────┤ │ 对比维度 │ 专用向量库 (如 Milvus/Qdrant)│ 传统库扩展 (如 pgvector)│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 1. 核心设计取向 │ 极致高维 ANN 计算与高并发 │ 事务 ACID、标量关联优先│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 2. 混合过滤性能 │ 单阶段原生图遍历带过滤 │ 依赖优化器执行计划评估 │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 3. 写入与索引吞吐│ 异步批量构建写入吞吐极大 │ 触发 WAL 日志构建耗时│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 4. 架构复杂性 │ 引入新组件、新维护栈与学习成本│ 零架构改造技术栈复用 │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 5. 数据一致性 │ 最终一致性为主 (高可用设计) │ 强一致性 (传统事务 ACID)│ └──────────────────┴─────────────────────────────┴───────────────────────┘3.1 混合过滤Hybrid Filtering的核心挑战在真实业务场景中我们很少只发起裸向量查询几乎一定会附带业务标量条件“查询与这段描述最相似、且用户所属部门在华东、创建时间在 2026 年之后、状态为已发布的文档。”传统数据库处理这类查询往往需要在两套不同逻辑之间调度容易遭遇性能塌陷【过滤策略的演化路线】 1. 后过滤 (Post-filtering): 先做向量 ANN 检索出 Top-1000 ➔ 再根据标量条件过滤 缺陷若符合条件的记录本身极少Top-1000 过滤后可能只剩 0 个结果召回率归零 2. 先过滤 (Pre-filtering): 先根据标量条件过滤出所有满足条件的 ID ➔ 在这些 ID 对应的向量中执行穷举距离比对 缺陷若满足条件的记录有数百万条ANN 索引无法生效退化为暴力线性计算 3. 单阶段迭代过滤 (Single-stage Iterative Filtering, 现代专用向量库方案): 在 HNSW 图遍历跳转的同时实时读取标量位图 (Bitmap / Payload Index)。 如果候选节点的标量不符合条件该点不加入结果集但继续沿其图边缘探寻下一个邻居。现代专用向量数据库如 Qdrant、Milvus在底层将标量索引与向量图结构融为一体能确保在满足复杂组合过滤的同时严格维持预设的 Top-K 召回率与毫秒级延迟。四、 五大主流向量数据库横向对比选型我们针对业界使用最广泛的 5 款代表性向量存储方案Milvus、Qdrant、Chroma、pgvector (PostgreSQL)以及Pinecone进行深度剖析与横向比对。4.1 候选对象全景画像1. Milvus 2.x —— 分布式云原生重量级霸主技术底座Go (协调控制面) C (Knowhere 核心计算内核)。架构特点彻底的存算分离与微服务架构。依赖 etcd 进行元数据同步Pulsar/Kafka 承载流式 WAL 写入日志MinIO/S3 承担持久化对象存储查询节点QueryNode具备水平弹性扩缩容能力。优点能够承载数十亿级超大规模向量分布式架构极其成熟支持极为丰富的索引类型HNSW、IVF、SCaNN、GPU 索引等。痛点部署架构非常重生产高可用集群至少依赖 5~8 个独立服务单机轻量启动复杂日常运维门槛高。2. Qdrant —— 现代云原生高性能的 Rust 精品技术底座纯 Rust 编写。架构特点极致利用系统级硬件与内存控制。提供原生丰富的 Payload 过滤语法支持向量与元数据的单阶段无损过滤。优点性能强劲、内存足迹小、单机吞吐表现极佳单二进制文件即可启动同时也原生支持基于 Raft 协议的分布式分片集群。支持将向量存储在内存或直接 mmap 到磁盘降低大规模场景的物理内存消耗。痛点相对 Milvus 诞生时间较晚生态周边的开箱即用大型管理套件相对较少。3. Chroma —— 本地开发与 PoC 原型利器技术底座Python / TypeScript 顶层封装底层基于 ClickHouse/SQLite DuckDB hnswlib。架构特点专为 LLM 应用开发者设计的无门槛轻量级嵌入式库。优点安装只需pip install chromadb两行代码即可在 Python 内存或本地文件持久化与 LangChain、LlamaIndex 原生整合度最高。痛点不是为多租户、高并发分布式企业生产设计的数据量一旦突破数百万写入吞吐和并发检索延迟会出现明显抖动。4. PostgreSQL pgvector —— 业务集成度最高、零心智负担的保守派之选技术底座C 语言扩展PostgreSQL Extension。架构特点将向量作为 Postgres 的原生数据类型vector利用 Postgres 已有的 WAL、事务隔离、连接池、备份恢复与标量索引。优点零架构变迁成本。单表直接把业务属性id,price,user_id,created_at与特征向量存放在同一张物理表中直接通过一个 SQL 语句完成事务性更新与复杂 Join。痛点在高维 HNSW 索引构建期间消耗巨大的 CPU 与维护内存大批量向量并发写入时不如专门的向量数据库平滑单节点承载千万级以上规模向量时硬件成本高。5. Pinecone —— 全托管云原生 SaaS 行业标杆技术底座闭源全托管托管在 AWS / GCP / Azure。架构特点Serverless 弹性计费用户完全不需要关注副本、分片、节点挂载等任何运维细节。优点真正的“开箱即用”秒级起服务99.9% 行业顶尖的托管 SLA支持元数据过滤与混合搜索。痛点闭源且必须将数据托管至外网公有云在注重数据隐私合规的金融、政企与内网环境中无法使用费用按使用量累加长期高负载成本显著高于自建。4.2 综合选型评估矩阵表评测维度MilvusQdrantChromapgvector (Postgres)Pinecone开源协议Apache 2.0Apache 2.0Apache 2.0PostgreSQL 协议闭源 (SaaS)开发语言Go CRustPython / CC未知 (云原生)部署架构存算分离微服务集群单二进制 / 原生 Raft 分布式进程内嵌入 / 极简客户端依赖 Postgres 主从/集群完全免运维托管支持数据量级亿级至百亿级数千万至数亿级百万级以下千万级以下亿级以上单机资源消耗较高 (依赖多)极低 (Rust 极致控制)低 (适合笔记本跑)中等 (共用 PG 资源)无本地开销索引类型支持HNSW, IVF, PQ, SCaNN, GPUHNSW (内存/mmap)HNSW (hnswlib)HNSW, IVFFlat托管优化索引标量过滤能力强大 (表达式解析)极强 (Payload 深度优化)基础元数据过滤最强 (原生全功能 SQL)强大 (JSON 过滤)ACID 事务支持否 (最终一致性)否 (最终一致性)否是 (完整数据库事务)否运维门槛高 (需掌握 etcd/MinIO/K8s)低至中等极低 (零运维)极低 (沿用已有 DBA)零运维适用场景超大规模企业级中心向量平台高性能业务落地、混合过滤优先个人项目、Demo、PoC 原型既有系统渐进升级、中小规模无运维预算团队、海外 SaaS五、 企业落地选型决策树在真实的软件工程架构设计中没有“最好”的技术只有“最匹配”的决策。根据团队技术栈、运维成本与业务指标可按照如下决策树进行选型[是否有海外合规/免运维公有云需求] │ ┌─────────────────────┴─────────────────────┐ 是 否 │ │ [选 Pinecone] [是否仅为个人测试/快速PoC] │ ┌─────────────────────┴─────────────────────┐ 是 否 │ │ [选 Chroma] [当前存量系统是否重度依赖] [PostgreSQL且向量1000万] │ ┌─────────────────────┴─────────────────────┐ 是 否 │ │ [选 pgvector] [数据规模与运维能力考量] │ ┌─────────────────────────────┴─────────────────────────────┐ │ │ [数据量 5000 万或需多租户] [追求极致性能、纯粹单二进制] [具备专业 K8s/大数据运维团队] [中等规模(千万级)、强调复杂过滤] │ │ [选 Milvus] [选 Qdrant]生产级关键考量内存容量规划计算在选型中很多团队会低估 HNSW 索引对物理内存RAM的消耗。以下是计算向量数据库物理内存开销的通用经验公式基本存储大小 数据量 (N) × 向量维度 (D) × 4 字节 (Float32) 索引额外开销 基本存储大小 × 索引倍率系数 (HNSW 约为 1.2 ~ 2.0) 运行安全冗余 (基本存储大小 索引额外开销) × 1.3 (用于缓冲与过滤计算) 【案例测算】 数据量10,000,000 (1000 万条) 模型维度1536 维 (OpenAI text-embedding-3-small 格式) 1. 纯向量体积 10,000,000 × 1536 × 4 字节 ≈ 61.44 GB 2. HNSW 索引体积 ≈ 61.44 GB × 1.5 ≈ 92.16 GB 3. 实际需要预留的最低物理内存 (61.44 92.16) × 1.3 ≈ 199.68 GB (约需配置 256 GB RAM 节点)结论如果硬件预算无法支撑将全部向量与图索引放入内存应优先选择支持磁盘 mmap / 向量量化压缩PQ/SQ8的数据库如 Qdrant 或配置了 PQ 索引的 Milvus。六、 双主流方案实战演练Python 代码对比下面针对工程中最常见的两种落地路线pgvector与Qdrant给出完整的初始化、写入与混合过滤检索实现。6.1 方案 A基于 PostgreSQL pgvector 实现1. 环境准备确保数据库已安装pgvector扩展并开启CREATE EXTENSION IF NOT EXISTS vector;2. Python 实战代码import psycopg2 from psycopg2.extras import execute_values import numpy as np def run_pgvector_demo(): conn psycopg2.connect(dbnameenterprise_db userpostgres passwordsecret hostlocalhost port5432) cur conn.cursor() # 1. 创建包含业务标量与高维向量的混合表 cur.execute( CREATE TABLE IF NOT EXISTS knowledge_chunks ( id BIGSERIAL PRIMARY KEY, department VARCHAR(50), status VARCHAR(20), content TEXT, embedding vector(1536) ); ) # 2. 建立 HNSW 向量索引 (余弦距离使用 vector_cosine_ops) cur.execute( CREATE INDEX IF NOT EXISTS idx_chunks_hnsw ON knowledge_chunks USING hnsw (embedding vector_cosine_ops) WITH (m 16, ef_construction 64); ) conn.commit() # 3. 模拟插入数据 mock_vector np.random.rand(1536).tolist() cur.execute( INSERT INTO knowledge_chunks (department, status, content, embedding) VALUES (%s, %s, %s, %s) , (Finance, Published, 2026年度企业第一季度财务合规指引..., mock_vector)) conn.commit() # 4. 执行带标量过滤的高维向量相似度检索 ( 表示余弦距离运算符) query_vector np.random.rand(1536).tolist() sql_search SELECT id, department, status, content, 1 - (embedding %s::vector) AS cosine_similarity FROM knowledge_chunks WHERE department %s AND status %s ORDER BY embedding %s::vector LIMIT 5; cur.execute(sql_search, (query_vector, Finance, Published, query_vector)) results cur.fetchall() print( pgvector 检索结果 ) for row in results: print(fID: {row[0]}, 部门: {row[1]}, 相似度: {round(row[4], 4)}, 摘要: {row[3][:30]}...) cur.close() conn.close() if __name__ __main__: run_pgvector_demo()6.2 方案 B基于 Qdrant 实现1. 环境准备运行独立的 Qdrant 容器docker run -p 6333:6333 -p 6334:6334 -v $(pwd)/qdrant_storage:/qdrant/storage:z qdrant/qdrant pip install qdrant-client2. Python 实战代码from qdrant_client import QdrantClient from qdrant_client.models import ( Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue ) import numpy as np def run_qdrant_demo(): # 初始化客户端 client QdrantClient(hostlocalhost, port6333) COLLECTION_NAME enterprise_rag_docs # 1. 创建 Collection 并指定向量维度与距离算法 if not client.collection_exists(COLLECTION_NAME): client.create_collection( collection_nameCOLLECTION_NAME, vectors_configVectorParams(size1536, distanceDistance.COSINE), ) # 为高频过滤字段建立 Payload 标量索引加速过滤效率 client.create_payload_index( collection_nameCOLLECTION_NAME, field_namedepartment, field_schemakeyword ) # 2. 构造并写入带有丰富业务元数据Payload的向量点 mock_vector np.random.rand(1536).tolist() client.upsert( collection_nameCOLLECTION_NAME, points[ PointStruct( id1, vectormock_vector, payload{ department: Finance, status: Published, content: 2026年度企业第一季度财务合规指引... } ) ] ) # 3. 单阶段高效混合过滤检索 query_vector np.random.rand(1536).tolist() search_filter Filter( must[ FieldCondition(keydepartment, matchMatchValue(valueFinance)), FieldCondition(keystatus, matchMatchValue(valuePublished)) ] ) search_result client.search( collection_nameCOLLECTION_NAME, query_vectorquery_vector, query_filtersearch_filter, limit5 ) print( Qdrant 检索结果 ) for hit in search_result: print(fID: {hit.id}, 匹配得分: {round(hit.score, 4)}, Payload: {hit.payload}) if __name__ __main__: run_qdrant_demo()七、 生产落地避坑指南在大规模向量数据库生产实践中以下工程陷阱必须引起高度警惕1. 警惕模型更换引发的“全量历史重算”灾难Embedding Lock-in陷阱在系统上线半年后算法团队将 Embedding 模型从text-embedding-v1升级为text-embedding-3维度从 768 变为 1536。后果不同模型投射的几何空间完全不一致新模型的 Query 无法在旧模型的向量库中进行有效检索。对策必须永远保留非结构化源文档的正文绝不能只存向量。更换模型意味着必须启动全量离线重新向量化Re-embedding脚本并在库中采用“蓝绿集合切换Blue-Green Collections”平滑上线。2. 构建阶段的写入性能陷阱陷阱在向数据库一次性写入 1000 万条历史数据时很多团队先创建了 HNSW 索引然后再逐条或批量INSERT。后果每写入一个新点数据库都要在线遍历图并为多个邻居计算重构指针单线程写入速度会从每秒数千条断崖式跌落到每秒数十条。对策先写入全量冷数据再批量触发并行构建索引Bulk-Build Index。大部分成熟数据库在此模式下会利用多核 CPU 进行并行加速。3. 忽略标量过滤字段的基数Cardinality陷阱如果不针对过滤条件做字段索引单阶段遍历会受到很大影响。对策在类似 Qdrant 或 Milvus 的系统中针对department_id、is_deleted等经常出现在WHERE / must过滤条件中的字段必须显式建立 Payload Index / Scalar Index避免过滤逻辑退化为全量扫表。结语向量数据库的未来演进趋势向量数据库并非孤立的存检组件随着大模型技术的深化演进它正在经历三个重大的范式变革多模态原生检索Native Multimodal不仅仅处理文本向量同时承载图像、音频、视频时空片段的联合嵌入检索具备跨模态统一表征能力多路混合检索深度内置Native Hybrid Search向量数据库不再单纯提供 Dense 密集检索而是深度集成BM25 / Sparse 稀疏检索并在引擎内部原生实现倒数排名融合RRF与重排序RerankingGraphRAG 与图向量融合Graph-Vector Convergence单纯的距离检索缺乏逻辑推理能力下一代系统正把知识图谱实体与关系拓扑与向量空间深度结合实现全局宏观关联与微观局部细节的双重精准捕获。客观审视自身的数据体量、团队的运维预算与业务真实延迟要求理智避开“盲目追求专用集群”或“无脑硬扛单机插件”的极端才能搭建出低成本、高可用且经得起业务规模考验的现代化 AI 数据基础设施。