目录

1. 向量数据库基础
2. 底层原理
3. 架构设计与数据流
4. 主流向量数据库介绍
5. 总结与选型建议

---

向量数据库基础

什么是向量数据库？

向量数据库是专门用于存储和检索高维向量的数据库系统。随着机器学习和深度学习的发展，文本、图像、音频等非结构化数据常被转换为向量表示（Embedding），用于语义搜索、推荐系统等场景。

向量的概念

在计算机中，向量通常指一个高维的数值数组，用于表示对象的某种特征或嵌入。例如：

• 768维的浮点数向量表示一句话的语义
• 2048维向量表示一张图像的视觉特征

通过比较向量之间的距离来衡量相似度，实现语义层面的模糊查询，而不局限于精确匹配。

向量搜索的意义

传统数据库主要处理结构化数据，通过主键或索引字段实现精确匹配查询。而向量搜索根据向量之间的距离（如欧氏距离或余弦相似度）来查找"最近邻"的向量，从而实现：

• 语义文本检索：找到意思相近的文档
• 以图搜图：通过图像特征找相似图片
• 个性化推荐：基于用户和物品的向量相似度推荐
• 异常检测：发现相似或不同的模式

与传统数据库的差异

特性	传统关系型数据库	向量数据库
查询类型	精确匹配（WHERE name = ‘Alice’）	相似度查询（找最相近的10个向量）
索引结构	B树、哈希索引	HNSW图、倒排索引等ANN算法
查询目标	“有哪些项满足精确条件？”	“有哪些项与给定项最相似？”
数据模式	固定Schema，支持事务和复杂SQL	关注快速向量比对和召回率
额外特性	支持元数据过滤	可在相似度搜索基础上增加结构化筛选

---

底层原理

向量距离度量

在进行向量相似度搜索前，需要定义"相似"的含义。常见的度量方式包括：

1. 欧氏距离（L2）

• 直观的几何距离
• 计算两个向量坐标差的平方和再开方
• 距离越小表示越相似

2. 余弦相似度（Cosine）

• 计算两个向量夹角的余弦值，范围[-1,1]
• 数值越大表示越相似（夹角小，方向相近）
• 通常使用 1 - cos(θ) 或余弦距离衡量"差异"
• 适用于已归一化的向量，常用于文本语义相似

3. 内积（Inner Product）

• 又称点积，反映两个向量在同一方向上的投影大小
• 常用于评估向量与潜在特征的匹配程度
• 在推荐场景下，可能用最大内积度量相似度

常见的向量索引结构

近似最近邻（ANN）算法是向量数据库加速查询的基石。直接对所有向量逐一计算距离的时间复杂度为O(n)，而ANN索引通过预处理和巧妙的数据结构，将查询复杂度降低到远小于O(n)。

1. 倒排文件索引（IVF）

原理：

• 使用聚类方法将向量集划分为若干簇，每个簇有一个代表中心（质心）
• 检索时，先找到最近的几个簇中心，只在这些簇内搜索最近邻
• 类似于"先粗略定位再精细查找"

关键参数：

• nlist：簇中心个数
• 访问的簇数：影响速度/精度平衡

2. 乘积量化（PQ）

原理：

• 向量压缩技术，将每个向量分成若干子向量
• 对每个子空间训练一个小型代码本（codebook）进行量化
• 每个原始向量用几个字节的码字表示
• 通过查表快速得到近似距离

优势：

• 大幅减少内存占用
• 保持较高的召回率
• 常与IVF结合形成IVF-PQ索引

3. HNSW图（Hierarchical Navigable Small World）

原理：

• 基于图的近邻搜索算法（2018年提出）
• 构建分层有向图：
  • 顶层节点连接范围较远的邻居
  • 底层节点连接局部邻居
• 查询时从上层开始，通过贪心策略逐层下跳，快速接近目标区域

特点：

• 查找速度快且精度高
• 需要将图结构存于内存，内存消耗相对较大
• 可结合PQ压缩存储
• 是目前主流向量数据库普遍支持的索引

关键参数：

• M：每个节点邻居数
• ef：查询时的搜索宽度

4. DiskANN

原理：

• 微软研究提出的磁盘上的ANN算法
• 只将轻量级的索引结构放在内存
• 大量原始向量和索引的其余部分存储在磁盘
• 优化磁盘I/O访问模式

优势：

• 在64GB内存的机器上处理十亿规模、百维以上的向量数据
• 保持95%以上召回率的同时将查询延迟控制在毫秒级
• 极大降低内存需求

适用场景：超大规模向量搜索，可接受依赖磁盘速度的场景

近似最近邻（ANN）搜索机制

查询流程

1. 查询预处理

   • 将输入数据转换为向量（如用BERT将文本编码为向量）

2. 粗筛阶段

   • 利用索引结构快速缩小候选集
   • IVF：选出若干最近的聚类中心
   • HNSW：通过图搜索锁定小区域

3. 精筛阶段

   • 对候选集进行精确距离计算
   • 可能使用原始未压缩向量重新计算（re-ranking）
   • 得到最后的Top K最近邻结果

4. 后处理

   • 应用用户指定的过滤条件
   • 对距离进行归一化或转换为相似度分值
   • 取出并附加元数据字段

性能权衡

• 召回率（Recall）：衡量ANN搜索结果与真实最近邻重合程度的指标
• 用户可通过调整参数在召回率和查询延迟之间权衡
• 通常能达到接近100%的召回率

向量压缩和存储优化

1. 量化与降维

量化技术：

• PQ（乘积量化）：通过有限码本表示向量
• OPQ（优化的乘积量化）：改进方法

降维技术：

• PCA或AutoEncoder将向量映射到更低维空间
• 典型地将上千维压缩到几十或几百维
• 需要权衡信息损失

2. 低精度存储

• 使用8位或16位整数/浮点表示向量分量
• 内存占用缩小至原来的1/2甚至1/4
• 通过SIMD指令并行计算距离

示例：

• 100万条、512维的单精度浮点向量集合：约2GB内存
• 压缩为INT8后：约0.5GB内存

3. 内存+磁盘混合存储

策略：

• DiskANN：轻量级结构在内存，数据页在磁盘
• 分批加载：动态加载部分向量到内存
• 分片（sharding）和副本：多节点分担数据

---

架构设计与数据流

分布式架构设计理念

主流向量数据库采用分布式架构，满足大规模数据的存储、计算和高可用需求。共性设计理念包括：

1. 计算与存储分离

• 计算层：向量运算、索引构建、查询服务
• 存储层：数据持久化、元数据管理
• 便于各自独立扩展

2. 无状态服务与协调调度

• 前端节点无状态，可水平扩展处理请求
• 协调组件管理元数据、分配任务
• 实现负载均衡和容错

3. 分片与副本

• 数据通过水平切分（sharding）存储在多个节点
• 配置副本节点实现数据冗余备份
• 某节点故障时其他副本仍可提供服务

Milvus 2.0 架构示例

组件架构

微服务组件：

• Proxy：代理，请求入口
• RootCoord：根协调器，全局元数据管理
• QueryCoord：查询协调器，查询调度
• DataCoord：数据协调器，数据写入管理
• QueryNode：查询节点，执行查询
• DataNode：数据节点，数据写入
• IndexNode：索引节点，索引构建

底层存储：

• Meta-Store：元数据存储（Etcd）
• Log Broker：日志消息队列（Kafka/Pulsar）
• Object Storage：对象存储（S3/MinIO）

数据插入流程

1. 客户端通过SDK连接到Proxy
2. Proxy将插入请求转发给DataNode
3. DataNode写入内存缓冲和日志（持久化增量数据）
4. 异步批量写入对象存储
5. 通知IndexNode构建索引
6. 更新元数据记录索引文件信息

查询流程

1. 客户端发送查询请求（向量+可选过滤条件）到Proxy
2. Proxy在元数据中查明相关分片的QueryNode
3. 将查询向量分发到这些QueryNode并行执行搜索
4. 每个QueryNode使用本地索引找到局部Top K结果
5. Proxy汇总所有结果，按距离重新排序取全局Top K
6. 返回最终结果集给客户端

其他架构模式

Weaviate架构

• 无主（leaderless）分布式架构进行数据复制
• 任何节点都可以直接接收写请求
• 通过协调协议使副本节点同步
• 使用Raft共识算法管理集群元数据
• 数据层面去中心化，元数据层面轻量中心化

Qdrant架构

• **分片（Shard）+ 副本（Replica）**机制
• 一个集合划分为多个分片，由不同节点存储
• 每个分片可配置多副本
• 使用Raft共识维护集群拓扑和集合结构一致性
• 写请求由任意节点受理，协调写入相关分片的所有副本

Faiss

• 不是分布式服务，而是C++库
• 没有服务器架构，通常被嵌入在应用中使用
• 需要在多节点部署时，应用层自行实现分片或RPC调用
• 追求极致的单节点性能，支持多GPU、多线程并行

---

主流向量数据库介绍

Faiss

基本信息

• 开发者：Facebook AI Research
• 语言：C++编写，提供Python接口
• 定位：相似度搜索库，而非完整数据库系统

核心特点

1. 高性能优化

   • 使用SIMD指令、多线程并行
   • GPU版本利用CUDA加速
   • 在CPU和GPU上高效运行

2. 多种索引算法

   • 内置IVF、PQ、HNSW、LSH等
   • 支持上亿级别向量数据集
   • 单机上实现极高的查询吞吐和低延迟

3. 使用方式

   • 作为库嵌入应用代码中
   • Python或C++中调用
   • 侧重于向量搜索功能
   • 不包含数据持久化、用户鉴权等数据库特性

应用场景

• 机器学习模型的向量检索加速
• 推荐系统中用户或物品Embedding的近邻搜索
• NLP任务中海量句向量的相似度匹配
• 检索增强生成（RAG）
• 适合不需要复杂部署的原型项目
• 单机范围内（甚至一台机器加多块GPU）的高效检索

局限性

• 需要与其他存储层或服务层结合实现持久化
• 不提供分布式查询能力
• 缺乏完整的数据库特性（事务、查询语言等）

---

Milvus

基本信息

• 开发者：Zilliz
• 语言：C++和Go混合实现
• 定位：企业级开源向量数据库

核心优势

1. 灵活性

   • 多索引支持：IVF_FLAT、IVF_PQ、HNSW、ANNOY、DiskANN等
   • 多距离度量：Euclidean、Cosine、Inner Product等
   • 少数实现了DiskANN算法的向量数据库之一

2. 分布式与弹性

   • Proxy、Coordinator、Worker模块划分
   • 无状态和消息机制实现计算节点横向扩展
   • 支持数据分片和副本
   • 根据需要扩展查询节点数量提高吞吐

3. 持久化和数据管理

   • 数据持久化到对象存储或本地磁盘
   • 用etcd维护元数据
   • 用Kafka/Pulsar保证数据增量日志
   • 提供强一致性读取选项、分层存储、备份等功能

4. 易用性

   • 高级SDK和简单易用的接口
   • 支持SQL风格的查询（MilvusQL或与Spark/Flink集成）
   • 图形化管理界面（Attu）
   • MilvusClient简化常用操作

应用场景

1. 搜索引擎

   • 存储文档的文本向量和标签属性
   • 混合查询能力实现"先语义后过滤"的检索

2. 推荐系统

   • 存储上亿级别的商品向量
   • 存储商品的类别、价格等属性
   • 通过向量相似度找候选商品，用属性过滤结果

3. 异常检测与网络安全

   • 将事件数据嵌入存入Milvus
   • 通过相似度搜索发现异常模式

注意事项

• 系统架构相对复杂，对基础设施要求较高
• 小规模场景下可能"大材小用"
• 部署和维护成本偏高
• Zilliz提供云托管服务和企业支持

---

Weaviate

基本信息

• 开发者：SeMI公司
• 语言：Go
• 定位：一站式AI语义数据库

核心特点

1. 开发者友好

   • 详尽而易懂的文档和教程
   • 查询接口采用GraphQL，直观易用
   • 支持REST API和多种语言客户端
   • 容器化部署简单（docker-compose up）

2. 内置向量化模块

   • 集成多种向量生成模块
   • 可连接Hugging Face模型或OpenAI API
   • 插入文本数据时自动转换为嵌入向量
   • 支持文本、图像、2D/3D对象向量化

3. 混合搜索

   • 支持纯向量相似度搜索
   • 支持关键词搜索
   • Hybrid Search：向量+关键词混合搜索
   • GraphQL查询中同时指定向量查询和关键词条件

4. 可扩展性

   • 通过分片和复制扩展
   • 无中心节点的数据复制（Cassandra风格）
   • 任意节点可充当协调者
   • Raft协议保证模式变更的一致性
   • 已展示百亿级别数据运行能力

应用场景

1. 快速原型开发

   • 适合初创项目快速上线
   • 提供开箱即用的所有组件：存储、向量化、查询接口

2. 文档检索问答系统

   • 直接导入文档（自动生成嵌入向量）
   • 通过GraphQL查询根据用户问题找相关文档片段

3. 在线学习场景

   • 数据持续更新，每日新增向量
   • 无主架构使写入过程流畅
   • 不会因集中写入节点成为瓶颈

社区与支持

• 活跃的论坛和Slack频道
• 开发团队积极与社区交流
• 不断展示新的应用案例

---

Qdrant

基本信息

• 语言：Rust实现
• 定位：面向生产环境的高性能向量检索

核心特点

1. 高性能与持久化

   • 得益于Rust的性能和安全性
   • 内存管理精细
   • 从一开始就支持向量数据持久化到磁盘
   • 默认采用HNSW作为索引（Rust实现）
   • 优化并发和内存管理

2. Payload支持

   • 将结构化的额外字段与向量一起存储
   • 检索时基于这些字段做过滤
   • 整合简洁易用

3. 简单易用

   • 提供RESTful API和gRPC接口
   • 多种语言的客户端（Python、TypeScript、Go、Java等）
   • Docker一条命令运行单节点实例
   • 学习曲线小，文档通俗易懂

4. 动态集群扩展

   • 从0.8版本开始支持集群模式
   • 分片和副本机制
   • 通过Kubernetes或自带集群管理创建多节点集群
   • 自动将查询路由到包含目标分片的节点
   • 正在完善自动重新分片、负载均衡等功能

应用场景

1. 有限资源下的高性能应用

   • 千亿数据规模以下运行
   • 要求每日实时更新
   • 单机利用SSD存储较多数据
   • 可方便扩展到多节点

2. 复杂过滤的语义查询

   • 支持基于payload的灵活过滤查询（布尔、范围等）
   • 在向量相似度检索同时过滤不符合条件的项
   • 适合个性化推荐或安全过滤

3. 边缘部署

   • Rust开发，编译后效率高且单机依赖少
   • 可部署在边缘设备或资源受限环境
   • 在本地执行嵌入式语义搜索，不依赖云服务

社区与生态

• GitHub星标增长速度快
• 官方积极优化产品
• 提供云服务（Qdrant Cloud）
• 社区氛围务实

---

总结与选型建议

性能与规模对比

数据库	单机性能	分布式能力	适用规模	部署复杂度
Faiss	极高	无（需自行实现）	亿级（单机）	低
Milvus	高	完善	百亿级+	高
Weaviate	中高	完善	百亿级	中
Qdrant	高	逐步完善	千亿级	中低

选型建议

1. 原型开发与小规模应用

• 首选：Faiss或Qdrant
• 理由：部署简单，性能优秀，快速上手

2. 企业级大规模部署

• 首选：Milvus或Weaviate
• 理由：完善的扩展和容灾机制，企业级功能

3. 快速迭代的AI应用

• 首选：Weaviate
• 理由：开箱即用，内置向量化，GraphQL友好

4. 资源受限或边缘部署

• 首选：Qdrant
• 理由：Rust实现高效，单机依赖少

5. 追求极致单机性能

• 首选：Faiss
• 理由：高度优化，支持GPU加速

技术趋势

• 计算与存储分离成为主流架构
• 混合搜索（向量+关键词）日益重要
• 磁盘型索引（如DiskANN）解决超大规模存储问题
• 云原生和托管服务降低运维成本
• 多模态支持（文本、图像、音频等）成为标配

关键考虑因素

在选择向量数据库时，应考虑以下因素：

1. 数据规模：当前和预期的向量数据量
2. 查询性能：QPS要求和延迟容忍度
3. 精度要求：可接受的召回率水平
4. 基础设施：可用的硬件资源（CPU/GPU/内存/磁盘）
5. 团队能力：运维能力和学习曲线
6. 成本预算：硬件成本、云服务费用、人力成本
7. 功能需求：是否需要混合查询、实时更新等特性

---

参考资源

官方文档

• Faiss GitHub
• Milvus 官方文档
• Weaviate 开发者文档
• Qdrant 官方文档

学习资源

• 向量数据库基准测试：VectorDBBench
• ANN算法基准：ann-benchmarks.com
• 相关论文：HNSW、DiskANN、Product Quantization

社区支持

• Milvus：Slack社区
• Weaviate：论坛
• Qdrant：Discord频道

---