MinIO прекращает принимать изменения сообщества: Оценка RustFS как жизнеспособного S3-совместимого бэкенда объектного хранилища для Milvus

Этот пост написан Минь Инь, одним из самых активных участников сообщества Milvus, и публикуется здесь с разрешения.

MinIO - это высокопроизводительная, совместимая с S3 система хранения объектов с открытым исходным кодом, которая широко используется в AI/ML, аналитике и других рабочих нагрузках, связанных с большими объемами данных. Для многих развертываний Milvus она также была выбором по умолчанию для объектного хранилища. Однако недавно команда MinIO обновила свой GitHub README, сообщив, что этот проект больше не принимает новых изменений.

На самом деле, за последние несколько лет MinIO постепенно переключился на коммерческие предложения, ужесточил модель лицензирования и распространения, а также сократил активную разработку в репозитории сообщества. Переход проекта с открытым исходным кодом в режим сопровождения является естественным результатом этого более широкого перехода.

Для пользователей Milvus, которые по умолчанию полагаются на MinIO, это изменение трудно игнорировать. Объектное хранилище лежит в основе слоя персистентности Milvus, и его надежность со временем зависит не только от того, что работает сегодня, но и от того, продолжает ли система развиваться вместе с рабочими нагрузками, которые она поддерживает.

На этом фоне в данной статье рассматривается RustFS как потенциальная альтернатива. RustFS - это совместимая с S3 объектная система хранения данных на основе Rust, в которой особое внимание уделяется безопасности памяти и современному дизайну систем. Она все еще является экспериментальной, и это обсуждение не является производственной рекомендацией.

Архитектура Milvus и место компонента объектного хранилища

В Milvus 2.6 используется полностью раздельная архитектура хранения и вычислений. В этой модели уровень хранения состоит из трех независимых компонентов, каждый из которых выполняет свою роль.

Etcd хранит метаданные, Pulsar или Kafka обрабатывает потоковые журналы, а объектное хранилище - как правило, MinIO или S3-совместимый сервис - обеспечивает долговременное хранение векторных данных и индексных файлов. Поскольку хранилище и вычисления разделены, Milvus может масштабировать вычислительные узлы независимо друг от друга, полагаясь при этом на общий надежный бэкэнд хранилища.

Роль объектного хранилища в Milvus

Объектное хранилище - это долговременный уровень хранения данных в Milvus. Сырые векторные данные хранятся в виде бинлогов, там же хранятся индексные структуры, такие как HNSW и IVF_FLAT.

Такая конструкция делает вычислительные узлы статичными. Узлы запросов не хранят данные локально; вместо этого они загружают сегменты и индексы из объектного хранилища по требованию. В результате узлы могут свободно увеличиваться или уменьшаться, быстро восстанавливаться после сбоев и поддерживать динамическую балансировку нагрузки в кластере без перебалансировки данных на уровне хранилища.

my-milvus-bucket/
├── files/                          # rootPath (default)
│   ├── insert_log/                 # insert binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}     # Per-field binlog files
│   │
│   ├── delta_log/                  # Delete binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Log_ID}        
│   │
│   ├── stats_log/                  # Statistical data (e.g., Bloom filters)
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}
│   │
│   └── index_files/                # Index files
│       └── {Build_ID}_{Index_Version}_{Segment_ID}_{Field_ID}/
│           ├── index_file_0
│           ├── index_file_1
│           └── ...

Почему Milvus использует API S3

Вместо того чтобы разрабатывать собственный протокол хранения, Milvus использует S3 API в качестве интерфейса объектного хранилища. S3 стал стандартом де-факто для объектных хранилищ: крупнейшие облачные провайдеры, такие как AWS S3, Alibaba Cloud OSS и Tencent Cloud COS, поддерживают его нативно, а системы с открытым исходным кодом, такие как MinIO, Ceph RGW, SeaweedFS и RustFS, полностью совместимы.

Стандартизировав S3 API, Milvus может полагаться на зрелые, хорошо протестированные Go SDK вместо того, чтобы поддерживать отдельные интеграции для каждого бэкенда хранения. Эта абстракция также дает пользователям гибкость в развертывании: MinIO для локальной разработки, облачное хранилище объектов в производстве или Ceph и RustFS для частных сред. Пока доступна конечная точка, совместимая с S3, Milvus не нужно знать - или заботиться - о том, какая система хранения используется под ней.

# Milvus configuration file milvus.yaml
minio:
 address: localhost
 port: 9000
 accessKeyID: minioadmin
 secretAccessKey: minioadmin
 useSSL: false
 bucketName: milvus-bucket

Оценка RustFS в качестве S3-совместимого бэкенда объектного хранилища для Milvus

Обзор проекта

RustFS - это распределенная система хранения объектов, написанная на языке Rust. В настоящее время она находится на стадии альфа-версии (версия 1.0.0-alpha.68) и призвана объединить эксплуатационную простоту MinIO с достоинствами Rust в области безопасности памяти и производительности. Более подробная информация доступна на GitHub.

RustFS все еще находится в стадии активной разработки, и ее распределенный режим еще не был официально выпущен. Поэтому на данном этапе RustFS не рекомендуется использовать для производственных или критически важных рабочих нагрузок.

Архитектурный дизайн

RustFS работает по схеме, концептуально схожей с MinIO. HTTP-сервер предоставляет S3-совместимый API, менеджер объектов обрабатывает метаданные объектов, а движок хранения отвечает за управление блоками данных. На уровне хранения RustFS опирается на стандартные файловые системы, такие как XFS или ext4.

В планируемом распределенном режиме RustFS собирается использовать etcd для координации метаданных, при этом несколько узлов RustFS образуют кластер. Такой дизайн тесно связан с распространенными архитектурами объектных хранилищ, что делает RustFS знакомой пользователям с опытом работы с MinIO.

Совместимость с Milvus

Прежде чем рассматривать RustFS в качестве альтернативного бэкенда объектного хранилища, необходимо оценить, соответствует ли она основным требованиям Milvus к хранилищу.

Требования Milvus	API S3	Поддержка RustFS
Сохранение векторных данных	PutObject, GetObject	✅ Полностью поддерживается
Управление индексными файлами	ListObjects, DeleteObject	✅ Полностью поддерживается
Операции слияния сегментов	Выгрузка нескольких частей	✅ Полностью поддерживается
Гарантии согласованности	Сильное чтение после записи	✅ Сильная согласованность (один узел)

Согласно этой оценке, текущая реализация S3 API в RustFS удовлетворяет базовым функциональным требованиям Milvus. Это делает ее пригодной для практического тестирования в непроизводственных средах.

Практическая работа: замена MinIO на RustFS в Milvus

Цель этого упражнения - заменить стандартную службу хранения объектов MinIO и развернуть Milvus 2.6.7, используя RustFS в качестве бэкенда для хранения объектов.

Необходимые условия

1. Установлены Docker и Docker Compose (версия ≥ 20.10), система может извлекать образы и нормально запускать контейнеры.

2. Доступен локальный каталог для хранения объектных данных, например /volume/data/ (или собственный путь).

3. Порт хоста 9000 открыт для внешнего доступа, либо настроен альтернативный порт.

4. Контейнер RustFS запускается от имени пользователя, не являющегося пользователем root (rustfs). Убедитесь, что каталог данных хоста принадлежит UID 10001.

Шаг 1: Создание каталога данных и установка разрешений

# Create the project directory
mkdir -p milvus-rustfs && cd milvus-rustfs
# Create the data directory
mkdir -p volumes/{rustfs, etcd, milvus}
# Update permissions for the RustFS directory
sudo chown -R 10001:10001 volumes/rustfs

Загрузите официальный файл Docker Compose

wget https://github.com/milvus-io/milvus/releases/download/v2.6.7/milvus-standalone-docker-compose.yml -O docker-compose.yml

Шаг 2: Изменение службы хранения объектов

Определите службу RustFS

Примечание: Убедитесь, что ключ доступа и секретный ключ соответствуют учетным данным, настроенным в службе Milvus.

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
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/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 в настоящее время предполагает настройки по умолчанию в стиле MinIO и пока не позволяет использовать пользовательские значения ключа доступа и секретного ключа. При использовании RustFS в качестве замены, он должен использовать те же учетные данные по умолчанию, которые ожидает Milvus.

version: ‘3.5’
services:
 etcd:
 container_name: milvus-etcd
 image: registry.cn-hangzhou.aliyuncs.com/etcd/etcd: v3.5.25
 environment:
 - ETCD_AUTO_COMPACTION_MODE=revision
 - ETCD_AUTO_COMPACTION_RETENTION=1000
 - ETCD_QUOTA_BACKEND_BYTES=4294967296
 - ETCD_SNAPSHOT_COUNT=50000
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
 command: etcd -advertise-client-urls=http://etcd:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd
 healthcheck:
 test: [“CMD”, “etcdctl”, “endpoint”, “health”]
 interval: 30s
 timeout: 20s
 retries: 3
 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
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3
 standalone:
 container_name: milvus-standalone
 image: registry.cn-hangzhou.aliyuncs.com/milvus/milvus: v2.6.7
 command: [”milvus“, ”run“, ”standalone“]
 security_opt:
 - seccomp: unconfined
 environment:
 MINIO_REGION: us-east-1
 ETCD_ENDPOINTS: etcd:2379
 MINIO_ADDRESS: rustfs:9000
 MINIO_ACCESS_KEY: minioadmin
 MINIO_SECRET_KEY: minioadmin
 MINIO_USE_SSL: ”false“
 MQ_TYPE: rocksmq
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
 healthcheck:
 test: [”CMD“, ”curl“, ”-f“, ”http://localhost:9091/healthz"]
 interval: 30s
 start_period: 90s
 timeout: 20s
 retries: 3
 ports:
 - “19530:19530”
 - “9091:9091”
 depends_on:
 - “etcd”
 - “rustfs”
networks:
 default:
 name: milvus

Запуск служб

docker-compose -f docker-compose.yaml up -d

Проверка состояния служб

docker-compose ps -a

Доступ к веб-интерфейсу RustFS

Откройте веб-интерфейс RustFS в браузере: http://localhost:9001.

Войдите в систему, используя стандартные учетные данные: имя пользователя и пароль - minioadmin.

Протестируйте службу Milvus

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
# connect to Milvus
connections.connect(
 alias="default",
 host='localhost',
 port='19530'
)
print("✓ Successfully connected to Milvus!")
# create test collection
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="test collection")
collection = Collection(name="test_collection", schema=schema)
print("✓ Test collection created!")
print("✓ RustFS verified as the S3 storage backend!")
### Step 3: Storage Performance Testing (Experimental)
Test Design
Two Milvus deployments were set up on identical hardware (16 cores / 32 GB memory / NVMe SSD), using RustFS and MinIO respectively as the object storage backend. The test dataset consisted of 1,000,000 vectors with 768 dimensions, using an HNSW index with parameters M = 16 and efConstruction = 200. Data was inserted in batches of 5,000.
The following metrics were evaluated: Insert throughput, Index build time, Cold and warm load time, Search latency, Storage footprint.
Test Code
Note: Only the core parts of the test code are shown below.

def milvus_load_bench(dim=768, rows=1_000_000, batch=5000): collection = Collection(...) # Insert test t0 = time.perf_counter() for i in range(0, rows, batch): collection.insert([rng.random((batch, dim), dtype=np.float32).tolist()]) insert_time = time.perf_counter() - t0 # Index build collection.flush() collection.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...}) # Нагрузочный тест (холодный старт + два теплых старта) collection.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # Query test search_times = [] for _ in range(3): collection.search(queries, limit=10, ...)

**Test Command**

python bench.py milvus-load-bench --dim 768 --rows 1000000 --batch 5000
-index-type HNSW --repeat-load 3 --release-before-load --do-search --drop-after

**Performance Results**

RustFS

Faster writes (+57%), lower storage usage (–57%), and faster warm loads (+67%), making it suitable for write-heavy, cost-sensitive workloads.
Much slower queries (7.96 ms vs. 1.85 ms, ~+330% latency) with noticeable variance (up to 17.14 ms), and 43% slower index builds. Not suitable for query-intensive applications.

MinIO

Excellent query performance (1.85 ms average latency), mature small-file and random I/O optimizations, and a well-established ecosystem.


Metric
RustFS
MinIO
Difference


Insert Throughput
4,472 rows/s
2,845 rows/s
0.57
Index Build Time
803 s
562 s
-43%
Load (Cold Start)
22.7 s
18.3 s
-24%
Load (Warm Start)
0.009 s
0.027 s
0.67
Search Latency
7.96 ms
1.85 ms
-330%
Storage Usage
7.8 GB
18.0 GB
0.57


RustFS significantly outperforms MinIO in write performance and storage efficiency, with both showing roughly 57% improvement. This demonstrates the system-level advantages of the Rust ecosystem. However, the 330% gap in query latency limits RustFS’s suitability for query-intensive workloads.
For production environments, cloud-managed object storage services like AWS S3 are recommended first, as they are mature, stable, and require no operational effort. Self-hosted solutions are better suited to specific scenarios: RustFS for cost-sensitive or write-intensive workloads, MinIO for query-intensive use cases, and Ceph for data sovereignty. With further optimization in random read performance, RustFS has the potential to become a strong self-hosted option.
Conclusion
      
    
MinIO’s decision to stop accepting new community contributions is disappointing for many developers, but it won’t disrupt Milvus users. Milvus depends on the S3 API—not any specific vendor implementation—so swapping storage backends is straightforward. This S3-compatibility layer is intentional: it ensures Milvus stays flexible, portable, and decoupled from vendor lock-in.
For production deployments, cloud-managed services such as AWS S3 and Alibaba Cloud OSS remain the most reliable options. They’re mature, highly available, and drastically reduce the operational load compared to running your own object storage. Self-hosted systems like MinIO or Ceph still make sense in cost-sensitive environments or where data sovereignty is non-negotiable, but they require significantly more engineering overhead to operate safely at scale.
RustFS is interesting—Apache 2.0-licensed, Rust-based, and community-driven—but it’s still early. The performance gap is noticeable, and the distributed mode hasn’t shipped yet. It’s not production-ready today, but it’s a project worth watching as it matures.
If you’re comparing object storage options for Milvus, evaluating MinIO replacements, or weighing the operational trade-offs of different backends, we’d love to hear from you.
Join our[ Discord channel](https://discord.com/invite/8uyFbECzPX) and share your thoughts. You can also book a 20-minute one-on-one session to get insights, guidance, and answers to your questions through[ Milvus Office Hours](https://milvus.io/blog/join-milvus-office-hours-to-get-support-from-vectordb-experts.md).