在 AI 大模型、推荐系统、语义检索等场景的推动下，向量数据库作为承载高维特征数据的核心组件，其选型直接影响系统的部署效率、扩展性与运维成本。本文将聚焦两款热门开源向量数据库 Milvus 与 Qdrant，结合与传统文档型数据库（如 MongoDB）的差异，从技术特性、部署模式、架构组件、查询机制等维度展开全面对比，为开发者提供客观的选型参考。

一、向量数据库基础认知

1. 与传统数据库的核心区别

  • 传统 SQL 数据库以二维表（行列）组织数据，数据关联依赖字段映射；
  • 文档型数据库（如 MongoDB）：以collection为存储单元，每个元素是 JSON/BSON 结构化document，适合非结构化数据的灵活存储；
  • 向量数据库：同样以collection为存储单元，核心存储单元为「点」，每个点由唯一 ID+向量特征+自定义元数据（payload） 构成，专为高维向量的快速相似性检索设计，兼顾结构化元数据查询与高维向量计算能力。

2. 核心关键概念

  • 数据向量化：通过机器学习 Embedding 模型，将文本、图像、音频等非结构化数据转化为高维向量，精准捕捉数据核心特征（如图像向量可表示像素分布，音乐向量可涵盖节奏、流派等属性）；
  • 距离查询算法（向量检索核心）：
    • 余弦相似度：基于向量夹角判断相似度（取值-1~1，越接近 1 越相似），适合文本语义匹配等场景；
    • 点积：向量各分量乘积之和，总和越高相似度越高，归一化后等价于余弦相似度；
    • 欧几里得距离：向量空间中两点的直线距离（√∑(xi-yi)²），值越小越相似，适合高维数据的精确距离计算。

二、Milvus 核心特性解析

Milvus 是开源向量数据库领域的热门选择，基于 Golang 和 C++开发，拥有成熟的社区生态与完善的功能支持（GitHub 仓库 | 官方介绍）。

1. 部署模式

  • Milvus Lite：类似 SQLite 的轻量模式，作为 Python 本地库运行，通过本地文件持久化，无需额外依赖，适合快速体验与小规模测试；
  • 单机部署：依赖 Docker 打包所有组件，支持生产环境（需充足内存），可通过主从复制实现高可用，核心依赖 etcd（元数据存储）与 MinIO（对象存储）等外部组件（安装概述 | 单机部署指南）；
  • 分布式部署：基于 K8s 实现集群部署，暂不支持从单机模式在线升级至分布式，需提前规划架构扩展（核心组件说明）。

2. 架构设计与核心组件

采用四层架构+微服务体系，分工明确且扩展性强（架构概述 | 四层结构详解）：

  • 接入层：无状态服务，通过 Nginx 等实现负载均衡，统一接收客户端请求；
  • 协调服务：分配任务与负载均衡，保障集群资源高效利用；
  • 工作节点（核心组件）：
    • 查询节点（Query Nodes）：加载对象存储中的历史数据+日志代理的增量数据，响应向量检索请求；
    • 数据节点（Data Nodes）：将日志代理的增量数据生成快照，持久化至对象存储；
    • 索引节点（Index Nodes）：从对象存储读取 binlog 数据，构建向量索引并写入存储；
  • 存储服务：
    • 元数据存储：依赖 etcd，存储表结构、集群配置等信息，同时负责服务注册与健康检查；
    • 对象存储：支持所有兼容 S3 协议的存储服务，官方默认使用 MinIO 搭建；
    • 日志代理：记录所有数据修改操作，单机模式使用 RocksDB，分布式模式支持 Pulsar/Kafka，保障故障恢复时的数据一致性；
  • 第三方依赖：核心依赖 etcd（协调）、MinIO（存储）、Pulsar/Kafka（消息队列），共三大类第三方组件支撑架构运行。

3. 查询机制

Milvus 通过 API 网关对不同类型的数据库操作进行路由分发，保障查询效率与数据安全性：

  • DQL（数据查询语言）：如向量相似性检索，直接路由至查询节点，结合历史数据与增量数据完成检索；
  • DML（数据操纵语言）：如数据增删改，先写入消息队列（日志代理），再由查询节点、数据节点异步消费，更新数据与索引；
  • DDL/DCL（数据定义/控制语言）：如建表、删表、权限控制，通过 etcd 存储元数据，由 Worker Nodes 根据元数据执行相关操作。

三、Qdrant 核心特性解析

Qdrant 是开源向量数据库领域的另一热门选择，采用 Rust 开发，以轻量、易部署、扩展性强为核心优势（GitHub 仓库），开发者主要分布于国外（无中文文档），其部署与扩展逻辑与 MongoDB 有诸多相似性。

1. 部署模式（与 MongoDB 的对比）

  • 单机部署：极致轻量，与 MongoDB 单机部署逻辑相似——仅需单个 Docker 容器+持久化目录即可启动，无任何外部依赖（tar.gz 压缩包仅 26MB，解压后 72MB），支持生产环境（需通过快照定期备份数据）（快速开始 | 安装指南 | 快照备份说明）；
  • 分布式部署：类似 MongoDB 的多副本集群方案，支持多副本存储（官方推荐三副本），副本节点故障可自动从其他副本恢复数据，无需额外定期备份，部署门槛远低于 Milvus（分布式部署指南）。

2. 架构设计与核心组件

Qdrant 架构极简，无复杂外部依赖，核心依赖自身实现的关键技术：

  • 单二进制文件架构：整个数据库本体封装为单个二进制文件，无需额外安装组件，部署与迁移成本极低；
  • 内置 Raft 协议：自主实现 Raft 分布式共识协议，无需依赖 etcd 等第三方组件，即可维护集群一致性（Raft 协议详解）；主节点故障时，集群进入只读模式，直至新主节点选举完成，该机制与 MongoDB 主从切换逻辑类似；
  • 存储设计：无需独立对象存储或消息队列，数据直接持久化至本地目录+快照，简化运维流程。

3. 关键技术特性（分片与副本）

  • 分片（Sharding）：
    • 支持自动（一致性哈希）或自定义分片（自定义分片配置），默认分片数等于集群节点数；
    • 分片为独立数据子集，支持节点间在线移动分片，便于集群缩容；但无法动态调整分片数，需重建集合实现分片调整；
    • 官方推荐：即使单机部署，也建议划分至少 2 个分片（最优 12 个），便于后续平滑扩容至分布式集群（如 12 分片可扩展至 2/3/4/6/12 个节点，因 12 的因数较多）。
  • 副本（Replication）：
    • 创建集合时可指定副本因子（默认 1），开源版本需通过 API 手动创建分片副本（创建分片副本指南），Qdrant Cloud 支持自动复制；
    • 多副本模式下，数据冗余存储，故障时可快速恢复，无需依赖外部备份。

4. 单机到分布式的平滑升级

Qdrant 支持单机模式无缝扩展至分布式集群，升级逻辑清晰（以集合c0为例）：

  • 场景 1：单机单分片（Node1[c0_shard0_0]）→ 新增 Node2 → 仅支持副本复制（Node1[c0_shard0_0]、Node2[c0_shard0_1]），无法重新分片；
  • 场景 2：单机 2 分片（Node1[c0_shard0_0、c0_shard1_0]）→ 新增 Node2 → 可移动分片（Node1[c0_shard0_0]、Node2[c0_shard1_0]）或复制分片（双节点均含 2 个分片副本）；
  • 注：开源版本不支持已有集合重新分片，需提前规划分片数，Qdrant Cloud 提供该功能。

5. 查询机制

Qdrant 依托极简架构实现高效查询，核心逻辑：

  • 向量检索：直接关联分片与副本数据，结合距离算法（支持余弦相似度、点积、欧几里得距离）快速返回结果；
  • 元数据过滤：payload 支持 JSON 格式自定义字段，查询时可结合向量相似度与元数据条件（如 URL、原始数据标识）进行联合过滤，兼顾检索精度与灵活性；
  • 集群查询：通过 Raft 协议同步分片状态，确保多节点查询的数据一致性。

四、Milvus vs Qdrant 核心差异对比

对比维度 Milvus Qdrant
开发语言 Golang + C++ Rust
部署复杂度 依赖外部组件（etcd/MinIO 等），部署较复杂 单二进制文件，无外部依赖，部署极简
分布式升级 不支持单机在线升级至分布式 支持单机无缝扩展至分布式集群
核心依赖 需依赖 etcd、Pulsar/Kafka 等第三方组件 内置 Raft 协议，无强制外部依赖
分片调整 支持动态调整（分布式模式） 需重建集合调整分片数
高可用实现 主从复制（单机）、K8s 集群（分布式） 多副本（Raft 协议）
官方文档 支持中文，文档完善 仅英文，文档清晰
适合场景 大规模分布式场景、需复杂架构支持 快速部署、中小规模场景、平滑扩容需求

五、选型建议与实践方案

1. 选型核心决策点

  • 选 Milvus：需构建大规模分布式集群、依赖复杂架构支持（如多组件协同）、重视中文文档与国内社区支持；
  • 选 Qdrant：追求轻量部署、低运维成本、单机到分布式的平滑扩容，且纯文本/中小规模向量数据场景（如语义检索、小型推荐系统）；

2. 推荐实践方案（Qdrant 优先场景）

  1. 初始部署：采用 Qdrant 单机模式，按官方推荐划分 12 个分片（便于未来扩展至 2/3/4/6/12 个节点）；
  2. 高可用设计：若需保障数据安全，配置 2-3 个副本，利用 Raft 协议实现故障自动恢复；
  3. 数据存储优化：向量数据为冗余数据，丢失后可通过原始数据重新 Embedding 还原；payload 建议存储 URL、原始数据定位字段等轻量化信息（避免存储大字段如原始文本、图片 base64），降低存储压力；
  4. 升级路径：当数据量增长至单机上限时，直接新增节点，通过分片移动/复制扩展为分布式集群，无需重构业务逻辑。

结语

Milvus 与 Qdrant 作为开源向量数据库的佼佼者，分别适配不同的技术场景与运维需求：Milvus 胜在大规模分布式架构的成熟度，Qdrant 则以轻量、易扩展、低运维成本成为中小规模场景的优选，其部署与扩展逻辑与 MongoDB 的兼容性也降低了开发者的学习成本。

开发者可根据自身业务数据量、部署资源、扩容规划等因素灵活选型，若追求快速落地与低运维成本，Qdrant 的单机+12 分片方案值得优先尝试；若需支撑超大规模向量数据检索，Milvus 的分布式架构更具优势。如需进一步了解两款数据库的性能测试细节，可参考官方提供的 benchmark 工具与文档，也可结合自身业务场景进行针对性测试。