تصور کنید یک شرکت تجارت الکترونیکی متوسط با کاتالوگی مواجه شود که در اواخر سال ۲۰۲۴ به ۸۰۰ میلیون آیتم می‌رسد و ناگهان زیرساخت جست‌وجوی آن‌ها فروپاشی کند. در چنین وضعیتی، پرس‌وجوها روی یک نمونه تک-گره (Single-node) از Postgres با افزونه pgvector تا ۴.۲ ثانیه طول می‌کشید و در مقابل، جایگزین‌های مدیریت‌شده (Managed) برای چنین حجمی، ماهانه ۱۲,۰۰۰ دلار هزینه demanding می‌کردند. Milvus 2.5 — پایگاه‌داده برداری (Vector Database) متن‌باز و فارغ‌تحصیل شده از CNCF که توسط Zilliz نگهداری می‌شود — با treating کردن جست‌وجوی نزدیک‌ترین همسایه تقریبی (ANN) به عنوان یک Primitive معماری درجه‌یک (و نه صرفاً یک افزونه دیتابیس)، این «مشکل میلیارد-برداری» را حل می‌کند.
بسیاری از توسعه‌دهندگان مسیر خود را با پلاگین‌های برداری ساده شروع می‌کنند، زیرا استقرار آن‌ها راحت است. با این حال، وقتی مجموعه‌داده‌ها به مرز صد میلیون مورد می‌رسند، این سیستم‌های Monolithic در برابر تأخیر پرس‌وجو و مصرف حافظه به یک دیوار سخت برخورد می‌کنند. اینجاست که تغییر به یک معماری توزیع‌شده و Cloud-native، Milvus را از پایگاه‌داده‌های همه‌منظوره متمایز می‌کند. با جداسازی ذخیره‌سازی از محاسبات (Decoupling storage from compute)، این سیستم به تیم‌ها اجازه می‌دهد قابلیت‌های جست‌وجوی خود را به‌صورت افقی در خوشه‌های Kubernetes گسترش دهند.
معماری جست‌وجو در مقیاس میلیارد
Milvus 2.5 از یک معماری میکروسرویس متشکل از پنج جزء اصلی برای حفظ عملکرد در مقیاس بالا استفاده می‌کند. Proxy درخواست‌های کلاینت و توازن بار (Load Balancing) را مدیریت می‌کند. Query Nodes جست‌وجوی ANN را روی بخش‌های شاخص‌گذاری شده‌ی بارگذاری‌شده اجرا می‌کنند. Data Nodes مسئولیت درج (Insertion)، تخلیه (Flushing) و فشرده‌سازی (Compaction) بردارها را بر عهده دارند. Index Nodes شاخص‌های برداری را می‌سازند و Coordinators مدیریت متادیتای سیستم را از طریق etcd بر عهده می‌گیرند.
ذخیره‌سازی در این معماری به‌گونه‌ای طراحی شده که استراتژی‌های ذخیره‌سازی لایه‌بندی شده (Tiered Storage) را ممکن سازد. متادیتا در etcd جای می‌گیرد، در حالی که داده‌های برداری واقعی و شاخص‌ها در MinIO یا S3 ذخیره می‌شوند. این ساختار اجازه می‌دهد بردارهای «داغ» (Hot) برای دستیابی به حداکثر سرعت روی حافظه‌های محلی NVMe باقی بمانند و بردارهای «گرم» (Warm) برای کاهش هزینه‌ها به Object Storage منتقل شوند.
شتاب‌دهی GPU و تحلیل عملکرد
یکی از قابل‌توجه‌ترین به‌روزرسانی‌ها در نسخه ۲.۵، ادغام NVIDIA RAFT برای ساخت شاخص‌های شتاب‌یافته با GPU است. بر اساس بنچمارک‌های منتشر شده در مه ۲۰۲۶، یک GPU مدل Tesla T4 می‌تواند شاخص‌ها را تقریباً ۶ برابر سریع‌تر از ساخت‌های مبتنی بر CPU ایجاد کند. این امر منجر به توان عملیاتی (Throughput) indexing معادل ۳۲۰,۰۰۰ بردار در ثانیه می‌شود.
در آزمایش‌های مستقلی که در آپریل ۲۰۲۶ روی مجموعه داده dbpedia-openai-1M (شامل یک میلیون بردار با ۱۵۳۶ بُعد) انجام شد، Milvus (با GPU T4) به تأخیر p99 معادل ۸ میلی‌ثانیه دست یافت. این نتیجه به‌وضوح از Pinecone (۲۸ میلی‌ثانیه) و Weaviate (۱۹ میلی‌ثانیه) برتر است و در عین حال با Qdrant (۱۲ میلی‌ثانیه) رقابتی می‌ماند.
مسیرهای استقرار: از داکر تا کوبرنتیز
برای تست‌های محلی، Milvus یک استقرار Standalone با Docker ارائه می‌دهد که می‌تواند در کمتر از ۵ دقیقه فعال شود. با این حال، محیط‌های عملیاتی (Production) برای بهره‌برداری از حالت توزیع‌شده به استقرار مبتنی بر Helm در Kubernetes نیاز دارند. این پیکربندی شامل etcd برای هماهنگی و MinIO توزیع‌شده برای ذخیره‌سازی اشیاء است.
برای کسانی که نمی‌توانند پیچیدگی‌های عملیاتی Kubernetes را مدیریت کنند، Zilliz Cloud یک نسخه کاملاً مدیریت‌شده فراهم می‌کند. از آنجایی که هر دو نسخه از یک API واحد استفاده می‌کنند، کدهایی که برای نسخه متن‌باز نوشته شده‌اند، بدون هیچ تغییری به ابر مدیریت‌شده منتقل می‌شوند.
عملیات هسته و یکپارچه‌سازی
Milvus از چندین نوع شاخص از جمله HNSW، IVF-PQ و DiskANN پشتیبانی می‌کند. برای مثال، ایجاد یک شاخص HNSW با نوع متریک L2 امکان جست‌وجوی معنایی با سرعت بسیار بالا را فراهم می‌کند. این سیستم همچنین از جست‌وجوی ترکیبی (Hybrid Search) پشتیبانی می‌کند که در آن شباهت برداری با فیلترهای متادیتا ترکیب می‌شود (به عنوان مثال، فیلتر کردن بر اساس دسته‌بندی کالا در حالی که برای یک Embedding خاص جست‌وجو می‌شود).
یکپارچه‌سازی با پشته‌های مدرن AI از طریق فریم‌ورک‌های موجود به‌صورت بدون‌درز (Seamless) انجام می‌شود:
- LangChain: با استفاده از بسته
langchain-milvusبرای ذخیره Embeddingهای اسناد. - LlamaIndex: بهره‌گیری از
MilvusVectorStoreبرای شاخص‌گذاری دایرکتوری‌های داده‌های محلی. - OpenAI: سازگاری کامل با مدل
text-embedding-3-large(با ۱۵۳۶ بُعد).
مقاوم‌سازی عملیاتی و چند-مستأجری
برای مدیریت هزینه‌ها در مقیاس ۱۰ میلیارد بردار، پیکربندی ذخیره‌سازی لایه‌بندی شده حیاتی است. با تنظیم محدودیت‌های حافظه برای گرم کردن (Warm-up) و فعال‌سازی کش دیسک محلی، تیم‌ها می‌توانند پربازدیدترین داده‌ها را در حافظه‌های پرسرعت نگه دارند.
در کاربردهای چند-مستأجری (Multi-tenant)، Milvus از پارتیشن‌ها پشتیبانی می‌کند. این قابلیت به توسعه‌دهندگان اجازه می‌دهد داده‌های مشتریان مختلف را ایزوله کنند (مثلاً ایجاد یک پارتیشن tenant_acme) و جست‌وجوها را به یک پارتیشن خاص محدود کنند که این امر به‌طور قابل‌توجهی عملکرد پرس‌وجو و امنیت را بهبود می‌بخشد.
ارزیابی صادقانه و سبک-سنگین کردن (Trade-offs)
علیرغم عملکرد خیره‌کننده، Milvus جایگزینی جهانی برای هر نیاز به جست‌وجوی برداری نیست. پیچیدگی عملیاتی آن بالا است؛ این سیستم نیازمند تخصص در Kubernetes، etcd و پیام‌رسان‌هایی (Message Brokers) مانند Pulsar یا Kafka است و یک فایل باینری تک-فایلی (Single-binary) نیست.
در حجم‌های زیر ۱۰ میلیون بردار، معماری توزیع‌شده احتمالاً زیاده‌روی (Overkill) است. در این موارد، یک نمونه تک-گره از Qdrant یا pgvector سریع‌تر مستقر شده و مدیریت آن آسان‌تر خواهد بود. علاوه بر این، Milvus به جای رابط‌های SQL سنتی، از APIهای gRPC/REST استفاده می‌کند که ممکن است برای تیم‌هایی که عمیقاً با جریان‌های کاری SQL عجین شده‌اند، یک مانع باشد.
این معماری معیارهای ممکن در AI میزبانی-شخصی (Self-hosted) را تغییر می‌دهد. با جابه‌جایی سقف مقیاس به بیش از ۱۰ میلیارد بردار، Milvus «دیوار قیمتی» سرویس‌های ابری اختصاصی را در مقیاس‌های شدید می‌شکند و گلوگاه را از محدودیت‌های نرم‌افزاری به دسترسی سخت‌افزاری و توانمندی DevOps منتقل می‌کند.
اگر در حال ساخت یک سیستم RAG هستید که نیاز دارد در سال آینده از ۱۰۰ میلیون Embedding عبور کند، باید سقف تأخیر زیرساخت فعلی خود را ارزیابی کنید. این بهینه‌سازی زیرساختی در کنار تکنیک‌های پیشرفته‌تر در لایه پردازش، مانند به‌کارگیری متد SIFT برای افزایش سرعت پیش‌تولید RAG، می‌تواند گلوگاه‌های زمانی را به‌طور کامل حذف کند. پیشنهاد می‌شود ابتدا نسخه Standalone Docker را مستقر کنید تا بنچمارک ابعاد برداری خاص خود را پیش از تعهد به یک خوشه Kubernetes بسنجید.
گام بعدی شما
- اگر سیستم تولید بازیابی‌افزا (RAG) شما در سال آینده از ۱۰۰ میلیون بردار عبور می‌کند، سقف تأخیر زیرساخت فعلی خود را اندازه‌گیری کنید.
- نسخه Standalone Docker را نصب کنید تا تأخیر مربوط به ابعاد بردار (Embedding Dimensions) خاص خودتان را بسنجید.
- استراتژی ذخیره‌سازی لایه‌بندی شده (Tiered Storage) را برای کاهش هزینه‌های VRAM بررسی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو