Milvus 的架构组成
Milvus 采用存算分离架构：协调组件管理元数据与调度，查询节点执行检索，数据节点负责落盘与压缩，消息队列串联写入链路，对象存储保存段文件。理解这套分工有助于判断性能瓶颈落在哪一层——写入慢、检索慢、还是索引构建慢，对应的扩容对象完全不同。
基本信息
| 协调组件 | root coord、query coord、data coord、index coord |
|---|---|
| 执行组件 | query node（检索）、data node（写入）、index node（建索引） |
| 依赖存储 | etcd 存元数据；MinIO 或 S3 存日志与段；Pulsar 或 Kafka 做日志流 |
| 部署形态 | standalone 单机（开发验证）与 cluster 分布式（生产） |
Docker Compose 启动 standalone
Docker Compose 启动 standalone
wget https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker compose up -d
curl http://localhost:9091/healthz # 健康检查部署要点
- 开发验证用单机形态即可，SDK 代码与分布式一致，后续切换不用改应用
- 生产部署要为对象存储与消息队列单独规划容量，它们常先于计算组件成为瓶颈
- 索引构建会消耗大量内存与 CPU，尽量与在线查询节点在资源上隔离
- 数据落盘有延迟，写入后立刻按条件检索可能查不到，要接受最终一致
- 元数据组件一旦不可用，整个集群无法启动，需要单独做备份
组件与职责
| 层次 | 组件 | 职责 |
|---|---|---|
| 接入 | SDK 与代理层 | 接收读写请求并路由 |
| 协调 | 各类 coord | 元数据、调度与均衡 |
| 计算 | query / data / index node | 检索、写入与索引构建 |
| 存储 | 对象存储与消息队列 | 段文件、日志流与元数据 |
单机与分布式的 SDK 使用方式一致，容量与高可用需求变化时再切换部署形态，应用层代码基本不需要改动。
用默认弱配置的对象存储与消息队列直接上生产，写入高峰期最容易先出问题，建议按写入吞吐预留余量。
容量与扩容判断
- 检索慢且内存吃紧：优先扩查询节点，或改用更省内存的索引类型
- 写入积压：检查消息队列与数据节点，落盘与压缩阶段更易堆积
- 建索引时间长且拖慢查询：把索引节点独立部署，避免共享资源
- 查询量突增时先看对象存储的读写延迟，段文件读取常是被忽略的一环
- 上线前按峰值写入与峰值查询分别压测，两类压力对组件的要求并不相同