[Rust] Milvus对象存储方案实战：MinIO替代选择与RustFS性能评测

前不久，被誉为开源对象存储“瑞士军刀”的MinIO，在其GitHub仓库的README中更新了一段声明：

This project is currently under maintenance and is not accepting new changes.

这意味着项目将不再开发新功能，仅进行维护。对于大量依赖MinIO作为默认对象存储的Milvus向量数据库用户而言，评估可行的替代方案变得必要。本文将深入探讨使用实验性的RustFS作为MinIO替代方案的技术可行性与实战表现。

重要提示：RustFS目前仍处于Alpha实验阶段，本文内容旨在进行技术探索与验证，不推荐直接用于生产环境。

一、Milvus架构解析：对象存储的核心角色

1.1 存储计算分离架构

Milvus 2.6+ 版本完全采用了存储计算分离的云原生架构。其存储层由三个独立组件构成：etcd负责元数据存储，消息队列（Pulsar/Kafka）处理流式日志，而对象存储（如MinIO或兼容S3的服务）则用于持久化向量原始数据、索引文件等。

1.2 对象存储的三大职责

在Milvus中，对象存储是唯一的持久化存储介质，承担着核心职责：

1. 数据持久化：向量插入日志（binlog）、删除日志以及HNSW、IVF_FLAT等各种索引文件均存储于此。
2. 支撑计算无状态化：Query Node等计算节点可以随时扩缩容，因为它们不持久化数据，仅按需从对象存储加载所需数据段，实现了弹性伸缩与快速故障恢复。
3. 标准化接口：通过采用行业事实标准S3 API，Milvus得以与众多云服务商（AWS S3、阿里云OSS）和开源实现（MinIO、Ceph）无缝集成。

典型的Milvus对象存储桶目录结构如下：

my-milvus-bucket/
├── files/                          # 根路径
│   ├── insert_log/                 # 插入数据 binlog
│   ├── delta_log/                  # 删除数据 binlog
│   ├── stats_log/                  # 统计信息
│   └── index_files/                # 索引文件

1.3 为什么是S3协议？

Milvus选择S3 API而非自定义协议，关键在于其广泛的生态兼容性。只要后端存储服务提供兼容S3的访问端点（endpoint），Milvus即可无缝对接。这赋予了用户在部署环境上极大的灵活性：开发测试可使用本地MinIO，生产环境可切换至云厂商对象存储，私有化部署则可选择Ceph或本文探讨的RustFS。

配置示例 (milvus.yaml)：

minio:
  address: localhost
  port: 9000
  accessKeyID: minioadmin
  secretAccessKey: minioadmin
  useSSL: false
  bucketName: milvus-bucket

二、RustFS：一个实验性的替代选择

2.1 项目概览

项目地址：https://github.com/rustfs/rustfs

RustFS是一个使用Rust语言编写的分布式对象存储系统，当前版本为1.0.0.alpha.68（Alpha阶段）。它旨在融合MinIO的简洁设计理念与Rust语言带来的内存安全和高性能潜力。

再次强调：该项目处于快速迭代期，分布式模式尚未稳定发布，请勿用于核心生产业务。

2.2 架构简析

RustFS架构与MinIO类似：通过HTTP服务器提供S3兼容接口，由对象管理器处理元数据，存储引擎操作数据块，并依赖底层文件系统（如XFS/ext4）。其规划中的分布式模式将使用etcd进行协调。

2.3 兼容性分析

为确认RustFS能否替代MinIO，需验证其是否满足Milvus的核心操作需求：

Milvus 需求	依赖的S3 API	RustFS 支持情况
向量数据存储	PutObject/GetObject	✅ 完全支持
索引文件管理	ListObjects/DeleteObject	✅ 完全支持
分段合并	Multipart Upload	✅ 完全支持
一致性要求	强一致性读写	✅ 单节点强一致

分析表明，RustFS的S3 API实现能满足Milvus的基本需求，具备进行替换测试的条件。

三、实战：使用RustFS部署Milvus

本实战目标是在Milvus 2.6.7版本中，使用RustFS替换默认的MinIO服务。

环境准备：

• Docker & Docker-Compose (版本 ≥ 20.10)
• 用于数据挂载的本地目录 (如 /volume/data/)
• 主机端口9000可用（或自定义其他端口）
• 注意：RustFS容器默认以UID 10001 运行，需相应调整主机目录权限。

3.1 准备目录与配置

# 创建项目目录
mkdir -p milvus-rustfs && cd milvus-rustfs
# 创建数据卷目录
mkdir -p volumes/{rustfs, etcd, milvus}
# 调整RustFS数据目录权限
sudo chown -R 10001:10001 volumes/rustfs

# 下载Milvus官方docker-compose文件
wget https://github.com/milvus-io/milvus/releases/download/v2.6.7/milvus-standalone-docker-compose.yml -O docker-compose.yml

3.2 修改Docker Compose配置

编辑 docker-compose.yml，主要改动为用rustfs服务替换原有的minio服务，并调整Milvus配置指向RustFS。

关键部分 (rustfs 服务定义)：

rustfs:
  container_name: milvus-rustfs
  image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs:latest
  environment:
    RUSTFS_ACCESS_KEY: minioadmin
    RUSTFS_SECRET_KEY: minioadmin
    RUSTFS_CONSOLE_ENABLE: "true"
    RUSTFS_REGION: us-east-1
  ports:
    - "9001:9001"  # 控制台端口
    - "9000:9000"  # S3 API端口
  volumes:
    - ./volumes/rustfs:/data
  command: > 
    --address :9000
    --console-enable
    /data
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:9000/health"]
    interval: 30s
    timeout: 20s
    retries: 3

Milvus服务配置需相应调整环境变量：

environment:
  MINIO_ADDRESS: rustfs:9000  # 关键：将端点指向rustfs服务
  MINIO_ACCESS_KEY: minioadmin
  MINIO_SECRET_KEY: minioadmin
  MINIO_USE_SSL: "false"
  # ... 其他配置不变

3.3 启动与验证

# 启动所有服务
docker-compose up -d

# 查看服务状态
docker-compose ps -a

访问RustFS控制台 (http://localhost:9001)，使用账号minioadmin/密码minioadmin登录，可查看存储桶状态。

3.4 功能测试

使用Python客户端连接Milvus并进行基本操作，验证集成是否正常。

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType

# 连接Milvus
connections.connect(alias="default", host='localhost', port='19530')
print("✓ 成功连接到Milvus!")

# 创建测试集合
fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=128)
]
schema = CollectionSchema(fields=fields, description="测试集合")
collection = Collection(name="test_collection", schema=schema)
print("✓ 集合创建成功，RustFS作为底层存储工作正常！")

四、性能对比测试（实验性参考）

在相同硬件环境（16核/32GB内存/NVMe SSD）下，分别部署以RustFS和MinIO为存储后端的Milvus，对100万条768维向量数据进行插入、索引构建、加载与查询测试。

4.1 测试结果摘要

测试指标	RustFS	MinIO	对比分析
数据插入吞吐	更快 (+57%)	基准	RustFS写入优势明显
索引构建时间	较慢 (+43%)	更快	MinIO在小文件处理上更成熟
存储空间占用	更省 (-57%)	基准	RustFS存储效率更高
集合热启动时间	更快 (-67%)	基准	RustFS缓存或加载机制可能更优
查询平均延迟	7.96 ms	1.85 ms	MinIO查询性能显著领先

4.2 性能结论

• RustFS优势场景：在数据写入速度和存储空间效率上表现突出（均提升/节省约57%），在成本敏感或写入密集型场景中具有潜力。
• RustFS明显短板：查询延迟远高于MinIO（差距达330%），且存在波动，索引构建也较慢。这使其在当前阶段不适合查询密集型的生产应用。
• MinIO优势：在随机读取（查询）优化上非常成熟，查询性能稳定且极致，生态工具链完善。

五、总结与选型建议

Milvus基于S3 API的存储抽象，赋予了用户切换后端存储的灵活性。针对MinIO的现状，选型建议如下：

1. 生产环境优先：首选云厂商对象存储服务（如AWS S3、阿里云OSS）。它们提供高可用、高持久性和免运维的优势，是生产系统的稳妥选择。
2. 自建方案考量：
   • 成本敏感/写入为主：可关注RustFS的未来发展，待其查询性能优化和分布式模式稳定后，可能是一个高性能自建选项。
   • 查询密集型/生态完善：MinIO仍是成熟可靠的自建选择，尽管处于维护模式，但其稳定性和性能经过长期验证。
   • 数据主权/复杂需求：Ceph (RGW) 等企业级开源方案值得考虑，但运维复杂度较高。

RustFS作为新兴项目，凭借Apache 2.0许可证和Rust语言的现代特性展现潜力，但其Alpha状态、查询性能短板及未发布的分布式功能，决定了它目前仅适用于技术预览和非核心场景的探索，切勿贸然用于生产。