Milvus 数据分片、扩展与高并发设计码海寻道 · 大模型、智能体与 RAG 工程组件系列第 19 篇当 Milvus 从单机开发环境进入生产环境问题会从“能不能检索”变成“高峰期能不能稳定检索”。这时需要理解三个概念数据如何分布、组件如何扩展、查询资源如何隔离。而在讨论扩展之前必须先区分三种部署形态形态适合场景组件特征主要限制Milvus LitePython 本地实验、单元测试、小型 Demo以库或轻量方式运行依赖少不适合作为多服务生产集群Standalone本地开发、测试环境、中小规模单机服务Milvus 主要服务集中在单机通常配合 etcd 与 MinIO计算资源和故障域集中不能按角色独立扩展Distributed生产集群、较高并发、需要独立扩容Proxy、Coordinator、Query/Data/Index Node 等角色可拆分扩展部署、监控、备份和升级复杂度更高Standalone 不是“没有 etcd 和 MinIO”。在常见 Docker Compose 方案中仍会有milvus-etcd、milvus-minio和milvus-standalone三类服务只是 Milvus 的多个计算角色被集中在一个实例中。某些嵌入式安装方式会把 etcd 放进同一容器不能据此推断生产环境也应该把所有依赖揉在一个容器里。一、先区分三种“分开”1. Partition逻辑分组Partition 是 Collection 内部的数据组织方式查询时可以只搜索指定分区。它主要解决逻辑范围和查询裁剪问题。2. Shard写入流分片Shard 用于把写入流分散到不同通道和处理节点帮助提升数据写入和流式处理能力。它不是“按租户建分区”的同义词。3. Query Node 扩展搜索计算扩容增加 Query Node 是把查询计算能力横向扩展。它解决的是并发和查询资源问题不会自动替代数据建模、索引和过滤设计。Partition按什么逻辑范围搜索 Shard写入流如何分散 Query Node搜索计算如何扩展二、Standalone、etcd、MinIO 和 Distributed 如何配合1. Standalone把 Milvus 主要服务集中运行Standalone 的优点是启动和调试简单。应用通过19530连接 Milvus管理页面通常通过9091访问etcd 和 MinIO 主要供 Milvus 内部使用。它适合让开发者快速验证 Collection、索引、插入和检索代码。它的边界也很清楚查询、导入、索引构建和故障域都集中在一台机器上。即使底层 MinIO 使用了持久化卷Standalone 也不等于查询服务高可用。2. etcd小而关键的元数据服务etcd 保存 Milvus 运行所需的关键元数据并参与服务注册和健康检查。它保存的是“数据在哪里、集合是什么结构、哪些服务存在”等控制信息而不是每个 Chunk 的完整文本和向量。etcd 对磁盘延迟和稳定性比较敏感。生产部署中应使用可靠的 SSD、持久化数据卷和备份方案不要把 etcd 当作可以随意清空的缓存。etcd 不健康时Milvus 可能无法正确读取集合、索引或节点状态即使 MinIO 中的数据文件仍然存在。3. MinIO / S3持久化对象存储Milvus 使用对象存储保存数据文件、索引文件以及部分持久化对象。MinIO 是常见的自建 S3 兼容方案云上也可以使用 S3、OSS、COS、OBS 等兼容对象存储。对象存储的优势是容量可扩展、计算与存储解耦代价是网络访问延迟、权限配置、生命周期管理和备份恢复都需要单独设计。Milvus 的 MinIO Bucket 不建议和业务原始文件共用无隔离的目录至少要区分 Bucket、账号、前缀和备份策略。4. WAL 与消息队列让写入可以恢复和传播Milvus 的写入通常不会直接等同于“把一行数据写进某个查询节点”。变更需要先进入可靠的日志或消息流再由数据服务消费、持久化并让查询侧逐步可见。这个角色通常被称为 WALWrite-Ahead Log或消息队列常见实现包括 Woodpecker、Kafka、Pulsar以及特定版本中的 RocksMQ。在官方 Standalone 方案中消息能力可能采用嵌入式实现不一定出现一个单独的消息队列容器在 Distributed 部署中则需要根据版本和吞吐目标评估外部消息系统。它解决的是“写入事件如何可靠传播和恢复”不是向量相似度索引也不是 RAG 应用自己的 RabbitMQ 任务队列。客户端写入 ↓ WAL / 消息流记录可恢复的变更 ↓ Data Node消费并持久化 ↓ 对象存储保存数据文件 ↓ Query Node加载后提供检索因此遇到“写入成功但查询暂时不可见”时除了检查 etcd 和 MinIO还要检查 WAL/消息链路的积压、消费错误和可见性延迟。5. Distributed按角色扩展 Milvus在 Distributed 部署中可以根据瓶颈增加 Query Node、Data Node 或 Index Node并由 Proxy 和 Coordinator 负责请求路由、任务调度及状态协调。外部 etcd、对象存储和消息系统也需要按高可用方式部署。客户端 ↓ Proxy ├── Query Coord → Query Nodes → MinIO/S3 中的数据与索引 ├── Data Coord → Data Nodes → WAL/对象存储 └── Index Coord → Index Nodes → MinIO/S3 中的索引文件 ↑ etcd元数据、服务注册、健康状态不同 Milvus 版本的组件名和消息队列实现可能变化架构图用于理解职责不应当当作固定的容器清单。三、Milvus 为什么可以水平扩展Milvus 的架构强调计算与存储分离。对象存储保存持久化数据和索引文件计算节点负责数据处理、索引构建或查询执行。简化理解如下客户端 ↓ Proxy / Access Layer ↓ Coordinator ├── Query Nodes搜索与查询 ├── Data Nodes数据写入与持久化流 └── Index Nodes索引构建 ↓ 对象存储 元数据存储不同版本和部署模式的组件细节可能不同但工程原则是一致的根据实际瓶颈扩展对应角色而不是盲目增加所有节点。四、什么时候需要扩展可以从以下信号判断P95/P99 查询延迟持续升高Query Node CPU 或内存长期接近上限查询并发增加后出现排队索引构建影响在线搜索数据写入速度跟不上知识库导入速度服务需要跨节点容错和高可用。不要只根据向量数量扩容。相同数量的向量在不同维度、索引、过滤条件和查询并发下资源需求可能完全不同。五、读写负载应该分开看RAG 系统通常有两类负载在线检索用户提问需要低延迟返回关注 P95、P99、并发和查询节点资源。离线建库批量解析、Embedding、插入和索引构建关注吞吐、队列积压和任务失败率。如果离线导入和在线检索共用资源可能出现“批量建库时线上变慢”。应通过任务调度、资源隔离、错峰构建或独立节点降低互相影响。六、租户隔离如何设计多租户知识库有三种常见方式方案 A同一 Collection tenant_id 过滤优点是结构简单、租户数量扩展容易缺点是每次搜索都必须带上安全过滤条件。方案 B有限数量的 Partition适合少量稳定的数据域例如公开知识、内部知识和归档知识。不要为数万租户创建数万 Partition。方案 C不同租户使用不同 Collection隔离强但集合管理、索引构建、资源利用和运维成本更高适合少量重要租户或强隔离场景。权限设计必须由业务服务、数据库权限和检索过滤共同完成。Milvus 的数据组织方式不能单独承担全部授权责任。七、高并发检索的关键参数1. 控制 Top K 和候选范围Top K 过大、IVF 的 nprobe 过高、HNSW 的 ef 过大都会增加查询成本。先确定答案所需的最小上下文再反推召回范围。2. 避免重复查询相同问题、相同租户和相同知识库版本可以在 Redis 中做短时缓存。缓存命中时不必重复执行 Embedding 和 Milvus 搜索。3. 控制批量导入把大批量写入拆成可观测、可重试的批次记录批次 ID、向量模型版本和写入结果避免单个超大请求阻塞服务。4. 保护服务边界在 API 层设置并发限制、超时和取消机制。不要让客户端直接无限制调用 Milvus也不要把 Milvus 的内部错误原样返回给用户。八、扩展前必须建立的指标请求层QPS、错误率、P50/P95/P99 检索层Top K、过滤命中率、空结果率 资源层CPU、内存、磁盘、网络 数据层写入吞吐、任务积压、索引构建时长 业务层RecallK、答案引用正确率、用户反馈如果只有 CPU 和内存没有 RecallK 与答案质量就无法判断扩容是否真的解决了用户问题。九、一个生产化的流量分层示意用户请求 ↓ API Gateway鉴权、限流、超时 ↓ RAG 服务问题改写、Embedding、过滤条件 ↓ Redis热点查询缓存 ↓ Milvus向量检索 ↓ Reranker精排 ↓ 大模型生成答案文档导入走另一条链路上传文件 → 对象存储 → 消息队列 → 解析/切分/Embedding → 批量写入 Milvus在线检索和离线建库分开后系统更容易分别扩容和排障。十、不要过早上 KubernetesMilvus Distributed 和 Kubernetes 适合对弹性、可用性和规模有明确要求的团队但它们也带来更高的部署和运维复杂度。如果项目还在验证阶段可以先使用 Milvus Lite 或 Standalone等数据规模、并发和可用性目标明确后再升级部署形态。架构升级应由指标驱动而不是由“生产环境必须上集群”的想象驱动。十一、扩容与缩容的注意事项一次只调整一个变量避免无法判断收益扩容前记录基线扩容后比较同一批流量缩容要观察服务可用性和数据副本状态索引、对象存储和元数据备份不能省略高可用不等于没有数据同步和恢复演练。结语Milvus 的高并发设计不是简单地“多启动几个节点”。它需要把 Partition、Shard、Query Node、在线检索、离线建库、租户隔离和指标体系放在一起考虑。下一篇将集中处理实际开发中最常见的问题检索不到、向量维度错误、刚写入数据不可见以及数据一致性如何判断。参考资料Milvus 官方文档Architecture OverviewMilvus 官方文档Scale a Milvus ClusterMilvus 官方文档Run Milvus with Docker ComposeMilvus 官方文档Milvus Architecture本文为“码海寻道”原创技术文章。集群组件、扩展方式和部署建议会随 Milvus 版本变化生产部署请结合目标版本验证。 19.Milvus数据分片扩展与高并发设计
Milvus 数据分片、扩展与高并发设计码海寻道 · 大模型、智能体与 RAG 工程组件系列第 19 篇当 Milvus 从单机开发环境进入生产环境问题会从“能不能检索”变成“高峰期能不能稳定检索”。这时需要理解三个概念数据如何分布、组件如何扩展、查询资源如何隔离。而在讨论扩展之前必须先区分三种部署形态形态适合场景组件特征主要限制Milvus LitePython 本地实验、单元测试、小型 Demo以库或轻量方式运行依赖少不适合作为多服务生产集群Standalone本地开发、测试环境、中小规模单机服务Milvus 主要服务集中在单机通常配合 etcd 与 MinIO计算资源和故障域集中不能按角色独立扩展Distributed生产集群、较高并发、需要独立扩容Proxy、Coordinator、Query/Data/Index Node 等角色可拆分扩展部署、监控、备份和升级复杂度更高Standalone 不是“没有 etcd 和 MinIO”。在常见 Docker Compose 方案中仍会有milvus-etcd、milvus-minio和milvus-standalone三类服务只是 Milvus 的多个计算角色被集中在一个实例中。某些嵌入式安装方式会把 etcd 放进同一容器不能据此推断生产环境也应该把所有依赖揉在一个容器里。一、先区分三种“分开”1. Partition逻辑分组Partition 是 Collection 内部的数据组织方式查询时可以只搜索指定分区。它主要解决逻辑范围和查询裁剪问题。2. Shard写入流分片Shard 用于把写入流分散到不同通道和处理节点帮助提升数据写入和流式处理能力。它不是“按租户建分区”的同义词。3. Query Node 扩展搜索计算扩容增加 Query Node 是把查询计算能力横向扩展。它解决的是并发和查询资源问题不会自动替代数据建模、索引和过滤设计。Partition按什么逻辑范围搜索 Shard写入流如何分散 Query Node搜索计算如何扩展二、Standalone、etcd、MinIO 和 Distributed 如何配合1. Standalone把 Milvus 主要服务集中运行Standalone 的优点是启动和调试简单。应用通过19530连接 Milvus管理页面通常通过9091访问etcd 和 MinIO 主要供 Milvus 内部使用。它适合让开发者快速验证 Collection、索引、插入和检索代码。它的边界也很清楚查询、导入、索引构建和故障域都集中在一台机器上。即使底层 MinIO 使用了持久化卷Standalone 也不等于查询服务高可用。2. etcd小而关键的元数据服务etcd 保存 Milvus 运行所需的关键元数据并参与服务注册和健康检查。它保存的是“数据在哪里、集合是什么结构、哪些服务存在”等控制信息而不是每个 Chunk 的完整文本和向量。etcd 对磁盘延迟和稳定性比较敏感。生产部署中应使用可靠的 SSD、持久化数据卷和备份方案不要把 etcd 当作可以随意清空的缓存。etcd 不健康时Milvus 可能无法正确读取集合、索引或节点状态即使 MinIO 中的数据文件仍然存在。3. MinIO / S3持久化对象存储Milvus 使用对象存储保存数据文件、索引文件以及部分持久化对象。MinIO 是常见的自建 S3 兼容方案云上也可以使用 S3、OSS、COS、OBS 等兼容对象存储。对象存储的优势是容量可扩展、计算与存储解耦代价是网络访问延迟、权限配置、生命周期管理和备份恢复都需要单独设计。Milvus 的 MinIO Bucket 不建议和业务原始文件共用无隔离的目录至少要区分 Bucket、账号、前缀和备份策略。4. WAL 与消息队列让写入可以恢复和传播Milvus 的写入通常不会直接等同于“把一行数据写进某个查询节点”。变更需要先进入可靠的日志或消息流再由数据服务消费、持久化并让查询侧逐步可见。这个角色通常被称为 WALWrite-Ahead Log或消息队列常见实现包括 Woodpecker、Kafka、Pulsar以及特定版本中的 RocksMQ。在官方 Standalone 方案中消息能力可能采用嵌入式实现不一定出现一个单独的消息队列容器在 Distributed 部署中则需要根据版本和吞吐目标评估外部消息系统。它解决的是“写入事件如何可靠传播和恢复”不是向量相似度索引也不是 RAG 应用自己的 RabbitMQ 任务队列。客户端写入 ↓ WAL / 消息流记录可恢复的变更 ↓ Data Node消费并持久化 ↓ 对象存储保存数据文件 ↓ Query Node加载后提供检索因此遇到“写入成功但查询暂时不可见”时除了检查 etcd 和 MinIO还要检查 WAL/消息链路的积压、消费错误和可见性延迟。5. Distributed按角色扩展 Milvus在 Distributed 部署中可以根据瓶颈增加 Query Node、Data Node 或 Index Node并由 Proxy 和 Coordinator 负责请求路由、任务调度及状态协调。外部 etcd、对象存储和消息系统也需要按高可用方式部署。客户端 ↓ Proxy ├── Query Coord → Query Nodes → MinIO/S3 中的数据与索引 ├── Data Coord → Data Nodes → WAL/对象存储 └── Index Coord → Index Nodes → MinIO/S3 中的索引文件 ↑ etcd元数据、服务注册、健康状态不同 Milvus 版本的组件名和消息队列实现可能变化架构图用于理解职责不应当当作固定的容器清单。三、Milvus 为什么可以水平扩展Milvus 的架构强调计算与存储分离。对象存储保存持久化数据和索引文件计算节点负责数据处理、索引构建或查询执行。简化理解如下客户端 ↓ Proxy / Access Layer ↓ Coordinator ├── Query Nodes搜索与查询 ├── Data Nodes数据写入与持久化流 └── Index Nodes索引构建 ↓ 对象存储 元数据存储不同版本和部署模式的组件细节可能不同但工程原则是一致的根据实际瓶颈扩展对应角色而不是盲目增加所有节点。四、什么时候需要扩展可以从以下信号判断P95/P99 查询延迟持续升高Query Node CPU 或内存长期接近上限查询并发增加后出现排队索引构建影响在线搜索数据写入速度跟不上知识库导入速度服务需要跨节点容错和高可用。不要只根据向量数量扩容。相同数量的向量在不同维度、索引、过滤条件和查询并发下资源需求可能完全不同。五、读写负载应该分开看RAG 系统通常有两类负载在线检索用户提问需要低延迟返回关注 P95、P99、并发和查询节点资源。离线建库批量解析、Embedding、插入和索引构建关注吞吐、队列积压和任务失败率。如果离线导入和在线检索共用资源可能出现“批量建库时线上变慢”。应通过任务调度、资源隔离、错峰构建或独立节点降低互相影响。六、租户隔离如何设计多租户知识库有三种常见方式方案 A同一 Collection tenant_id 过滤优点是结构简单、租户数量扩展容易缺点是每次搜索都必须带上安全过滤条件。方案 B有限数量的 Partition适合少量稳定的数据域例如公开知识、内部知识和归档知识。不要为数万租户创建数万 Partition。方案 C不同租户使用不同 Collection隔离强但集合管理、索引构建、资源利用和运维成本更高适合少量重要租户或强隔离场景。权限设计必须由业务服务、数据库权限和检索过滤共同完成。Milvus 的数据组织方式不能单独承担全部授权责任。七、高并发检索的关键参数1. 控制 Top K 和候选范围Top K 过大、IVF 的 nprobe 过高、HNSW 的 ef 过大都会增加查询成本。先确定答案所需的最小上下文再反推召回范围。2. 避免重复查询相同问题、相同租户和相同知识库版本可以在 Redis 中做短时缓存。缓存命中时不必重复执行 Embedding 和 Milvus 搜索。3. 控制批量导入把大批量写入拆成可观测、可重试的批次记录批次 ID、向量模型版本和写入结果避免单个超大请求阻塞服务。4. 保护服务边界在 API 层设置并发限制、超时和取消机制。不要让客户端直接无限制调用 Milvus也不要把 Milvus 的内部错误原样返回给用户。八、扩展前必须建立的指标请求层QPS、错误率、P50/P95/P99 检索层Top K、过滤命中率、空结果率 资源层CPU、内存、磁盘、网络 数据层写入吞吐、任务积压、索引构建时长 业务层RecallK、答案引用正确率、用户反馈如果只有 CPU 和内存没有 RecallK 与答案质量就无法判断扩容是否真的解决了用户问题。九、一个生产化的流量分层示意用户请求 ↓ API Gateway鉴权、限流、超时 ↓ RAG 服务问题改写、Embedding、过滤条件 ↓ Redis热点查询缓存 ↓ Milvus向量检索 ↓ Reranker精排 ↓ 大模型生成答案文档导入走另一条链路上传文件 → 对象存储 → 消息队列 → 解析/切分/Embedding → 批量写入 Milvus在线检索和离线建库分开后系统更容易分别扩容和排障。十、不要过早上 KubernetesMilvus Distributed 和 Kubernetes 适合对弹性、可用性和规模有明确要求的团队但它们也带来更高的部署和运维复杂度。如果项目还在验证阶段可以先使用 Milvus Lite 或 Standalone等数据规模、并发和可用性目标明确后再升级部署形态。架构升级应由指标驱动而不是由“生产环境必须上集群”的想象驱动。十一、扩容与缩容的注意事项一次只调整一个变量避免无法判断收益扩容前记录基线扩容后比较同一批流量缩容要观察服务可用性和数据副本状态索引、对象存储和元数据备份不能省略高可用不等于没有数据同步和恢复演练。结语Milvus 的高并发设计不是简单地“多启动几个节点”。它需要把 Partition、Shard、Query Node、在线检索、离线建库、租户隔离和指标体系放在一起考虑。下一篇将集中处理实际开发中最常见的问题检索不到、向量维度错误、刚写入数据不可见以及数据一致性如何判断。参考资料Milvus 官方文档Architecture OverviewMilvus 官方文档Scale a Milvus ClusterMilvus 官方文档Run Milvus with Docker ComposeMilvus 官方文档Milvus Architecture本文为“码海寻道”原创技术文章。集群组件、扩展方式和部署建议会随 Milvus 版本变化生产部署请结合目标版本验证。