想象你是一座千万级人口城市的“智慧图书馆”馆长。这座图书馆藏书数十亿册，每天有百万读者来借阅。每一本书都有几百个数字组成的“指纹”——描述它的主题、风格与内容。读者借书时不说书名，只说“给我找一本像《三体》那样硬科幻又带悬疑感的书”，系统必须在几十毫秒内从浩如烟海的书库中捞出最相似的十本。 你一个人当然做不到，但你可以设计一套分布式协作体系：门口有接待员收单，调度中心发号施令，各分馆的书库管理员负责查书，而最深处还有一个永远在扩大的地下书库，配合一套严密的借阅流水账记录每次操作。这套体系，正是 Milvus 分布式向量数据库的骨架。 Milvus 把“找相似”这件看似不可能完成的任务拆解成无数个精细环节：把海量向量切分、分区、编段、落盘，用日志记录每次写入，再由协调器把查询分发给一群工作节点并行完成。最终，从亿级向量中检索 Top-K 相似结果，被压缩到几十毫秒内完成，这正是分布式架构与存储设计的功力所在。本文我们以这座“智慧图书馆”为线索，从整体架构到存储细节，一层层走进 Milvus 的内部世界。

岗位关联

对 AI 从业者而言，理解 Milvus 架构与存储设计，意味着你在构建 RAG、以图搜图、推荐召回等系统时，能够做出合理的容量规划与性能调优，让海量向量检索真正落地到生产环境。

目录
  1. 可视化演示
  2. 一、整体架构：图书馆的四层协作骨架
  3. 二、数据模型组织：给图书编写定位坐标
  4. 三、日志存储架构：每一步都留痕的流水账
  5. 四、对象存储层：永不缩水的地下书库
  6. 五、索引与检索：快速找书的目录术
  7. 六、分布式一致性：多馆之间的默契
  8. 七、性能优化：让图书馆高效运转
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

一、整体架构：图书馆的四层协作骨架

在这座千万人口的智慧城市里，图书馆的业务量早已不是一个馆员能承受的。你把图书馆分成四个层级：门口是接待处，负责收取借阅请求；再往里是调度中心，所有指令从这里发出；一个个专题阅览室里，图书员真正执行查询任务；而最深层的地下书库则存放着所有图书的总仓库。四层各司其职、互不干扰，是图书馆能同时服务百万读者的前提。

Milvus 分布式向量数据库的骨架正是同样的四层协作体系。接入层类似接待处，由 Proxy 和无状态 SDK 组成，负责接收客户端请求、校验权限、分发请求；协调层对应调度中心，RootCoord、DataCoord、QueryCoord、IndexCoord 各管一摊；工作节点层对应阅览室的图书员，DataNode、QueryNode、IndexNode 分别负责数据写入、查询执行和索引构建；存储层则对应地下书库，由对象存储（MinIO 等）和日志消息中间件构成，存放全部数据与操作日志。

这种“存储计算分离”的架构带来了关键收益：任意一层都能独立水平扩展。查询压力大时只需增加 QueryNode；写入量大时扩容 DataNode。为了量化扩展收益，常用以下吞吐量模型：

所以在实际扩容时，不要以为增加一台节点吞吐量就线性翻倍——协作开销是分布式系统永远的影子成本。就像图书馆新增一个分馆，需要额外配备馆际调拨的物流与对账人力，这一部分损耗永远存在。

Ttotal=n×Tnode×(1−θ)T_{\text{total}} = n \times T_{\text{node}} \times (1 - \theta)
这是水平扩展的“收益打折”模型：集群总吞吐量约等于节点数乘以单节点吞吐量，再乘以扣除协作开销后的折扣系数。
  1. 节点总数$n$ 代表参与计算的同类型工作节点数量，例如 QueryNode 的实例数。
  2. 单节点吞吐量$T_{\text{node}}$ 表示单个节点每秒能处理的查询或写入请求数，是基准性能指标。
  3. 协作开销折扣$(1-\theta)$ 是效率系数，$\theta$ 是分布式节点之间的通信与协调开销占比，节点越多 $\theta$ 往往越大。
  4. 集群总吞吐量$T_{\text{total}}$ 是该模型下集群整体每秒请求处理能力的理论估计。

二、数据模型组织：给图书编写定位坐标

图书馆里的每本书不仅要入库，还要有一个明确的“物理坐标”：哪个馆区、哪个书架、哪一格。你设计了双层的图书定位系统：第一层按大类分馆区（文学、科学、历史……），第二层在每个馆区内按编号精细到具体书架。这样一来，读者查询时先锁定馆区，再缩小到书架，层层裁剪，避免大海捞针。

Milvus 的数据模型同样如此。最上层是“集合”（Collection），相当于一座图书馆；集合内可以划分多个“分区”（Partition），相当于不同的馆区；每个分区内部的数据通过“分片”（Shard）机制分散到多个节点上并行处理；而真正落盘的最小单元是“段”（Segment），相当于书架上一本本实实在在的书。写入数据时，Milvus 会按主键哈希把数据均匀分配到各个分片，每个分片的数据最终被组织成若干段文件。

分片分配的核心公式是哈希取模：

这套坐标系统让数据能够均匀分散。就像图书馆给每本书一个精确编号，读者找书时按编号就能直达书架，Milvus 也靠这套模型在分布式环境中快速定位数据所在的节点和段文件。

shard_id=hash(pk) mod Nshards\text{shard\_id} = \mathrm{hash}(\text{pk}) \bmod N_{\text{shards}}
这里的“取模”就像按读者证的尾号分配服务窗口：主键经过哈希运算后对分片总数取余数，每个余数对应一个固定的分片。
  1. 主键值$\text{pk}$ 是数据行的主键（如 book_id），是每条记录的唯一定位标识。
  2. 哈希运算$\mathrm{hash}(\text{pk})$ 将任意长度的主键映射为整数，使分布更均匀。
  3. 取模操作$\bmod N_{\text{shards}}$ 用哈希值对分片总数取余，结果固定在 $0$ 到 $N_{\text{shards}}-1$ 之间。
  4. 分片定位最终得到的 $\text{shard\_id}$ 决定了该行数据的归属分片，写入和查询都据此路由。

三、日志存储架构：每一步都留痕的流水账

图书馆每天有海量借还操作。为了保证任何一笔记录都不丢失，你规定了一个铁律：每一位图书员在处理任何借还之前，必须先把操作写进一本只许追加、不可涂改的流水总账，然后再去更新书架台账。万一有人操作失误或系统崩溃，只要翻查流水账就能完整恢复现场。

Milvus 正是用这套“日志先行”（WAL，Write-Ahead Log）的策略保证数据可靠性。所有写入操作首先被追加到日志 Broker（如 Pulsar）中，形成一个严格的、有序的事件流；然后 DataNode 订阅这些日志，将数据包装为段，最终刷入对象存储。协调器（如 DataCoord）负责管理日志的消费位点和段的提交状态，确保每个段在“已落盘”之前，所有变更都安全地躺在日志里。

日志先行带来的写延迟模型可以用一个简化公式描述：

这个设计就像图书馆的流水账：每本书的借还记录先补上总账，然后各馆员再并行更新自己的小台账。由于总账是唯一的事实来源，无论哪个分馆出了问题，都能按总账对齐，确保数据最终一致。

twrite=tappend+max⁡(tmem,tnet)t_{\text{write}} = t_{\text{append}} + \max(t_{\text{mem}}, t_{\text{net}})
这条公式说明：写入总耗时主要取决于“追加日志”这一步的耗时，因为日志写完后，内存更新和网络传输可以并行进行，整体延迟不再受它们串行拖累。
  1. 追加日志耗时$t_{\text{append}}$ 是将一条写入记录顺序追加到日志 Broker 所需的时间，通常为毫秒级。
  2. 内存更新耗时$t_{\text{mem}}$ 是 DataNode 将数据写入内存缓冲区的耗时，极快但非瓶颈。
  3. 网络传输耗时$t_{\text{net}}$ 是日志从客户端传输到 Broker、以及从 Broker 分发到消费端的耗时。
  4. 取最大值$\max(t_{\text{mem}}, t_{\text{net}})$ 表示内存更新和网络传输并行执行后，总耗时由较慢的一方决定。
  5. 总写入延迟$t_{\text{write}}$ 因此被压缩到“追加日志 + 并行阶段较大值”，这正是日志先行架构的低延迟秘诀。

四、对象存储层：永不缩水的地下书库

图书馆的地上书架再大也有限，于是你修建了一座地下书库，容量近乎无限，但取书速度比馆内书架慢。你的策略是：热门书放在馆内阅览室，冷门书全部存入地下书库，需要时再调取。这种“分库存储”的做法让图书馆得以在有限预算内存储无限增长的书目。

Milvus 的存储层采用了同样的哲学。最终数据（段文件、索引文件、日志快照）都会以对象的形式持久化到对象存储中，最常用的是 MinIO（兼容 S3 协议）。对象存储提供近乎无限的容量和极高的可靠性，但访问延迟相对较高。因此 Milvus 将热数据缓存在本地磁盘和内存中，冷数据才下沉到对象存储。段文件被标记为 flush 后即写入对象存储，并在元数据中登记其位置。

存储成本模型可以用分层公式估算：

就像智慧图书馆会把“镇馆之宝”放在恒温展厅、把旧报刊送往郊区仓库，Milvus 通过对段生命周期的管理自动完成冷热分层，让存储成本与查询性能达成平衡。

Ctotal=V×r×phot+V×(1−r)×pcoldC_{\text{total}} = V \times r \times p_{\text{hot}} + V \times (1 - r) \times p_{\text{cold}}
总存储成本由热数据与冷数据两部分构成：热数据占比高、单价贵；冷数据占比高、单价便宜。合理控制热数据比例是降低成本的关键。
  1. 数据总体量$V$ 是全部向量数据的总存储量（如 TB 级别）。
  2. 热数据比例$r$ 是热数据（经常被访问的段和索引）占总数据的比例，通常在 10%~30%。
  3. 热数据单价$p_{\text{hot}}$ 是热存储的单位价格，对应本地 SSD 或高频对象存储。
  4. 冷数据比例$(1-r)$ 是冷数据（不常访问的历史段）的占比。
  5. 冷数据单价$p_{\text{cold}}$ 是冷存储的单位价格，对应低频对象存储或归档存储。
  6. 总成本$C_{\text{total}}$ 是两部分成本之和，帮助你在容量规划时做出权衡。

五、索引与检索：快速找书的目录术

面对几千万册藏书，逐本翻找显然不现实。图书馆有一本“分类目录卡”，按主题把书归类：读者要找“硬科幻”，目录卡直接指向科幻区，再按关键词筛选出最匹配的那几本。这套目录体系大大缩小了查找范围。

Milvus 的索引机制就是这套目录术。最常用的两类索引算法是 IVF 和 HNSW。IVF（Inverted File Index）先对数据集做聚类，把向量空间切成 $n_{\text{list}}$ 个区域，每个区域有一个质心；查询时只搜索离查询向量最近的几个质心对应的区域，而不是遍历全部数据。HNSW 则构建一张多层图，高层稀疏、底层稠密，从高层入口逐层下探，用图搜索的方式快速逼近最近邻。

IVF 的检索代价可以用候选集公式描述：

理解为：这就像读者先在分类目录里锁定“科幻类”（一个聚类），再从其中翻找心仪的几本。如果觉得候选不够多，可以同时再翻“奇幻类”和“悬疑类”（增大 nprobe），更多候选当然更容易找到目标，但也需要更多时间。索引的精心设计，让“亿里挑一”变得可行。

Cdist=Nnlist×nprobeC_{\text{dist}} = \frac{N}{n_{\text{list}}} \times n_{\text{probe}}
候选集大小 = 每个聚类平均向量数 × 需要探测的聚类数。nprobe 越大，候选越多，召回率越高但耗时也越长。
  1. 数据总量$N$ 是集合中的向量总数。
  2. 聚类中心数$n_{\text{list}}$ 是 IVF 索引划分的聚类数量，例如 1024。
  3. 每簇平均向量数$\frac{N}{n_{\text{list}}}$ 是每个聚类中平均包含的向量的数量。
  4. 探测聚类数$n_{\text{probe}}$ 是查询时实际扫描的聚类数量，通常远小于 $n_{\text{list}}$。
  5. 候选集规模$C_{\text{dist}}$ 是需计算距离的候选中向量的总数，它决定了检索的时间开销。

六、分布式一致性：多馆之间的默契

图书馆在多个城区设有分馆，每个分馆都保留同一批热门书的副本。读者们在任何分馆借书，其他分馆的副本必须同步更新，否则就会出现“A 馆显示可借、B 馆显示已借出”的矛盾。你允许各分馆之间存在极短暂的滞后，但必须保证最终一致。

Milvus 的分布式一致性机制正是围绕多副本同步展开的。数据写入时按分片被复制到多个副本，日志 Broker 以流的方式把变更事件推送给所有副本节点。Milvus 提供了可配置的一致性级别——从强一致到最终一致——让使用者根据场景在“一致性与性能”之间做权衡。节点故障时，协调器会自动摘除故障节点，并触发副本重新分配和负载均衡。

多副本可用性模型常用下面的公式估算：

这就像图书馆在同一本书购置了多份副本放在不同分馆——只要不是所有分馆的这本书同时被毁，读者就能借到书。Milvus 通过副本机制把单点故障的风险摊薄到了几乎可以忽略的地步。

A=1−(1−p)rA = 1 - (1-p)^{r}
假设每个节点的故障概率为 p，如果有 r 个副本，整个副本组只有当所有副本同时故障才不可用，所以可用性大幅提升。
  1. 单节点故障率$p$ 表示单个节点在给定时间窗口内发生故障的概率。
  2. 副本数量$r$ 是同一份数据的副本个数，例如 3 副本。
  3. 全部故障概率$(1-p)^{r}$ 是所有 $r$ 个副本同时故障的概率，由于各副本独立，该值随 $r$ 增大迅速减小。
  4. 系统可用性$A = 1 - (1-p)^{r}$ 是副本组整体的可用率，副本越多可用性越高。

七、性能优化：让图书馆高效运转

图书馆即使架构再合理，若不做精细化管理，依然会在高峰期排起长队。你总结出了三类提速手段：给热门书做专门的快速检索卡（索引调优）；把读者常问的区域做前置筛选（查询裁剪）；合理分配馆员的精力与书架空间（资源管理）。这些手段组合起来，让图书馆的响应速度大幅提升。

Milvus 性能优化的核心也在这三方面。索引调优：IVF 中增大 nlist 能提高聚类精度，HNSW 中增大 M 和 efConstruction 能提升图的质量；查询参数：调大 nprobe 或 ef 可提升召回率，同时要为查询向量指定合理的输出字段，避免不必要的数据传输；资源管理：合理规划内存、CPU 和磁盘配额，避免查询节点过载。

查询时延可以分解为三段之和：

把时延拆解成三个独立环节后，定位瓶颈变得清晰：如果大部分时间花在网络上，应该调整客户端连接和负载均衡策略；如果索引检索慢，就该检查索引参数是否合理。这座智慧图书馆的运营智慧，最终凝结成一套可度量、可优化的工程方法，这正是 Milvus 能成为生产级向量数据库的根本原因。

Ltotal=Lnet+Lindex+LmergeL_{\text{total}} = L_{\text{net}} + L_{\text{index}} + L_{\text{merge}}
总时延 = 网络传输时延 + 索引检索时延 + 结果合并时延。优化任意一段都能降低整体响应时间。
  1. 网络传输时延$L_{\text{net}}$ 是请求从客户端到服务端、以及各节点间的通信耗时，优化靠减少网络往返。
  2. 索引检索时延$L_{\text{index}}$ 是工作节点执行索引查询计算距离的耗时，优化靠调参或换用更优索引。
  3. 结果合并时延$L_{\text{merge}}$ 是协调器把多个分片返回的 Top-K 结果合并排序的耗时，优化靠裁剪候选集。
  4. 端到端时延$L_{\text{total}}$ 是三者之和，性能优化的本质就是分别压缩这三段时间。

AI 应用场景

RAG 知识库检索增强生成

阶段：数据召回与上下文构建

解决的问题：大模型幻觉严重，直接问答可信度低。传统关键词检索无法理解语义，导致召回内容不相关。Milvus 通过向量化知识库片段，在毫秒级时间内检索出语义最相关的内容作为上下文，让大模型基于事实生成答案。

具体案例：某企业搭建内部知识问答系统，将 10 万份技术文档切片并向量化后存入 Milvus，员工提问时系统先检索 Top-5 相关片段，再喂给大模型生成回答，准确率从 55% 提升到 88%。

以图搜图的电商场景

阶段：特征提取与相似检索

解决的问题：用户看到一件衣服但不知如何用文字描述。传统标签检索覆盖有限。Milvus 支持将图片经过视觉模型转换为向量后入库，用户提交图片即可在亿级商品中检索出同款或相似款。

具体案例：某电商平台将 1 亿商品图片向量化存入 Milvus，采用 IVF 索引配合 GPU 推理服务，用户拍照检索的平均响应时间 120ms，曝光点击率提升 32%。

个性化推荐召回

阶段：用户向量匹配候选物品

解决的问题：推荐系统需要从全量物品池中快速筛出用户可能感兴趣的内容。基于用户行为序列向量与物品向量做 ANN（近似最近邻）检索是最主要的召回手段之一。

具体案例：某短视频平台使用 Milvus 存储 5000 万视频向量，每次请求先在 Milvus 中召回 500 个候选视频，再由排序模型精排，整体召回时延控制在 30ms 以内。

Python 演示

python36 行
"""Milvus 向量数据库基本操作演示：创建集合、写入向量、构建索引并检索"""import randomfrom pymilvus import connections, FieldSchema, CollectionSchema, DataType, Collection connections.connect(alias="default", host="localhost", port="19530") book_id = FieldSchema(name="book_id", dtype=DataType.INT64, is_primary=True)book_vector = FieldSchema(name="book_vector", dtype=DataType.FLOAT_VECTOR, dim=8)book_name = FieldSchema(name="book_name", dtype=DataType.VAR_CHAR, max_length=256)schema = CollectionSchema(fields=[book_id, book_vector, book_name], description="图书向量集合") collection = Collection(name="book_vectors", schema=schema) rows = 1000data = [    [i for i in range(rows)],    [[random.random() for _ in range(8)] for _ in range(rows)],    [f"book_{i}" for i in range(rows)],]collection.insert(data)collection.flush() index_params = {"index_type": "HNSW", "metric_type": "L2", "params": {"M": 8, "efConstruction": 64}}collection.create_index(field_name="book_vector", index_params=index_params)collection.load() query = [[random.random() for _ in range(8)]]results = collection.search(    data=query,    anns_field="book_vector",    param={"metric_type": "L2", "params": {"ef": 16}},    limit=5,)for hits in results:    for hit in hits:        print(f"id={hit.id}, distance={hit.distance:.4f}")
目的：演示了连接 Milvus、定义集合 Schema、插入向量数据、构建 HNSW 索引并执行相似度检索的完整链路。
  1. connections.connect(alias="default", host="localhost", port="19530")建立与 Milvus 服务的连接，相当于打开图书馆大门。
  2. FieldSchema(name="book_id", dtype=DataType.INT64, is_primary=True)定义主键字段，每条数据的唯一标识。
  3. CollectionSchema(fields=[...], description="图书向量集合")定义集合的结构，相当于确定图书分类规则。
  4. collection.insert(data)批量写入向量数据，数据会被自动分片并写入日志。
  5. collection.flush()强制将内存中的段数据落盘到对象存储，确保持久化。
  6. collection.create_index(field_name="book_vector", index_params=index_params)构建 HNSW 图索引，提升检索速度。
  7. collection.load()将索引加载到内存，使查询进入可用状态。
  8. collection.search(data=query, anns_field="book_vector", ...)执行相似向量检索，返回最相近的 5 条记录。

常见误区

误区很多初学者以为有了 Milvus 这样的向量数据库，MySQL、PostgreSQL 就可以淘汰了。把所有数据都塞进向量数据库，一个库解决所有问题。

正解Milvus 是专为向量检索设计的系统，擅长海量向量的 ANN 搜索，但在事务处理、复杂 SQL 关联查询、权限管理等方面远不如关系型数据库。生产系统通常将 Milvus 与关系库配合使用：关系库存储业务元数据，Milvus 负责向量召回，两者互补。

为何常见：看到 Milvus 既能存向量又能存标量字段，容易误以为它完全覆盖了关系库的功能，忽略了事务与复杂查询能力的差距。

误区网上不少文章鼓吹 HNSW 是“最强索引”，初学者因此在所有场景中都无脑选择 HNSW，认为它召回高、速度快，应该无条件使用。

正解HNSW 的查询性能好，但构建索引耗时更长、内存占用更大；IVF 构建快、内存友好，适合超大容量场景。在十亿级数据、内存受限的环境下，IVF 往往比 HNSW 更实用。索引选择必须结合数据规模、内存预算和延迟要求综合判断。

为何常见：演示环境中 HNSW 在百万级数据上表现惊艳，但生产环境的数据规模与资源约束完全不同，容易产生以偏概全的结论。

误区一些使用者认为既然数据能按分区裁剪，那就尽量多建分区，让每个分区很小，查询只扫一个分区应该更快。

正解分区数量过多会带来元数据管理开销，协调器需要维护大量分区状态，反而拖慢整体性能。分区的目的是逻辑隔离与裁剪，分布式扩展主要靠分片完成。一般建议按业务维度（如时间、租户）设计合理数量的分区，而非盲目追求数量。

为何常见：把分区和分片混为一谈，误以为分区也参与分布式负载均衡，实际上分片才是数据分布的真正机制。

误区为了“保险起见”，把 Milvus 的一致性级别设为强一致，认为这样数据最安全可靠。

正解强一致意味着每次读写都要等待所有副本确认，时延显著增加。对于大部分检索场景，轻微滞后完全可接受，选择最终一致性或会话一致性即可大幅降低延迟。一致性级别应该根据业务容忍度来选择，而不是一律拉满。

为何常见：人们对“一致性越高越好”的直觉来自单机数据库经验，在分布式系统中一致性是有成本的，需要重新校准认知。

误区很多初学者认为 embedding 模型的输出维度越高，语义表达越丰富，检索效果就越好，于是选择 1024 维甚至更高维度的向量。

正解维度升高会显著增加存储开销和距离计算耗时，而且超过一定维度后语义增益迅速衰减。同时，高维空间中的距离趋于均匀，反而可能降低检索区分度。实践中 384~768 维通常是效果与成本的平衡点，具体应通过离线评测决定。

为何常见：模型厂商的宣传和大模型的普及让大家追求“更大更强”，忽略了向量检索场景中维度是成本因子的事实。

面试题

Q1. 在 Milvus 中，向量数据持久化的最小数据单元是什么？

单选题 · easy

  • A.集合（Collection）
  • B.段（Segment）← 正确答案
  • C.分区（Partition）
  • D.分片（Shard）

答案：B。段（Segment）是 Milvus 中数据持久化和索引构建的最小单元。写入数据先形成内存中的段，flush 后落盘成为不可变段文件。集合是顶层组织，分区用于逻辑裁剪，分片用于数据分布，它们都不是持久化最小单元。

Q2. Milvus 的 WAL（预写日志）最核心的作用是什么？

单选题 · easy

  • A.加速索引构建速度
  • B.压缩向量文件体积
  • C.崩溃时通过重放日志恢复数据← 正确答案
  • D.替代对象存储的后端

答案：C。WAL 采用日志先行策略，所有写入先追加到日志再更新内存。一旦节点崩溃，可以从日志重放尚未落盘的变更，保证数据不丢失。它并不直接加速索引构建或压缩文件，更不替代对象存储。

Q3. 以下哪些组件属于 Milvus 的存储层？

多选题 · mid

  • A.对象存储（MinIO/S3）← 正确答案
  • B.日志 Broker（Pulsar）← 正确答案
  • C.代理 Proxy
  • D.元数据存储（etcd）← 正确答案

答案：ABD。存储层由对象存储（存放段文件与索引）、日志 Broker（存放变更事件流）和元数据存储（记录集合与段的状态信息）构成。Proxy 属于接入层而非存储层。

Q4. Milvus 中负责集合 Schema 管理与 DDL 操作的协调器是哪一个？

单选题 · mid

  • A.RootCoord← 正确答案
  • B.DataCoord
  • C.QueryCoord
  • D.IndexCoord

答案：A。RootCoord 是 Milvus 的总控协调器，负责处理集合的创建/删除、Schema 管理以及 DDL 操作。DataCoord 管理段的存储，QueryCoord 分配查询任务，IndexCoord 负责索引构建，三者均在各自领域内协作。

Q5. 分片计算公式 shard_id = hash(pk) mod N 中，N 代表什么？

单选题 · mid

  • A.向量字段维度
  • B.分片总数← 正确答案
  • C.每个分片的向量数
  • D.集合的分区数量

答案：B。N 是分片总数（Shard 数量）。哈希取模的结果范围是 0 到 N-1，每个结果对应一个分片。这个公式让数据均匀分散到全部分片上，实现并行写入与查询。

Q6. 以下哪些调参动作能提升 HNSW 索引的召回率？

多选题 · hard

  • A.增大 efConstruction← 正确答案
  • B.增大 M← 正确答案
  • C.减小 ef
  • D.增大向量维度

答案：AB。efConstruction 控制建图时的候选队列大小，M 控制每个节点的最大连接数，两者增大都会提升图质量从而提高召回率。减小 ef 反而降低查询精度。向量维度属于模型层面，不是索引参数，且增大维度不必然提升召回。

Q7. Milvus 水平扩展时总吞吐量增长通常低于节点数增长，可能的原因有哪些？

多选题 · mid

  • A.节点间协调通信开销← 正确答案
  • B.协调器成为瓶颈← 正确答案
  • C.向量维度选择过高
  • D.数据分片分布不均匀← 正确答案

答案：ABD。分布式系统的吞吐量受协调开销（A）、协调器单点瓶颈（B）和数据倾斜（D）制约，这些因素使实际扩容收益低于线性增长。向量维度与扩展非线性没有直接关系。

Q8. IVF 索引中增大 nprobe 参数，最直接的结果是什么？

单选题 · hard

  • A.召回率上升且查询时延上升← 正确答案
  • B.召回率上升且查询时延下降
  • C.召回率下降且查询时延上升
  • D.召回率下降且查询时延下降

答案：A。nprobe 是查询时扫描的聚类数量。增大它意味着搜索更多聚类，候选集变大，因此召回率上升；但同时需要计算更多距离，时延也随之上升。这是召回与性能之间最经典的权衡。

Q9. 在存储计算分离架构下，扩容 QueryNode 主要提升哪方面能力？

单选题 · extreme

  • A.数据持久化容量
  • B.查询并发处理能力← 正确答案
  • C.WAL 日志写入吞吐
  • D.元数据一致性保证

答案：B。QueryNode 是查询执行节点，负责向量检索和结果合并，扩容 QueryNode 直接提升查询并发能力和吞吐量。持久化容量属于对象存储，WAL 吞吐属于日志 Broker，元数据一致性属于协调器职责。

Q10. 关于 Milvus 的存储设计，以下哪些说法是正确的？

多选题 · mid

  • A.日志 Broker 只保留近期变更日志← 正确答案
  • B.对象存储保存最终的全部段数据← 正确答案
  • C.内存不参与查询加速
  • D.本地磁盘仅作为缓存使用← 正确答案

答案：ABD。日志 Broker 是流式中间件，数据最终刷入对象存储后日志即可被消费回收，所以 A 正确。对象存储是最终存储层，B 正确。本地磁盘用于缓存热数据加速查询，D 正确。内存当然参与查询加速，段索引加载到内存后查询性能大幅提升，C 错误。