Milvus 2021：把向量搜索做成数据库

待复核

是什么

Milvus 2021 这篇论文讲的是：当图片、文本、音频都被模型变成一串数字以后，系统怎么像数据库一样存、查、更新这些数字向量。

日常类比：普通数据库像图书馆按书名、作者、编号找书；向量数据库像问“哪几本书和这本的味道最像”。Milvus 做的事，就是给这种“找相似”配上书架、索引、管理员和借还流程。

向量本身可以理解成“特征坐标”：

image_vector = [0.12, -0.38, 0.91, ...]
query_vector = embed("红色运动鞋")
results = collection.search(query_vector, top_k=10)

代码看起来简单，难点在后面：数据量可能是十亿级，向量还会不断新增、删除，查询还要带上价格、城市、时间这类普通字段过滤。

这篇论文的核心贡献，是把“近似最近邻算法库”往前推了一步，变成一个能服务真实应用的向量数据管理系统。

为什么重要

不理解 Milvus，很多现代检索系统会显得很神秘：

为什么图片搜图、语义搜索、推荐召回都离不开向量。
为什么只会用 FAISS 还不够，线上系统还要处理分片、更新、过滤和容错。
为什么向量检索不是“扫一遍数组”，而是索引、硬件和查询计划一起配合。
为什么数据库世界会单独长出“向量数据库”这个新分支。

核心要点

向量是一等公民：Milvus 不是在传统表里硬塞一个 vector 列，而是围绕向量的写入、索引、搜索和生命周期来设计。
索引不止一种：IVF、PQ、HNSW、Annoy、Faiss 等路线各有取舍。Milvus 的意义是让用户根据数据量、召回率和延迟选索引。
动态数据是系统难点：论文特别强调大规模、动态向量。新数据不能等夜间批处理才可见，旧数据删除后也不能继续被搜出来。
查询常常带条件：真实业务不是只问“最像的 10 个”，还会问“北京、近 7 天、价格小于 100 的最像商品”。这就是属性过滤。
CPU 和 GPU 要分工：向量计算很吃硬件，论文讨论了缓存友好、SIMD 和 GPU 混合方案，目标是让算力花在最值钱的地方。

实践案例

案例 1：给图片库做以图搜图

collection.insert([
    {"id": 1, "image_vec": embed_image("shoe.jpg"), "brand": "A"}
])
collection.create_index("image_vec", index_type="IVF_SQ8")
collection.search(embed_image("query.jpg"), top_k=20)

逐部分解释：

embed_image 把图片压成向量，像给图片做“指纹”。
create_index 建近似搜索索引，牺牲一点精确度换速度。
search 返回相似图片，业务再把商品名、价格、库存拼回来。

案例 2：语义搜索加普通字段过滤

vector_search(text_vec, :query_vec, top_k = 20)
where category = 'database' and year >= 2021

这里有两件事同时发生：

向量搜索负责“意思接近”。
标量过滤负责“范围合法”。

如果先全量搜向量，可能拿到一堆年份不对的结果；如果先按字段过滤，候选太少又可能召回差。论文里的优化重点之一，就是让这两类条件合作。

案例 3：新数据马上可搜

写入新向量 -> 放入 growing segment -> 后台建索引 -> 合并到 sealed segment

可以把它想成餐厅临时加桌：

新客人先坐临时桌，不能等装修完才接待。
等人多了，再把临时桌整理成正式区域。
查询时同时看正式区域和临时区域，保证新数据能被搜到。

踩过的坑

把向量库当成普通 key-value 存储：只会 id -> vector 还不够，核心价值在近似搜索索引和查询执行。
只看召回率，不看延迟：召回率 0.99 很漂亮，但如果每次查 3 秒，线上推荐和搜索都扛不住。
忘了数据会变：很多 ANN 论文默认数据静态；业务里商品、用户、文档都在变。
过滤条件后补：先搜 top-10 再过滤，可能过滤完一个都不剩。过滤要进入查询计划。
把 GPU 当万能加速器：数据搬到 GPU 也有成本。小批量查询时，传输开销可能抵掉计算收益。

适用 vs 不适用场景

适用：

图片、音频、视频、文本等非结构化数据检索。
推荐系统里的粗召回阶段。
文档问答和语义搜索。
生物、化学、风控里需要按相似度找候选的任务。

不适用：

只需要主键查找或精确条件过滤。
数据量很小，内存里线性扫描已经足够。
业务不能接受近似结果，必须 100% 精确最近邻。
团队还没有 embedding 质量评估，先上系统也不会变聪明。

历史小故事（可跳过）

早期向量搜索更多是算法库的问题，典型代表是 FAISS、Annoy、SPTAG。
机器学习把图片、文本和用户行为都变成向量后，工程问题变大了：数据要分布式、要更新、要过滤、要监控。
SIGMOD 2021 的 Milvus 论文把这些问题放到数据库会议里讲，说明向量检索已经从“算法技巧”进入“数据系统”阶段。
今天再看 Milvus，它更像一个入口：通过它能理解为什么很多数据库都开始补 vector index。

学到什么

向量数据库不是魔法，它是在近似最近邻之上补齐数据库系统能力。
真正难的是动态数据、属性过滤、分布式扩展和硬件利用。
索引选择不是越高级越好，而是召回、延迟、内存和更新成本之间做平衡。
做语义搜索时，embedding 质量和系统执行同样重要，任何一边弱都会拖垮结果。

关联

faiss —— Milvus 可以站在这类 ANN 库能力之上做系统封装。
faiss-2017 —— GPU 向量搜索的代表论文。
diskann-2019 —— 大规模向量检索的另一条系统路线。
product-quantization-2011 —— 压缩向量索引的关键基础。
elasticsearch —— 都是检索系统，但一个偏文本倒排，一个偏向量相似。
postgresql —— 传统数据库补 vector 能力时，可以和 Milvus 做对照。

反向链接

（暂无反向链接）