★ FEATURED ARTICLE Milvus 跑起来向量、索引和一堆相关对象默认写在它自己的本地卷里。单机验证很顺可一旦向量量上来本地盘的容量、IO 和单点就成了绕不开的墙。更麻烦的是向量库的数据量和查询负载往往不是线性增长一次模型切换就可能让向量规模翻几倍。Milvus 支持把兼容 S3 的对象存储当持久层向量数据和索引直接落进 RustFS 桶Milvus 节点本身只留运行时数据和缓存。把存储下沉到对象存储向量库的扩缩就和数据量解耦了加节点是加节点加容量是加桶。Milvus 把数据往哪写Milvus开源项目把服务元数据放在 etcd把向量数据、索引和对象持久化到对象存储的s3://my-bucket/milvus前缀下。运行时数据、索引缓存这些仍然需要本地 Milvus 卷所以对象存储不是唯一的本地状态但它承接了最占空间、最该持久的那部分。这一层换成 RustFS 之后节点的本地盘只管缓存和临时状态真正的向量都在桶里节点挂了换一台数据从桶拉回即可。官方指南用 Milvus v2.6.0配合 etcd v3.5.18、attu v2.6.5、pymilvus 2.6.0验证通过。下面重点放在配置和验证不重复从零装。etcd 那部分元数据量很小还是留在本地卷或独立 etcd 集群对象存储只接向量和索引这一大头。落到桶里的具体是 Milvus 的段文件segment和索引文件查询时按需要把段从对象存储读回本地缓存再算。这意味着冷查询第一次会多一层对象存储读取延迟但缓存命中后和本地盘差异不大而换来的是存储容量不再受单机盘限制。对象在桶里按milvus/下的子前缀组织插入、索引、段各有自己的目录排查时翻控制台能看到这些对象随集合的增删而增长也能据此判断某次写入是否真的落了地。代价是对象存储的读取延迟比本地 NVMe 高对延迟极度敏感的在线检索本地盘加内存缓存可能更合适对象存储更适合数据量大、冷热分明的场景把成本摊薄。一个 minio 配置键实际指向 RustFSMilvus 把兼容 S3 的存储设置归在minio这个配置键下面。名字虽然叫 minio但并不要求后端真的是 MinIO这里minio.address指向的就是 RustFS 服务。关键就是把common.storageType切成remote再填一组minio.*common:storageType:remoteminio:address:rustfs:9000port:9000bucketName:my-bucketrootPath:milvususeSSL:falseuseIAM:falsecloudProvider:awsregion:us-east-1useVirtualHost:falseuseVirtualHost: false这一行决定走路径风格path-style请求对 RustFS 是必须的因为 RustFS 不走虚拟主机风格的桶寻址。useIAM: false表示用静态密钥而不是实例角色配合cloudProvider: aws走标准的 S3 签名。主机名rustfs在 compose 网络内部解析主机上的客户端用http://localhost:9000。同样的凭证也会通过环境变量交给 MilvusMINIO_ADDRESSrustfs:9000、MINIO_ACCESS_KEY_ID、MINIO_SECRET_ACCESS_KEY、MINIO_REGIONus-east-1外加ETCD_ENDPOINTSetcd:2379指向元数据服务。这套配置对分布式 Milvus 同样适用区别只是 standalone 换成多个 coordinator 和 worker 节点它们共享同一个minio配置指向 RustFS。无论哪种形态给 Milvus 用的凭证都应该走专用的 IAM 子账号只对这个桶有读写权不要把管理员密钥塞进 compose 的环境变量密钥泄漏的波及面要压到最小。用 compose 把整栈拉起来官方 demo 把 RustFS、etcd、Milvus standalone 和 Attu 塞进同一个 compose还用一个create-bucket服务专门建my-bucket。桶必须存在Milvus 自己不建。RustFS 服务镜像官方指南钉的是较早的rustfs/rustfs:1.0.0-alpha.83生产环境建议换成当前稳定版rustfs/rustfs:1.0.42026-10-25稳定版覆盖这些 S3 操作且经过充分验证。dockercompose up-ddockercomposeps-acreate-bucket应以退出码 0 结束etcd、rustfs、standalone进入健康状态。RustFS 控制台在http://localhost:9001Attu 在http://localhost:8000Milvus 健康端点是http://localhost:9091/healthz。Attu 通过 compose 网络连standalone:19530浏览器端则用localhost:19530。插几条向量确认它们落进桶里装一个和服务器同版本的客户端插几条四维向量再搜一下frompymilvusimportMilvusClient clientMilvusClient(urihttp://localhost:19530)ifclient.has_collection(collection_namerustfs_demo):client.drop_collection(collection_namerustfs_demo)client.create_collection(collection_namerustfs_demo,dimension4)client.insert(collection_namerustfs_demo,data[{id:1,vector:[0.1,0.2,0.3,0.4]},{id:2,vector:[0.2,0.3,0.4,0.5]},{id:3,vector:[0.9,0.8,0.7,0.6]},])client.flush(collection_namerustfs_demo)插完刷完用存储桶初始化镜像列一下milvus根路径下的对象应该能看到 Milvus 在milvus/前缀下创建的对象dockercompose run--rm--entrypoint/bin/sh create-bucket-c\/usr/bin/rc alias set rustfs http://rustfs:9000 $RUSTFS_ACCESS_KEY $RUSTFS_SECRET_KEY \ --region us-east-1 --bucket-lookup path /dev/null /usr/bin/rc find rustfs/my-bucket/milvus插入、刷新、查询成功加上 RustFS 对象列表里出现milvus/前缀的内容这三件事合起来才算验证通了整条链路。Milvus 可能先缓冲或压缩再落盘所以插完立刻查不到对象是正常的给一点时间让它刷出去。RustFS 当前稳定版是 1.0.42026-10-25覆盖 Milvus 需要的这些 S3 操作。官方 GA 基准里 4KiB 小对象 PUT 大约能到 MinIO 的 2.3 倍向量和索引多为中等大小的对象吞吐稳定即可这一层 RustFS 不拖后腿。控制台在/rustfs/console/路径下进去能直接翻milvus/前缀确认对象到位。几个别动的生产红线端点用服务名compose 内部必须写rustfs:9000写localhost:9000指向的是 Milvus 容器自己连不上 RustFSuseVirtualHost 保持 false改回虚拟主机风格RustFS 的路径风格请求就废了已有部署别动根路径minio.bucketName、minio.rootPath和 etcd 根路径一旦改动旧数据对不上恢复不了本地卷仍要备份运行时数据和缓存还在 Milvus 本地卷对象存储只是持久层的一部分整机备份别只盯桶官方指南是本地集成测试文档声明不适用于生产环境生产里要补上专用凭证、TLS、鉴权和资源规划。接好之后Milvus 的向量全在 RustFS 桶里扩节点、换机器都不用搬数据存储容量跟着桶走而不是跟着机器走。对于已经在用 RustFS 承接着日志、备份、镜像这类负载的团队顺手把向量库也接进来存储底座统一运维心智和成本模型都跟着统一不必为向量单独养一套分布式文件系统。官方把 Milvus 接进 RustFS 的完整步骤在 Milvus 集成指南 里包含 compose、插入验证与故障排查的示例。生产凭证的创建方式看 访问密钥管理S3 兼容性细节看 S3 协议说明。
阅读完成 · 觉得有帮助？
