> **本文是「架构实战·第二季」第四篇**。前面我们讲了 RAG 的整体架构，本篇深入 RAG 的核心组件——向量库，一次性把三个主流开源向量库讲清楚。

---

## 引子：选错向量库的代价

去年我们做一个电商推荐系统，第一版用了 Chroma——轻量、上手快。三个月后数据涨到 5000 万条向量，查询延迟从 20ms 涨到 800ms。

紧急迁移到 Milvus，重写了一遍所有代码，多花 8 个人周。教训是：**向量库这种东西，等出问题再换，成本是选型时的 10 倍。**

这一篇就是为了让你不踩同样的坑。

---

## 一、向量数据库的本质

### 1.1 它解决什么问题

传统数据库擅长精确匹配：

```sql
SELECT * FROM products WHERE category = '手机';
```

但我们经常需要"模糊但语义相近"的查询：

```
查询：适合送给老人的手机
传统 SQL：找不到（没有 "适合老人" 字段）
向量库：能找（基于语义相似度）
```

向量数据库的本质是：**把高维向量的相似度搜索（ANN）做成一个独立的高性能服务**。

### 1.2 关键概念

| 概念 | 说明 |
|------|------|
| 向量（Vector） | 文本/图像/音频的数值化表示，通常 384-3072 维 |
| 距离度量 | COSINE / L2 / IP（点积），决定相似度计算方式 |
| 索引 | 用于加速 ANN 搜索的数据结构（HNSW、IVF、PQ 等） |
| Top-K | 返回相似度最高的 K 个结果 |
| 元数据过滤 | 基于属性（如时间、标签）先过滤再搜索 |

### 1.3 主流向量库全景

按生态分：

| 类别 | 代表 |
|------|------|
| 专用向量库 | Milvus、Weaviate、Qdrant、Pinecone、Chroma |
| 传统数据库扩展 | pgvector（PostgreSQL）、ES 8+、Redis Search |
| 搜索引擎扩展 | Elasticsearch 8+、OpenSearch |

本文聚焦前三款主流开源专用向量库：**Milvus、Weaviate、Qdrant**。

---

## 二、三大向量库架构对比

### 2.1 架构总览

```
Milvus（分布式优先）：
┌──────────────┐
│   Proxy      │ ← 客户端入口
└──────┬───────┘
       │
   ┌───┴────┐
   ▼        ▼
┌─────┐  ┌─────┐
│Query│  │Data │ ← 无状态微服务
│Coord│  │Coord│
└──┬──┘  └──┬──┘
   │        │
   ▼        ▼
┌──────────────┐
│ QueryNode × N │ ← 计算节点
└──────────────┘
       │
       ▼
┌──────────────┐
│ ObjectStorage │
│ MinIO/S3      │
└──────────────┘

Weaviate（单机优先）：
┌────────────────────┐
│  Weaviate Process   │
│  + Inverted Index  │
│  + HNSW Index      │
│  + Plugin System   │
└────────────────────┘
       │
       ▼
┌────────────────────┐
│  ObjectStorage     │
│  (持久化)          │
└────────────────────┘

Qdrant（Rust 单体）：
┌────────────────────┐
│  Qdrant Process    │
│  (Rust，高效)      │
└────────────────────┘
       │
       ▼
┌────────────────────┐
│  RocksDB / Memory  │
└────────────────────┘
```

### 2.2 存储引擎对比

| 引擎 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 主存储 | MinIO/S3（Segment 文件） | 自研 + 磁盘 | RocksDB + Payload 存储 |
| 向量索引 | HNSW / IVF / DiskANN | HNSW | HNSW |
| 标量过滤 | 独立检索 + 过滤合并 | 倒排索引 | Payload 索引 |
| 持久化路径 | 复杂（多服务协调） | 中等（单进程） | 简单（单进程 + RocksDB） |
| 内存占用 | 高（计算节点全内存） | 中 | 低 |

### 2.3 索引算法对比

**Milvus** 支持最多索引类型：

| 索引 | 适用规模 | 内存 | 速度 | 精度 |
|------|---------|------|------|------|
| FLAT | < 10万 | 低 | 慢 | 100% |
| IVF_FLAT | 百万级 | 中 | 中 | 高 |
| IVF_PQ | 亿级 | 极低 | 中 | 中 |
| HNSW | 千万-亿级 | 高 | 极快 | 极高 |
| DISKANN | 亿级以上 | 低（冷数据磁盘）| 中 | 高 |

**Weaviate** 默认 HNSW，可选 PQ 压缩。

**Qdrant** 默认 HNSW，内置 Scalar Quantization，压缩比友好。

### 2.4 分布式能力

这是三款差异最大的一环：

| 能力 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 内置分布式 | ✅ 原生 | ✅ 原生（Sharding + 副本） | ✅ 原生 |
| 副本机制 | 自动 | 手动配置 | 手动配置 |
| 动态扩缩容 | ✅（新增节点） | ✅ | ⚠️（需手动 rebalance） |
| 多租户（Database/Collection） | ✅（Database/Partition） | ✅（Tenant） | ✅（Collection） |
| 一致性 | 可调（强/最终） | 默认强一致 | 默认强一致 |

**Milvus 在分布式能力上最强**，但运维也最复杂。**Qdrant 在单机性能上领先**（Rust 原生），但横向扩容稍麻烦。**Weaviate 介于两者之间**，默认配置简单，扩展能力有限。

---

## 三、性能对比

### 3.1 测试环境与数据

```yaml
数据集：LAION 400M 子集，100万条 768 维向量
CPU：32 vCPU，128GB RAM
存储：NVMe SSD
Milvus：v2.4，standalone + HNSW（M=16, efConstruction=200）
Weaviate：v1.24，默认 HNSW
Qdrant：v1.8，默认 HNSW
embedding：bge-base-zh-v1.5，768 维
```

### 3.2 召回性能

| QPS | Milvus P99 | Weaviate P99 | Qdrant P99 |
|-----|-----------|-------------|-----------|
| 100 | 8ms | 12ms | **5ms** |
| 500 | 25ms | 35ms | **15ms** |
| 1000 | 60ms | 80ms | **40ms** |
| 2000 | 150ms | 200ms | **95ms** |
| 5000 | 800ms | 1100ms | **500ms** |

**结论**：Qdrant 在高 QPS 场景下性能最优；Milvus 中等；Weaviate 相对慢一些。

### 3.3 召回精度

| 召回率 | Milvus HNSW | Weaviate HNSW | Qdrant HNSW |
|--------|-------------|--------------|-------------|
| R@1 | 92.1% | 91.8% | **92.5%** |
| R@10 | 98.3% | 98.0% | **98.6%** |
| R@100 | 99.5% | 99.3% | **99.6%** |

精度差异极小，主要和 HNSW 参数（ef、efConstruction）有关。

### 3.4 资源占用

| 资源 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 内存（100万 768维） | 8GB | 6GB | **4GB** |
| 磁盘（原始向量）| 4GB | 3GB | **2.5GB** |
| 容器镜像 | 复杂（多镜像） | 单镜像 | 单镜像 |

---

## 四、能力对比

### 4.1 混合检索

混合检索 = 向量检索 + 关键词（BM25）检索 + 元数据过滤。

| 能力 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 向量 + 标量过滤 | ✅（Expression） | ✅（GraphQL） | ✅（Filter） |
| 内置 BM25 | ❌（需自建） | ✅ | ❌（需自建） |
| 全文检索 | ✅（Text Match） | ✅ | ✅（全文索引） |
| 分层命名空间 | ✅（DB → Collection → Partition） | ✅（Tenant + Class） | ✅（Collection） |

**Weaviate 内置 BM25** 是其差异化优势，做混合检索时最方便。

### 4.2 数据类型

| 类型 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 标量字段 | ✅ | ✅ | ✅ |
| 数组字段 | ✅（Array） | ✅ | ✅ |
| JSON 字段 | ✅（JSON） | ✅ | ✅（Payload） |
| 多向量（每行多个向量）| ✅（≥2.4） | ✅ | ✅ |
| 地理坐标 | ❌ | ✅（Geo） | ✅（Geo） |
| 时间序列 | ⚠️（需自配） | ⚠️ | ✅（Time Series） |

### 4.3 API & SDK

| 维度 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 主语言 | Go、C++ | Go | Rust |
| 官方 SDK | Python、Java、Go、Node | Python、Java、Go、JS | Python、Rust、Go、JS |
| REST API | ✅ | ✅（GraphQL + REST） | ✅ |
| gRPC | ✅ | ❌ | ✅ |
| ORM 兼容 | SQLAlchemy、Prisma | 自带 GraphQL ORM | 自带 |

### 4.4 运维复杂度

| 维度 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 部署复杂度 | 高（多服务 + etcd + MinIO） | 中（单服务） | 低（单服务二进制） |
| 监控 | 自带 Prom 指标 | 自带 | 自带 |
| 备份恢复 | 支持（restic） | 支持 | 支持 |
| 升级路径 | 复杂 | 中等 | 简单 |
| 高可用 | 原生 | 原生 | 原生 |

**Milvus 运维最复杂**，需要懂 etcd、MinIO、Pulsar 等组件。

### 4.5 社区与生态

| 维度 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| GitHub Stars | 28k+ | 9k+ | 18k+ |
| 主要贡献者 | Zilliz（中文社区活跃） | Weaviate（SeMI） | Qdrant（俄罗斯团队） |
| 文档质量 | 完善（中文友好） | 完善 | 完善 |
| 企业用户 | 非常多 | 中 | 增长中 |
| 云托管 | Zilliz Cloud | Weaviate Cloud Services | Qdrant Cloud |

---

## 五、选型决策树

### 5.1 按数据规模

```
小于 100 万向量？
├── 是 → Chroma / pgvector 都能用
│
└── 否
    │
    需要极致性能？
    ├── 是 → Qdrant
    │
    └── 否
        │
        数据是否超 1 亿？
        ├── 是 → Milvus（DiskANN + 分布式）
        │
        └── 否
            │
            是否需要 BM25 混合检索？
            ├── 是 → Weaviate
            │
            └── 否
                │
                已有 K8s/微服务运维体系？
                ├── 是 → Milvus（接受复杂度）
                │
                └── 否 → Weaviate 或 Qdrant（简单部署）
```

### 5.2 按场景

| 场景 | 推荐 | 理由 |
|------|------|------|
| 通用 RAG（百万级） | **Qdrant** | 性能好，部署简单 |
| 大型 RAG（亿级） | **Milvus** | 分布式能力 |
| 混合检索（语义 + 关键词） | **Weaviate** | 内置 BM25 |
| 已有 PG 团队 | pgvector | 不引入新组件 |
| 已有 ES 团队 | ES 8+ | 利用已有能力 |
| 推荐系统 | Milvus 或 Qdrant | 高 QPS |
| 时序向量 | Qdrant | 内置 Time Series |
| 中文 RAG | **Milvus** | 中文社区活跃 |

### 5.3 选型 Checklist

```
□ 数据规模预估（1 年后）
□ QPS 预估（峰值）
□ 是否需要混合检索
□ 团队运维能力
□ 数据合规要求
□ 预算（自建 vs 云托管）
□ 与现有技术栈集成成本
□ 长期发展（生态、社区）
```

---

## 六、实战：从零部署 Milvus 集群

### 6.1 单机部署（开发测试）

```bash
# Docker Compose 一键启动
wget https://github.com/milvus-io/milvus/releases/download/v2.4.0-rc.1/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker-compose up -d
```

### 6.2 集群部署（生产）

适用 1 亿+ 向量、需要高可用。

```yaml
# milvus-cluster.yaml - 简化示意
version: '3.5'
services:
  etcd:
    image: quay.io/coreos/etcd:v3.5.5
    volumes: ["./volumes/etcd:/etcd"]
  
  minio:
    image: minio/minio:RELEASE.2023-03-20T20-16-18Z
    volumes: ["./volumes/minio:/minio_data"]
  
  pulsar:
    image: apachepulsar/pulsar:2.10.4
    # ... 详细配置略
  
  rootcoord:
    image: milvusdb/milvus:v2.4.0-rc.1
    command: ["milvus", "run", "rootcoord"]
    depends_on: [etcd, minio, pulsar]
  
  datacoord:
    command: ["milvus", "run", "datacoord"]
    depends_on: [etcd, minio, pulsar]
  
  querycoord:
    command: ["milvus", "run", "querycoord"]
    depends_on: [etcd, minio, pulsar]
  
  datanode:
    command: ["milvus", "run", "datanode"]
    # 可启动多个实例
    deploy:
      replicas: 3
  
  querynode:
    command: ["milvus", "run", "querynode"]
    deploy:
      replicas: 5
  
  indexnode:
    command: ["milvus", "run", "indexnode"]
    deploy:
      replicas: 2
  
  proxy:
    command: ["milvus", "run", "proxy"]
    ports: ["19530:19530"]
    deploy:
      replicas: 2
```

### 6.3 性能压测

```python
import random
from pymilvus import connections, Collection, utility
from locust import HttpUser, task, between

class VectorDBUser(HttpUser):
    wait_time = between(0.01, 0.1)

    def on_start(self):
        connections.connect("default", host="localhost", port="19530")
        self.collection = Collection("perf_test")
        self.collection.load()

        # 准备测试查询
        self.queries = [gen_random_vector(768) for _ in range(100)]

    @task
    def search(self):
        q = random.choice(self.queries)
        self.collection.search(
            data=[q],
            anns_field="embedding",
            param={"metric_type": "COSINE", "params": {"ef": 64}},
            limit=10,
        )
```

压测关注的指标：

```promql
milvus_proxy_search_latency        # 整体延迟
milvus_querynode_sq_latency        # 计算节点延迟
milvus_datanode_consume_latency    # 数据节点消费延迟
milvus_search_throughput           # QPS
```

---

## 七、踩坑提示

### 坑 1：Milvus 索引没有加载

**症状**：查询延迟 5-10 秒，结果全是空的。

**解决**：索引建好后必须调用 `collection.load()` 加载到内存：

```python
collection.create_index("embedding", index_params)
collection.load()  # 这一步千万不能忘！
```

### 坑 2：Weaviate 内存爆掉

**症状**：内存不足，频繁 OOM。

**解决**：用 PQ（Product Quantization）压缩：

```python
client.schema.create_class({
    "class": "MyClass",
    "vectorIndexType": "hnsw",
    "vectorIndexConfig": {
        "pq": {"enabled": True, "centroids": 256, "segments": 0}  # 压缩到 1/16
    }
})
```

### 坑 3：Qdrant Collection 误删

**症状**：调用 `delete_collection` 把数据删了，没备份。

**解决**：开启快照 + 定期备份到 S3：

```bash
# 创建快照
curl -X POST http://localhost:6333/collections/my_collection/snapshots

# 列快照
curl http://localhost:6333/collections/my_collection/snapshots

# 从快照恢复
curl -X PUT http://localhost:6333/collections/my_collection/snapshots/{snapshot_id}
```

### 坑 4：HNSW 参数调优反效果

**症状**：把 efConstruction 调到 1024 想要更高精度，结果构建时间从 1 小时变成 8 小时。

**解决**：

- efConstruction：100-300 够用；
- efSearch：根据延迟预算调，一般 32-128；
- M：16-32 是合理范围。

### 坑 5：标量过滤性能差

**症状**：带 metadata 过滤的查询慢 10 倍。

**解决**：给经常过滤的字段建标量索引：

```python
# Milvus
collection.create_index("department", {"index_type": "INVERTED"})

# Qdrant
collection.create_payload_index("department", "keyword")

# Weaviate（自动索引）
```

---

## 八、本篇要点回顾

本篇系统对比了三大开源向量库：

| 维度 | Milvus | Weaviate | Qdrant |
|------|--------|----------|--------|
| 性能 | 中等 | 中 | **最强** |
| 分布式能力 | **最强** | 中 | 中 |
| 部署运维 | 复杂 | 中 | **简单** |
| 中文生态 | **最好** | 一般 | 一般 |
| 混合检索 | 需自建 | **内置 BM25** | 需自建 |
| 适合规模 | 千万-亿级 | 百万级 | 百万级 |

**选型的三个核心原则**：

1. **先看规模，再看场景，最后看团队能力**——顺序错了选型就会失误；
2. **不要追新，不要追大**——亿级以下 Qdrant/Weaviate 足够；
3. **第一次选错没关系，怕的是不知道什么时候换**——设计时留好抽象层。

---

## 九、下一篇预告

下一篇 【架构实战】**Embedding模型选型：从开源到商业API的取舍**，我们继续深入 RAG 的核心组件——Embedding 模型：

- 主流 Embedding 模型的能力评测（BGE、OpenAI、Cohere、M3E 等）；
- 商用 API vs 自建开源的成本、性能、数据安全对比；
- 跨语种、长文档、代码、表格等特殊场景的 Embedding 选择；
- 实战：从零训练/微调一个领域 Embedding 模型。

Embedding 是向量检索的灵魂——选错了整个 RAG 都会失效。

---

> **作者**：架构实战 第二季  
> **版本**：v1.0  
> **最后更新**：2026-10  
> **全文约 5000 字**

本文是「架构实战·第二季」第四篇。前面我们讲了 RAG 的整体架构，本篇深入 RAG 的核心组件——向量库，一次性把三个主流开源向量库讲清楚。

【架构实战】向量数据库选型：Milvus、Weaviate、Qdrant深度对比

研发部经理

编程语言

本文深度对比Milvus、Weaviate、Qdrant三大开源向量库，从架构、性能、混合检索到部署运维全维度解析。基于真实测试数据，揭示Qdrant高QPS性能优势、Milvus分布式扩展能力及Weaviate内置BM25特性，提供数据规模驱动的选型决策树与生产环境踩坑指南，助你避开向量库迁移高成本陷阱。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】向量数据库选型：Milvus、Weaviate、Qdrant深度对比-腾讯云开发者社区-腾讯云

【架构实战】向量数据库选型：Milvus、Weaviate、Qdrant深度对比

【架构实战】向量数据库选型：Milvus、Weaviate、Qdrant深度对比

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐