文章导航

Vibe Coding自成长

大白话讲透：AI 时代的“记忆中枢”——向量数据库 Milvus 到底是什么？

想彻底搞懂 AI 向量数据库与大模型 RAG 的底层核心？本文用通俗易懂的大白话带你深度拆解分布式向量数据库天花板——Milvus。从高维向量与语义搜索本质，到 Segment、Partition、Collection 的数据组织，再到“存算分离 + 读写分离”的微服务分布式架构与完整读写流程，一文带你吃透 AI 时代的记忆中枢与以图搜图、语义检索落地实践！

作者：余晓峰 · 18 喜欢

在 AI 大模型（LLM）、AI Agent 和 RAG（检索增强生成）火遍全网的今天，你一定经常听到一个高频词汇——向量数据库。而在向量数据库领域，Milvus 绝对是绕不开的“顶流扛把子”。

很多人一听到“高维向量”、“分布式架构”就头大。今天，我们就用最通俗易懂的大白话，不堆砌生涩术语，彻底搞懂 Milvus 到底是个啥、它为什么厉害，以及它的内部是怎么运作的！

一、先搞懂：AI 时代的“向量”到底是什么？

要理解 Milvus，首先得知道什么是向量和语义匹配。

1. 传统搜索 vs 语义搜索

传统数据库（如 MySQL）：像个认死理的考官。你搜“唱跳rap”，它只能帮你找出字面上包含“唱跳rap”的数据。如果一篇文章写的是“练习时长两年半”，哪怕含义完全一致，只要字对不上，MySQL 就搜不出来。
向量搜索（语义搜索）：它能“懂”背后的含义。你搜“黄枫谷历飞羽”，它能心领神会地帮你匹配出“韩老魔”。

2. 万物皆可“向量化”

计算机本来不懂什么是图片、文字或声音，但 AI 模型（Embedding Model）可以把它们转化成一串串浮点数数组，这串数组就是向量（比如 [0.23, -0.11, 0.87, ...]）。

高维空间：你可以把每条数据想象成宇宙空间中的一颗星星。
距离越近，含义越像：两段话、两张图如果意思相近，它们在空间里的距离就极近。
Milvus 的核心任务：就是当你在宇宙中扔进一颗新星星（你的查询条件）时，在海量星群中，用极快的速度找出离它最近的那几颗星星。

二、什么是 Milvus？

简单一句话：Milvus 是专门用来存储海量向量数据，并提供超快、超准相似度检索的分布式数据库。

除了存向量，Milvus 还支持存标量（也就是传统数据，比如图片 ID、创建时间、标签、分类等）。这就意味着它能搞混合查询，比如：“帮我找一张和这张猫咪表情包最像的图（向量匹配），但必须是 16:9 比例且昨天上传的（标量过滤）”。

三、俄罗斯套娃：Milvus 的数据是怎么装的？

为了管好成百上千万甚至上亿条向量，Milvus 像俄罗斯套娃一样设计了层级结构：

Collection（数据表）
  └── Partition（分区/抽屉）
        └── Segment（段/最小盒子：包含数据列 + 索引）

Segment（段 —— 最小的数据盒子）：

内部采用列式存储（向量一列、ID一列、时间一列），排得整整齐齐。
Growing Segment（生长中）：刚写进来的新数据暂存这里，能查，但还没建索引。
Sealed Segment（已封存）：数据攒满一定量后，啪的一声“封箱”固化，不可再被修改，并为它单独立建索引。
Compaction（碎片合并）：零碎的小箱子太多会占句柄，系统会在后台把多个小箱子压成大箱子。

Partition（分区 —— 业务抽屉）：

如果数据库里混装了表情包、风景照、人像照，每次都全量翻一遍太慢了。
划分不同的 Partition，搜表情包时就只在“表情包抽屉”里翻，速度瞬间起飞！

Collection（集合 —— 整张大表）：

包含多个 Partition，相当于 MySQL 里的某张“数据表”。

四、从单机到分布式：Milvus 的核心架构秘密

数据量小的时候，一台电脑就能跑。但面对几亿甚至几十亿的 AI 数据，单机一定会被撑爆。Milvus 之所以被称为架构天花板，核心在于它精妙的三大拆分策略：

1. 存算分离（存储与计算解耦）

存储层：所有固化的数据段和索引，统统扔到对象存储（比如 AWS S3 或 MinIO）里。
计算层：计算节点自己不保留核心数据，按需从对象存储拉取。
好处：计算节点挂了？换一台秒级拉起；空间不够了？直接扩容对象存储，彼此互不拖累。

2. 读写分离（专人专事，绝不打架）

数据库通常“读多写少”，如果把读、写、建索引全揉在一起，CPU 跑满了连查询都会卡死。Milvus 把它们拆成了专职打工人：

DataNode（写节点）：只管把数据写入 Segment，负责落盘封存。
QueryNode（读节点）：把索引和数据加载到内存，专门拼尽全力做高并发查询。
IndexNode（索引构建节点）：专门干繁重的苦力活，为封存的数据构建 ANN（近似最近邻）加速索引。

3. 中枢调度与入口保障

Proxy（统一门面）：所有客户端请求先到它这里，由它分发给后端的节点，最后再把结果打包返回给用户。
Coordinator（协调调度大脑）+ etcd：负责给各个节点派活、记录谁管哪个 Segment，元数据统统存在 etcd 里，支持高可用切换。
消息队列（WAL 机制）：写入数据先落消息队列，即使 DataNode 突然宕机，重启后根据偏移量（Offset）接着消费，数据绝不丢失。

五、实战演练：一张猫咪表情包的一生

为了把上面的知识串起来，我们走一遍完整的读写流程：

【写入流程】

转向量：你上传了一张猫咪表情包，AI 模型将其提取为一个 128 维的浮点数组。
进大门：你带着向量和标签（ID、分类）调用 SDK，发给 Proxy。
保安全：Proxy 先把数据写进消息队列，只要进了队列，就立即告诉你“上传成功！”。
进暂存区：DataNode 从队列消费数据，写进当前的 Growing Segment。
封箱与建索引：数据攒满了，DataNode 把它封存（Flush）进对象存储变成 Sealed Segment；随后 IndexNode 开工为其生成 HNSW 向量索引。
就绪迎客：Coordinator 通知 QueryNode 将新数据与索引载入内存，正式开放检索。

【读取流程】

发起检索：你拿了一张新猫图，想要找“库里最像它的 16:9 表情包（Top-10）”。
路由分发：Proxy 问 Coordinator 拿到路由，把任务并发分发给对应的各个 QueryNode。
局部检索：每个 QueryNode 在各自管理的 Segment 内存里，同时做向量距离匹配和标量过滤，算出自己那部分的局部前 10 名。
全局聚合：Proxy 收集所有 QueryNode 的局部最优解，在内存中做全局排序，把最像的 10 张图返回给你！

总结：什么时候该用 Milvus？

✅ 适合 Milvus 的场景：语义搜索（搜文本含义）、以图搜图、以音搜音、大模型知识库检索（RAG）、AI 推荐系统。
❌ 不适合 Milvus 的场景：高频的“根据 ID 精确查找整行记录”（这种场景请老老实实交给 MySQL 或 Redis）。

一句话记住 Milvus：它是让 AI 拥有“联想记忆”的超大规模向量搜索引擎，靠着列式存储、存算分离、读写分离的现代化分布式设计，成为了 AI 时代基础设施的顶流选手。

本页目录

一、 先搞懂：AI 时代的“向量”到底是什么？