前言
在AI技术爆发的这两年,我发现了一个有趣的现象。
当大家都在讨论大模型有多强大时,真正落地的AI应用却往往卡在一个看似不起眼的环节:数据的检索和记忆。
你有没有想过,为什么智能客服能记住你之前的对话?
为什么电商推荐能精准找到"风格相似"的商品?
为什么企业知识库能瞬间从海量文档中找出你想要的答案?
这些能力的背后,都有一个共同的技术核心------向量数据库。
今天这篇文章就专门跟大家一起聊聊,AI中最常用的四种向量数据库,希望对你会有所帮助。
更多项目实战在项目实战网:java突击队
一、为什么AI离不开向量数据库?
有些小伙伴可能会问:传统的关系型数据库难道不能存储这些向量吗?
答案是:能存,但没法高效检索。
向量数据库的核心原理
在深入具体产品之前,我们先花三分钟理解向量数据库的核心概念:
1. 万物皆可向量化
想象一下,你要用一个数字来描述一个朋友。你可以用[身高, 体重, 外向程度, 幽默感...]这一组数字来定义他。
AI模型做得更精细,它能把一段话、一张图变成由几百甚至几千个维度组成的"特征向量",就像给内容定做了一个超精密的数学坐标。
2. 相似度计算 = 找"邻近点"
向量数据库把所有内容的坐标点都存起来。
当你查询时,它把你的问题也变成坐标点,然后快速计算空间中距离最近的那些点。
空间中两点距离越近,内容就越相似。这就像在一个超大的宇宙星图中,快速找到离你当前位置最近的那些星球。
3. 索引:快速查找的"秘籍"
如果挨个计算距离,数据一多就慢如蜗牛。
所以需要"索引"------一种高级的目录或地图。
常见的如HNSW(分层导航小世界)算法,它像建立了一个多层次的"交友网络",让你能通过少数几个"朋友"就快速联系到目标人物,极大提升了搜索速度。
理解了这三个核心,你就掌握了向量数据库90%的原理。
向量数据库的完整架构

二、Milvus:开源领域的"性能怪兽"
2.1 项目概况
一句话定位:专为海量向量搜索设计的分布式数据库
Milvus是LF AI & Data基金会的毕业项目,由Zilliz主导开发。
经过多年的迭代,它已经成为开源向量数据库领域的标杆产品。
2.2 底层架构深度解析
Milvus采用存算分离的云原生架构,这是它与众不同的核心设计:

核心创新:三层存储架构
Milvus 2.6引入的三层存储架构是其最大的技术亮点:
- 内存层:承载热数据,支持毫秒级查询响应
- 本地SSD缓存:温数据缓存,加速重复访问请求
- 对象存储(如S3):存放全量数据,保障低成本
系统基于LRU(最近最少使用)算法智能预测,动态调整冷热数据边界,自动降级不常用数据块。
生产环境测试显示,其缓存命中率超90%,能降低87%存储成本 和25%计算支出。
一个10TB的数据集,月均成本可从3000美元降至400美元。
2.3 混合搜索能力
Milvus最新版本内置了优化版BM25全文引擎,支持向量语义检索与关键词精确匹配的双重能力:
java
import io.milvus.client.MilvusClient;
import io.milvus.param.*;
import io.milvus.param.collection.SearchParam;
import io.milvus.grpc.SearchResults;
import io.milvus.grpc.SearchResultData;
// 初始化客户端
MilvusClient client = new MilvusClient(ConnectParam.newBuilder()
.withHost("localhost")
.withPort(19530)
.build());
// 构建搜索请求
SearchParam searchParam = SearchParam.newBuilder()
.withCollectionName("docs")
.withVectorFieldName("embedding")
.withVectors(Collections.singletonList(queryVector))
.withMetricType(MetricType.COSINE)
.withTopK(10)
.withExpr("category == 'AI'") // 标量过滤
.build();
SearchResults results = client.search(searchParam);
List<SearchResultData> resultData = results.getResults().getFieldsDataList();
实测数据显示,Milvus的BM25检索速度比Elasticsearch快4-7倍,索引体积仅为原始文本的1/3。
2.4 优缺点分析
优点:
- 分布式架构,可水平扩展至千亿级向量
- 丰富的索引类型:HNSW、IVF、DiskANN、GPU加速CAGRA
- 完善的混合搜索能力:向量+全文+标量过滤
- 开源免费,社区活跃
缺点:
- 部署运维复杂,依赖etcd、对象存储、消息队列等多个组件
- 学习曲线陡峭,需要理解其存储和索引概念
- 对中小规模应用来说可能"太重"
适用场景:
- 超大规模图像/视频检索
- 基因序列分析
- 大型互联网平台的推荐系统
- 企业级RAG应用
三、Qdrant:Rust构建的"可组合"搜索引擎
3.1 项目概况
一句话定位:让工程师可以完全掌控检索流程的现代化向量引擎
2026年3月,Qdrant宣布完成5000万美元B轮融资,由AVP领投,博世风投、Unusual Ventures等参投。这标志着市场对"可组合向量搜索"理念的高度认可。
3.2 核心设计理念
Qdrant的核心理念是可组合性。很多向量数据库只能做"存储密集嵌入,返回最近邻"的基础操作,但Qdrant认为,生产级AI系统需要更精细的控制:
"生产级AI系统需要一个搜索引擎,其中检索的每个方面------如何索引、如何评分、如何过滤、如何平衡延迟与精度------都是可组合的决策。" ------ André Zayarni, Qdrant CEO
3.3 架构解析

技术亮点:
- Rust语言开发:内存安全、零成本抽象,性能卓越
- 精确控制:工程师可以明确选择检索组件,精确控制对相关性、延迟和成本的影响
- 多向量支持:支持密集向量和稀疏向量的混合使用
3.4 代码示例
java
import io.qdrant.client.QdrantClient;
import io.qdrant.client.grpc.Points;
import io.qdrant.client.grpc.Collections;
// 初始化客户端
QdrantClient client = new QdrantClient(
QdrantGrpcClient.newBuilder("localhost", 6334, false).build()
);
// 创建集合
Collections.VectorParams vectorParams = Collections.VectorParams.newBuilder()
.setSize(768)
.setDistance(Collections.Distance.Cosine)
.build();
client.createCollectionAsync("products",
Collections.CreateCollection.newBuilder()
.setVectorsConfig(Collections.VectorsConfig.newBuilder()
.setParams(vectorParams).build())
.build()
).get();
// 插入数据时支持丰富的元数据
Points.PointStruct point = Points.PointStruct.newBuilder()
.setId(Points.PointId.newBuilder().setNum(1).build())
.addAllVector(FloatVector.asList(0.1f, 0.2f, ...))
.putPayload("category", Points.Value.newBuilder()
.setStringValue("electronics").build())
.putPayload("price", Points.Value.newBuilder()
.setDoubleValue(299.99).build())
.putPayload("in_stock", Points.Value.newBuilder()
.setBoolValue(true).build())
.build();
client.upsertAsync("products", Collections.singletonList(point)).get();
// 带过滤条件的检索
Points.SearchPoints searchPoints = Points.SearchPoints.newBuilder()
.setCollectionName("products")
.addAllVector(FloatVector.asList(queryVec))
.setLimit(10)
.setFilter(Points.Filter.newBuilder()
.addMust(Points.Condition.newBuilder()
.setField("category")
.setMatch(Points.Match.newBuilder()
.setKeyword("electronics").build()).build())
.addMust(Points.Condition.newBuilder()
.setField("price")
.setRange(Points.Range.newBuilder()
.setLte(500.0).build()).build())
.build())
.build();
Points.SearchResponse response = client.searchAsync(searchPoints).get();
3.5 优缺点分析
优点:
- Rust语言开发,内存占用低,性能卓越
- 可组合设计,精确控制检索的每个环节
- 支持密集向量和稀疏向量的混合使用
- 轻量级部署,资源消耗小
缺点:
- 生态系统相对Milvus较小
- 分布式功能不如Milvus成熟
- 中文资料较少
适用场景:
- 对延迟要求极高的实时推荐
- 边缘AI设备部署
- 需要精细控制检索逻辑的生产系统
- 中小规模高精度检索场景
更多项目实战在项目实战网:java突击队
四、Weaviate:混合搜索的"多面手"
4.1 项目概况
一句话定位:既能做向量搜索,又能做关键词搜索的"全能选手"
Weaviate是一个开源向量数据库,以其独特的混合搜索能力和GraphQL接口著称。它内置了多种AI模型,可以自动完成向量化过程。
4.2 核心架构

4.3 混合搜索实战
Weaviate的杀手锏是混合搜索------同时进行向量搜索(找意思相近的)和传统关键词搜索(找字面匹配的),结果更精准:
graphql
# GraphQL混合搜索查询
{
Get {
Product(
hybrid: {
query: "wireless headphones with noise cancellation"
alpha: 0.5 # 向量搜索和关键词搜索的平衡权重
vector: [0.1, 0.2, ...] # 可选:直接提供向量
}
limit: 10
) {
name
description
price
_additional {
score
explainScore
}
}
}
}
Alpha参数 是关键:alpha=1表示纯向量搜索,alpha=0表示纯关键词搜索,中间值则混合两者。
4.4 模块化设计
Weaviate的模块系统允许用户轻松切换不同的AI模型:
yaml
# docker-compose.yml
version: '3.4'
services:
weaviate:
image: semitechnologies/weaviate:1.36.0
environment:
AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true'
PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
DEFAULT_VECTORIZER_MODULE: 'text2vec-openai'
ENABLE_MODULES: 'text2vec-openai,text2vec-cohere,qna-openai'
OPENAI_APIKEY: ${OPENAI_APIKEY}
2026年3月发布的Weaviate 1.36版本引入了HFresh向量索引(预览版)、Server-side Batching、Object TTL等新特性。
4.5 优缺点分析
优点:
- GraphQL接口,前端开发者友好
- 内置多种AI模型,开箱即用
- 混合搜索能力业界领先
- 模块化设计,可插拔
缺点:
- 超大规模(十亿级以上)性能需精细调优
- 社区规模小于Milvus
- 中文资料相对较少
适用场景:
- 需要结合关键词和语义搜索的企业知识库
- 内部智能搜索引擎
- 快速构建AI应用原型
- 多模态搜索场景
五、pgvector:PostgreSQL的"AI扩展包"
5.1 项目概况
一句话定位:给老朋友PostgreSQL戴上AI眼镜
pgvector是PostgreSQL的一个开源扩展,它把向量搜索能力无缝集成到全球最流行的关系型数据库中。
5.2 为什么选择pgvector?
有些小伙伴可能会问:为什么要在PostgreSQL里做向量搜索?
答案很简单------如果你已经在用PostgreSQL,pgvector就是零成本上手的选择。
sql
-- 安装扩展
CREATE EXTENSION vector;
-- 创建带向量列的表
CREATE TABLE items (
id bigserial PRIMARY KEY,
content text,
embedding vector(768) -- 768维向量
);
-- 创建HNSW索引加速查询
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);
-- 向量相似度查询
SELECT * FROM items
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 10;
5.3 数据类型和索引
pgvector支持多种向量数据类型,满足不同场景需求:
| 数据类型 | 精度 | 最大维度 | 典型场景 |
|---|---|---|---|
| vector | 单精度浮点(4字节) | ≤16,000 | 传统Embedding |
| halfvec | 半精度浮点(2字节) | ≤16,000 | 高维Embedding,内存敏感场景 |
| bit | 二进制位 | ≤64,000 | 二进制哈希,图像特征 |
| sparsevec | 稀疏向量 | ≤16,000非零 | TF-IDF特征,超高维稀疏 |
5.4 距离函数
pgvector提供了丰富的距离度量:
sql
-- 欧几里得距离(L2)
SELECT * FROM items ORDER BY embedding <-> '[3,1,2]';
-- 内积(负值,越大越相似)
SELECT * FROM items ORDER BY embedding <#> '[3,1,2]';
-- 余弦距离
SELECT * FROM items ORDER BY embedding <=> '[3,1,2]';
-- 曼哈顿距离(L1)
SELECT * FROM items ORDER BY embedding <+> '[3,1,2]';
-- 汉明距离(二进制)
SELECT * FROM items ORDER BY bit_vec <~> '101010';
-- Jaccard距离
SELECT * FROM items ORDER BY bit_vec <%> '101010';
5.5 索引类型
pgvector支持IVFFlat和HNSW两种索引:
| 索引类型 | 构建速度 | 查询速度 | 内存占用 | 适用场景 |
|---|---|---|---|---|
| IVFFlat | 快 | 中等 | 低 | 中大规模数据集 |
| HNSW | 慢 | 极快 | 高 | 低延迟要求场景 |
5.6 优缺点分析
优点:
- 无需引入新数据库,复用PostgreSQL运维经验
- 完美支持ACID事务,这是专用向量数据库不具备的
- SQL语法,学习成本几乎为零
- 可与关系数据无缝关联查询
缺点:
- 处理海量、超高维向量时,性能不如专用数据库
- 索引类型较少(仅IVFFlat和HNSW)
- 不适合纯向量搜索场景
适用场景:
- 已有PostgreSQL的中小型AI应用
- 需要严格事务保证的AI业务
- 希望用SQL统一管理关系数据和向量数据
- 快速在现有系统上增加AI能力
六、四大向量数据库对比
6.1 功能特性对比表
| 维度 | Milvus | Qdrant | Weaviate | pgvector |
|---|---|---|---|---|
| 定位 | 分布式向量数据库 | 可组合搜索引擎 | 混合搜索数据库 | PostgreSQL扩展 |
| 开发语言 | Go/C++ | Rust | Go | C |
| 架构模式 | 存算分离 | 一体化 | 模块化 | 嵌入式 |
| 索引类型 | HNSW/IVF/DiskANN/CAGRA | HNSW | HNSW | IVFFlat/HNSW |
| 混合搜索 | ✅ BM25+向量 | ✅ 稀疏+密集 | ✅ 关键词+向量 | ❌ 需应用层实现 |
| 分布式 | ✅ 原生分布式 | ⚠️ 集群版收费 | ✅ 支持 | ❌ 依赖PG |
| ACID事务 | ❌ | ❌ | ❌ | ✅ 完美支持 |
| 易用性 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 性能 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 社区活跃度 | 极高 | 高 | 高 | 极高 |
6.2 如何选型?

6.3 实战场景建议
场景1:企业知识库RAG系统
yaml
推荐: Weaviate
理由: 混合搜索能力出色,关键词+语义双路召回
配置: 使用GraphQL API,开箱即用的Embedding模块
场景2:电商商品推荐系统
yaml
推荐: Qdrant
理由: 延迟低,支持复杂过滤条件,可精确控制检索逻辑
配置: 利用payload存储商品属性,结合元数据过滤
场景3:海量图像视频检索
yaml
推荐: Milvus
理由: 分布式架构,可扩展至千亿级向量,支持GPU加速
配置: 使用DiskANN索引处理海量数据,三层存储降本
场景4:现有PostgreSQL系统增加AI能力
yaml
推荐: pgvector
理由: 零成本接入,无需引入新组件,ACID事务保证
配置: 创建vector列,添加HNSW索引,SQL无缝集成
更多项目实战在项目实战网:java突击队
总结
向量数据库已经成为AI应用的基础设施。通过本文的深度剖析,我们可以看到:
- Milvus:海量数据场景的首选,分布式架构可支撑千亿级向量,三层存储大幅降低成本
- Qdrant:追求极致控制和性能的选择,Rust语言构建,可组合设计让工程师精确掌控每个环节
- Weaviate:混合搜索专家,关键词+向量双路召回,GraphQL接口对前端友好
- pgvector:PostgreSQL生态的最佳补充,零成本接入,完美支持ACID事务
没有最好的向量数据库,只有最适合你场景的。在选择时,建议先明确:
- 数据规模:十万级?百万级?十亿级?
- 性能要求:毫秒级响应还是秒级可接受?
- 现有技术栈:是否已有PostgreSQL?
- 团队能力:是否有分布式系统运维经验?
希望这篇文章能帮助你在AI应用开发的道路上少走弯路。