توقف MinIO عن قبول تغييرات المجتمع: تقييم RustFS كواجهة خلفية لتخزين الكائنات متوافقة مع S3 قابلة للتطبيق في ميلفوس

هذا المنشور بقلم مين يين، أحد أكثر المساهمين النشطين في مجتمع ميلفوس، ويتم نشره هنا بإذن.

MinIO هو نظام تخزين كائنات مفتوح المصدر وعالي الأداء ومتوافق مع S3 يستخدم على نطاق واسع في الذكاء الاصطناعي/التعلم الآلي والتحليلات وأعباء العمل الأخرى كثيفة البيانات. بالنسبة للعديد من عمليات نشر Milvus، كان أيضًا الخيار الافتراضي لتخزين الكائنات. ومع ذلك، قام فريق MinIO مؤخرًا بتحديث GitHub README الخاص به ليشير إلى أن هذا المشروع لم يعد يقبل تغييرات جديدة.

في الواقع، على مدى السنوات القليلة الماضية، حولت MinIO اهتمامها تدريجيًا نحو العروض التجارية، وشددت نموذج الترخيص والتوزيع الخاص بها، وقلصت التطوير النشط في مستودع المجتمع. إن نقل المشروع مفتوح المصدر إلى وضع الصيانة هو النتيجة الطبيعية لهذا التحول الأوسع نطاقاً.

بالنسبة لمستخدمي Milvus الذين يعتمدون على MinIO بشكل افتراضي، من الصعب تجاهل هذا التغيير. يقع تخزين الكائنات في قلب طبقة المثابرة في Milvus، ولا تعتمد موثوقيتها بمرور الوقت على ما يعمل اليوم فحسب، بل على ما إذا كان النظام يستمر في التطور جنبًا إلى جنب مع أعباء العمل التي يدعمها.

على هذه الخلفية، تستكشف هذه المقالة نظام RustFS كبديل محتمل. نظام RustFS هو نظام تخزين كائنات متوافق مع S3 قائم على Rust ومتوافق مع S3 ويركز على سلامة الذاكرة وتصميم الأنظمة الحديثة. لا يزال تجريبيًا، وهذه المناقشة ليست توصية إنتاج.

بنية ميلفوس وأين يقع مكوّن تخزين الكائنات

يعتمد ميلفوس 2.6 على بنية تخزين وحوسبة منفصلة تماماً. في هذا النموذج، تتألف طبقة التخزين من ثلاثة مكونات مستقلة، يخدم كل منها دورًا مميزًا.

يخزن Etcd البيانات الوصفية، ويتعامل Pulsar أو Kafka مع سجلات التدفق، ويوفر تخزين الكائنات - عادةً MinIO أو خدمة متوافقة مع S3 - ثباتًا دائمًا للبيانات المتجهة وملفات الفهرس. نظرًا لفصل التخزين عن الحوسبة، يمكن ل 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 واجهة برمجة تطبيقات S3

بدلاً من تحديد بروتوكول تخزين مخصص، تستخدم Milvus واجهة برمجة تطبيقات S3 كواجهة تخزين كائناتها. أصبح S3 معيارًا فعليًا لتخزين الكائنات: يدعمه موفرو الخدمات السحابية الرئيسيون مثل AWS S3 و Alibaba Cloud OSS و Tencent Cloud COS، بينما الأنظمة مفتوحة المصدر مثل MinIO و Ceph RGW و SeaweedFS و RustFS متوافقة تمامًا.

من خلال التوحيد القياسي على واجهة برمجة تطبيقات S3، يمكن ل Milvus الاعتماد على حزم SDKs Go الناضجة والمُختبرة جيدًا بدلاً من الحفاظ على تكامل منفصل لكل واجهة تخزين خلفية. هذا التجريد يمنح المستخدمين أيضًا مرونة في النشر: 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.0-alpha.68) ويهدف إلى الجمع بين البساطة التشغيلية ل MinIO ونقاط قوة Rust في سلامة الذاكرة والأداء. يتوفر المزيد من التفاصيل على GitHub.

لا يزال RustFS قيد التطوير النشط، ولم يتم إصدار وضع التوزيع الخاص به رسميًا بعد. ونتيجة لذلك، لا يوصى باستخدام RustFS للإنتاج أو أعباء العمل الحرجة في هذه المرحلة.

تصميم البنية

يتبع RustFS تصميمًا مشابهًا من الناحية المفاهيمية ل MinIO. يعرض خادم HTTP واجهة برمجة تطبيقات متوافقة مع S3، بينما يتعامل مدير الكائنات مع البيانات الوصفية للكائنات، ويكون محرك التخزين مسؤولاً عن إدارة كتلة البيانات. في طبقة التخزين، يعتمد RustFS على أنظمة الملفات القياسية مثل XFS أو ext4.

بالنسبة للوضع الموزع المخطط له، يعتزم RustFS استخدام إلخd لتنسيق البيانات الوصفية مع عقد RustFS المتعددة التي تشكل مجموعة. يتماشى هذا التصميم بشكل وثيق مع بنيات تخزين الكائنات الشائعة، مما يجعل RustFS مألوفًا للمستخدمين ذوي الخبرة في MinIO.

التوافق مع ميلفوس

قبل التفكير في استخدام RustFS كواجهة خلفية بديلة لتخزين الكائنات، من الضروري تقييم ما إذا كانت تفي بمتطلبات التخزين الأساسية ل Milvus.

متطلبات Milvus	واجهة برمجة تطبيقات S3	دعم RustFS
ثبات البيانات المتجهة	PutObject, GetObject	✅ مدعوم بالكامل
إدارة ملفات الفهرس	ListObjects, DeleteObject	✅ مدعومة بالكامل
عمليات دمج الأجزاء	تحميل متعدد الأجزاء	✅ مدعومة بالكامل
ضمانات الاتساق	قراءة قوية بعد الكتابة	✅ اتساق قوي (عقدة واحدة)

بناءً على هذا التقييم، يفي تطبيق واجهة برمجة تطبيقات S3 الحالية في RustFS بالمتطلبات الوظيفية الأساسية ل Milvus. وهذا يجعله مناسبًا للاختبار العملي في البيئات غير الإنتاجية.

التدريب العملي: استبدال MinIO ب RustFS في Milvus

الهدف من هذا التمرين هو استبدال خدمة تخزين كائنات MinIO الافتراضية ونشر Milvus 2.6.7 باستخدام RustFS كواجهة خلفية لتخزين الكائنات.

المتطلبات الأساسية

1. يتم تثبيت Docker و Docker Compose (الإصدار ≥ 20.10)، ويمكن للنظام سحب الصور وتشغيل الحاويات بشكل طبيعي.

2. يتوفر دليل محلي لتخزين بيانات الكائنات، مثل /volume/data/ (أو مسار مخصص).

3. يكون المنفذ المضيف 9000 مفتوحًا للوصول الخارجي، أو يتم تكوين منفذ بديل وفقًا لذلك.

4. تعمل حاوية RustFS كمستخدم غير جذر (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 الرسمي

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.

تعريف milvus_load_bench(dim=768، الصفوف=1_000_000، الدفعة=5000): المجموعة = المجموعة(...) # إدراج الاختبار t0 = time.perf_counter() ل i في النطاق(0، الصفوف، الدفعة): المجموعة.insert([rng.random((batch, dim), dtype=np.float32).tolist()]) insert_time = time.perf_counter() - t0 # إنشاء الفهرس collection.flush() collection.create_index(field_name="التضمين"، index_params={"index_type": "HNSW"، ...}) # اختبار التحميل (بداية باردة + بدايتين دافئتين) التجميع.التحرير() load_times = [] لـ i في النطاق (3): إذا i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # اختبار الاستعلام search_times = [] لـ _ في النطاق (3): collection.search(queries, limit=10, ...)

**Test Command**

python bench.py milvus-load-bench - dim 768 - الصفوف 1000000 - الدفعة 5000
-نوع الفهرس HNSW -تكرار التحميل 3 -التحرير قبل التحميل -إجراء البحث -إسقاط ما بعد

**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).