如果说第三期的pgvector解决了PostgreSQL拥抱向量的问题，那么这一期我们要聊的Milvus，解决的是超大规模向量检索的终极命题。
在AI应用从"能用"走向"好用"的2026年，一个残酷的现实浮出水面：pgvector撑不住了。当向量数据突破千万级、甚至迈向亿级时，PostgreSQL的单机架构开始力不从心。这时，一个专为"海量"而生的选手站了出来——Milvus。
Milvus是LF AI & Data基金会旗下的顶级开源项目，由Zilliz公司发起，是目前全球最流行的云原生向量数据库。它不是pgvector的"替代品"，而是pgvector的"进阶版"——当你的数据量达到pgvector的瓶颈时，Milvus就是那个扛起PB级向量检索的答案。
今天，我们就从DBA的视角，从五个方面全方位拆解这款"向量数据库之王"。
Milvus 是一个开源的、云原生的向量数据库，专为海量向量数据的高性能相似性搜索而设计。
核心定位："当pgvector不够用时，你需要的向量数据库。"
为什么有了pgvector还需要Milvus？这不是"重复造轮子"，而是场景分化：
| 十亿~百亿级 | ||
| 分布式集群 | ||
| 超大规模、高性能专用 |
简单来说：100万条以内用pgvector，100万条以上考虑Milvus。
Milvus的故事始于2019年，由Zilliz团队开源。到2026年，它已成为GitHub上Star数超3.4万的明星项目，被超过2000家企业采用，涵盖推荐系统、图像检索、药物发现、RAG等场景。
2. 核心技术架构：存算分离的四层设计
Milvus最引以为傲的是其云原生架构。它遵循"数据平面"与"控制平面"分离的原则，由四个主要层组成，各层独立扩展。
第1层：访问层（Access Layer）
组件：Proxy（代理节点）
Proxy是无状态的网关节点，是用户请求的唯一入口。它负责：
• 客户端请求验证与路由 • 请求的负载均衡（配合Nginx、K8s Ingress） • 结果聚合：由于Milvus采用MPP架构，多个节点返回的中间结果需要由Proxy统一聚合后再返回客户端
运维要点：Proxy无状态，可随意水平扩展。生产环境建议至少部署2个Proxy + 负载均衡器。
第2层：协调器层（Coordinator Layer）
组件：rootCoord、dataCoord、queryCoord、indexCoord
这是Milvus的"大脑"。协调器负责维护集群拓扑、调度所有任务类型、保证集群级一致性。
• rootCoord：处理DDL/DCL请求（创建/删除Collection、分区、索引），管理TSO（时间戳Oracle） • dataCoord：管理数据节点的任务调度，包括数据压缩、索引构建、垃圾回收 • queryCoord：管理查询节点的拓扑和负载均衡 • indexCoord：管理索引构建任务的调度
运维要点：协调器是有状态的，生产环境需启用enableActiveStandby实现高可用。
第3层：工作节点层（Worker Layer）
组件：Data Node、Query Node、Index Node
这是Milvus的"手脚"，执行协调器下发的具体任务。由于存算分离，工作节点是无状态的。
三种工作节点：
| Data Node | ||
| Query Node | ||
| Index Node |
数据流转：插入请求 → Proxy → Data Node写WAL → 数据落盘到对象存储 → Index Node异步建索引 → Query Node加载索引提供服务。
第4层：存储层（Storage Layer）
组件：元数据存储、日志存储、对象存储
这是Milvus的"骨骼"，负责数据的持久化。
• 元存储（etcd）：存储Collection Schema、消息消费进度等元数据快照。要求高可用、强一致性。 • 日志存储（WAL）：默认使用Pulsar，也支持Kafka。记录所有数据变更操作，保证故障恢复。v2.5+版本引入Woodpecker——零磁盘的云原生WAL实现。 • 对象存储（MinIO/S3）：存储binlog（向量/标量数据）和索引文件。支持AWS S3、阿里云OSS等。
存算分离的价值：
• 计算节点（Query Node）可以按需扩缩容 • 存储成本大幅降低（对象存储约0.02美元/GB/月） • 故障恢复快：节点挂了只需重新从对象存储加载数据
3. 核心功能：不止于向量检索
3.1 多向量类型支持
Milvus支持6种向量数据类型，覆盖各种AI场景：
多向量字段：一个Collection最多可包含10个向量字段，支持多模态混合检索（如图片向量+文本稀疏向量同时搜索）。
3.2 丰富的索引算法
Milvus集成Knowhere（封装了FAISS、HNSWlib等），提供10+种索引类型：
| FLAT | ||||
| IVF_FLAT | ||||
| IVF_PQ | ||||
| HNSW | 极快 | 高性能首选 | ||
| DISKANN | 超大数据集（PB级） | |||
| GPU索引 | 毫秒级 |
索引选择铁律：
• 内存充足 + 追求性能 → HNSW • 内存受限 + 数据量大 → IVF_PQ • 数据量10亿+ → DISKANN • GPU资源丰富 → GPU索引
3.3 混合检索：向量+标量过滤
Milvus的真正杀手锏是混合检索——在同一查询中同时进行向量相似度搜索和标量字段过滤。
典型场景：电商"相似商品+价格区间"
# 伪代码示意
results = collection.search(
data=[query_vector],
anns_field="embedding",
expr="price > 100 and price < 500 and category == 'electronics'", # 标量过滤
param={"metric_type": "COSINE", "params": {"nprobe": 10}},
limit=10
)
实现原理：Milvus使用预过滤（先标量过滤再向量搜索）或后过滤策略，通过倒排索引加速标量过滤。
3.4 时序一致性
Milvus通过TSO（Timestamp Oracle）提供可配置的一致性级别：
| Strong | ||
| Bounded | ||
| Session | ||
| Eventual |
DBA提示：一致性越强，查询延迟越高。大多数场景Bounded足够。
4. 部署方式与高可用架构
4.1 三种部署模式
| Standalone | |||
| Cluster | |||
| 云托管 |
Standalone：单机版本，包含etcd+MinIO+Milvus，适合快速上手。
Cluster（K8s）：生产标准方案。Milvus官方提供Helm Chart，支持：
• 各组件独立扩缩容 • 滚动升级 • 持久化存储（PVC）
云托管：阿里云、京东云、火山引擎均提供Milvus托管服务，兼容开源协议，开箱即用。
4.2 高可用架构：多可用区部署
云厂商的Milvus托管服务支持跨可用区部署，提供机房级容灾能力：
| <3分钟 |
关键设计：
• etcd（元数据）跨3个AZ部署 • Pulsar（消息）跨3个AZ部署 • OSS对象存储为同城冗余模式
DBA建议：金融级场景选多可用区高可用版，一般生产选基础版即可。
5. 运维实战：监控、调优与避坑
5.1 监控体系搭建
Milvus官方推荐的监控栈是Prometheus + Grafana + Alertmanager。
关键指标监控：
QueryNode | ||
官方Grafana Dashboard：Milvus提供开箱即用的Grafana仪表盘，包含40+图表。
5.2 性能调优核心参数
以下参数直接影响生产性能：
1. segment大小（dataCoord.segment.maxSize）
# 默认：1024MB，调大可减少segment数量
dataCoord:
segment:
maxSize: 8192 # 8GB，查询性能提升约4倍
2. HNSW索引参数
# 构建时
M: 32 # 每层最大连接数（默认16，调大提高召回率）
efConstruction: 360 # 构建候选列表（默认64，调大提高质量）
# 查询时
ef: 100 # 搜索候选列表（默认40，调大提高召回率）
3. mmap内存映射
queryNode:
mmap:
enabled: true # 启用mmap，降低内存占用
4. 垃圾回收（GC）
dataCoord:
gc:
dropTolerance: 86400 # 24小时后删除已标记数据
5.3 常见问题与避坑指南
坑1：索引构建导致查询变慢
• 现象：索引构建期间，查询延迟飙升 • 原因：索引未完成时，Query Node回退到暴力搜索 • 解决：错峰建索引，或增加Query Node资源
坑2：segment碎片过多
• 现象：查询性能随数据插入逐渐下降 • 原因：频繁小批量插入产生大量小segment • 解决：批量插入（建议每批>1万条），或手动触发compaction
坑3：etcd性能瓶颈
• 现象：元数据操作（创建Collection等）超时 • 原因：etcd磁盘IOPS不足 • 解决：etcd使用SSD，或单独部署高性能etcd集群
坑4：认证未启用导致数据泄露
• 风险：默认配置无认证，任何人都可访问 • 解决：生产环境必须启用认证并修改默认密码
common:
security:
authorizationEnabled: true # 启用认证
结语：pgvector vs Milvus，如何选择？
"DBA午器"三期连续介绍了pgvector和Milvus，很多读者会问：到底该选哪个？
决策树：
数据量 < 100万？
└─ 是 → pgvector（简单、够用、复用PG生态）
数据量 100万~5000万？
├─ 已深度使用PostgreSQL → pgvector（可接受性能折衷）
└─ 追求极致性能、准备独立运维 → Milvus
数据量 > 5000万？
└─ Milvus（唯一选择）
特殊场景：
├─ 多模态检索（图片+文本+稀疏向量） → Milvus
├─ GPU加速 → Milvus
└─ 云原生、弹性伸缩 → Milvus
Milvus不是pgvector的敌人，而是pgvector的"进阶形态"。
当你的业务从MVP走向规模化，当你的向量数据从百万奔向亿级，当你的查询延迟要求从"可以接受"变成"毫秒级"——Milvus就是那个帮你扛住海量数据、保持高性能的答案。
"DBA午器"温馨提示：Milvus虽强，但运维复杂度不可小觑。建议先用云托管服务（阿里云/京东云）快速验证，确认规模后自建集群。切记：生产环境必开认证、必配监控、必做备份！
参考引用：本文数据与架构解析参考自Milvus官方文档、阿里云/京东云产品文档、Zilliz技术博客及社区实战经验。
