← 返回概念解读

Concept Fable精修版

Milvus

Milvus · Open-source vector database

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

织坊主学会分纱而不是加纱

江南最大的织坊有几百台织机同时开工,每台织机都要从仓库里找出最匹配的纱线。老管事的办法是把所有纱线样本挂在一面长墙上,工人跑过去一根一根比。

生意越做越大,纱线品种从几十种变成几万种。那面墙延伸到十几间屋子,工人从早跑到晚,腿比眼累。有经验的师傅靠记忆,新工人却总把相近纱线搞混。

东家先买了三面更大的墙。墙大了,比对没变快,反而因为走的路更远而更慢。三位管事分别管理左中右三面墙,互相同步靠喊,错漏更多。

工程师上门看了一眼,说你们需要把纱线拆成几组分开放,每组大小刚好能装进一个人够得着的架子。查询时,先判断要查的纱属于哪一组,再只在那组里找。

东家担心多房间会导致管理混乱。工程师给他一张总图:所有架子虽然分散,但由一个总调度台统一管理。调度台知道谁在哪,该查哪个架子,也知道新纱进来后要放到哪里。

第一个改进是给不同架子不同找法:有些用近邻绳快速找到大致相似,有些按桶分组适合海量粗查,还有些保留全量精比,给关键订单用。

第二个改进是让架子能横向增加。旺季时,新仓库接进总调度台,旧查询不用推倒重来。工人仍问同一个窗口,背后却能把工作分给许多房间。

织坊终于不用靠一面无限延长的墙支撑生意。东家明白,真正的能力在于把相似查找、分组、索引、调度和扩展放进同一套仓库秩序里。后来织坊又接到急单,东家没有再买长墙,而是先问这批纱该用哪种找法、放在哪组、是否需要精比。总调度台把问题分派下去,结果比老师傅凭记忆还稳。规模扩大后,秩序比墙面更重要。东家后来明白,仓库越大,越不能只靠一个老师傅记路。要让任何工人都能通过总调度台找到近似纱线,生意才撑得住。

揭示

这个故事讲的是:Milvus

Milvus 是一个开源分布式向量数据库,专为大规模向量相似度搜索设计。它采用存储计算分离架构,支持多种索引类型(HNSW、IVF_FLAT、IVF_PQ、DiskANN 等)、水平扩展、数据持久化和混合查询。Milvus 分为接入层(proxy)、查询节点、数据节点、索引节点和存储层(对象存储 + 消息队列),各组件可独立扩缩。在企业 RAG 中,Milvus 适合向量量级在数千万到数十亿的场景:需要高并发在线查询、增量数据持续写入、多种索引策略共存、以及对故障恢复和数据持久性的严格要求。它提供 Python/Java/Go SDK 和 RESTful API,与 LangChain、LlamaIndex 等框架集成良好。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 长墙挂纱线样本:单机内存向量检索,数据量受限且无持久化
  • 三面墙三位管事各自管:简单多实例部署,缺乏统一调度和数据一致性
  • 拆成几组放不同房间:分片(sharding),将向量数据水平切分
  • 总调度台统一管理:Milvus proxy 层,路由查询和写入到对应节点
  • 跳点图、分桶、精确:多种索引类型(HNSW、IVF、DiskANN 等)
  • 数据落盘和增量写入:基于对象存储 + 消息队列的持久化机制
  • 增加架子数量而非换大单体:水平扩展,查询节点/数据节点独立缩放
  • 把记忆拆开,保持查询一致:分布式向量数据库的核心工程挑战

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Zillizvector indexANN searchembeddingsRAG