Architectures de référence Milvus
Ce blog répond à certaines questions fréquemment posées concernant l’allocation des ressources de Milvus en fonction de cas d’utilisation spécifiques. Ces questions incluent :
Quelle quantité de ressources CPU et mémoire est nécessaire pour Milvus, en fonction d’un nombre spécifique d’utilisateurs ou de requêtes par seconde (RPS) ?
Quelle quantité de ressources CPU et mémoire est nécessaire pour Milvus, en fonction de différents mélanges de READ et WRITE ?
Comprendre les caractéristiques de votre charge de travail
La première étape de l’allocation des ressources à Milvus consiste à comprendre les caractéristiques de votre charge de travail. Ces facteurs jouent un rôle crucial dans la détermination de la puissance de calcul et des besoins en mémoire de Milvus.
Voici une liste d’exemples d’architectures de référence basées sur des packages Linux, où RPS signifie Requests Per Second :
Jusqu’à 20 RPS ou 1 000 utilisateurs API : 20 RPS, Web : 2 RPS, Git (Pull) : 2 RPS, Git (Push) : 1 RPS
Jusqu’à 40 RPS ou 2 000 utilisateurs API : 40 RPS, Web : 4 RPS, Git (Pull) : 4 RPS, Git (Push) : 1 RPS
Jusqu’à 60 RPS ou 3 000 utilisateurs API : 60 RPS, Web : 6 RPS, Git (Pull) : 6 RPS, Git (Push) : 1 RPS
Jusqu’à 100 RPS ou 5 000 utilisateurs API : 100 RPS, Web : 10 RPS, Git (Pull) : 10 RPS, Git (Push) : 2 RPS
Jusqu’à 200 RPS ou 10 000 utilisateurs API : 200 RPS, Web : 20 RPS, Git (Pull) : 20 RPS, Git (Push) : 4 RPS
Jusqu’à 500 RPS ou 25 000 utilisateurs API : 500 RPS, Web : 50 RPS, Git (Pull) : 50 RPS, Git (Push) : 10 RPS
Jusqu’à 1000 RPS ou 50 000 utilisateurs API : 1000 RPS, Web : 100 RPS, Git (Pull) : 100 RPS, Git (Push) : 20 RPS
Estimer les besoins en ressources
Pour estimer les besoins en ressources pour Milvus, nous devons formuler quelques hypothèses :
Lectures : chaque requête web et chaque Git pull est une opération READ.
Écritures : chaque Git push est considéré comme une opération WRITE.
Volume et ratio des lectures/écritures : Milvus est supposé être identique au ratio lecture/écriture des appels API par nombre d’utilisateurs.
Requêtes par seconde (QPS) : doivent correspondre à l’exigence de RPS de l’API (requêtes par seconde) par nombre d’utilisateurs.
Nous devons également estimer la taille des données par requête de lecture/écriture. Nous supposerons un cas d’utilisation GenAI courant :
Dimension du vecteur : 1024 nombres à virgule flottante
Taille en octets par nombre à virgule flottante : 4 KB
Top_k (nombre de vecteurs renvoyés) : 10 vecteurs par requête de recherche
Taille d’une collection (table de base de données) : 1 million de vecteurs par requête d’écriture
Type d’index de base de données : HNSW
Sur la base de ces hypothèses, nous pouvons faire un calcul approximatif pour estimer la taille des données par lecture ou écriture. Supposons que la dimension du vecteur soit de 1024, et que chaque vecteur occupe 1024 * 4 octets = 4 KB. Supposons un top_k typique = 10 vecteurs par lecture. Avec ces hypothèses :
Chaque opération de lecture Milvus traite environ 40 KB de données.
Chaque opération d’écriture Milvus est estimée impliquer 40 MB de données.
Milvus propose à la fois des fonctionnalités d’insert (créer une collection entièrement nouvelle) et d’upsert (modifier quelques lignes) (Voir le blog Milvus insert, upsert, delete pour plus d’informations). Nous allons surestimer chaque opération WRITE comme étant l’insertion d’une collection entière plutôt que seulement des upserts de quelques lignes.
Les bases de données doivent prendre en compte non seulement la taille des données, mais aussi la vitesse de recherche et d’insertion. Nous supposerons que la collection est indexée à l’aide du populaire index HNSW, qui a un temps de recherche en notation Big-O, O(log n).
Avec ces hypothèses, voici notre conversion des utilisateurs/RPS/lectures/écritures Web vers des niveaux d’architecture QPS/taille des données pour bases de données vectorielles :
Jusqu’à 1 000 utilisateurs = 20 QPS avec 1 million de vecteurs
Jusqu’à 2 000 utilisateurs = 40 QPS avec 1 million de vecteurs
Jusqu’à 3 000 utilisateurs = 60 QPS avec 1 million de vecteurs
Jusqu’à 5 000 utilisateurs = 100 QPS avec 2 millions de vecteurs
Jusqu’à 10 000 utilisateurs = 200 QPS avec 4 millions de vecteurs
Jusqu’à 25 000 utilisateurs = 500 QPS avec 10 millions de vecteurs
Jusqu’à 50 000 utilisateurs = 1000 QPS avec 20 millions de vecteurs
Tests de charge et benchmarking
Pour garantir l’exactitude de nos estimations de ressources, nous avons effectué des tests de charge et des benchmarks des niveaux d’architecture sur VectorDBBench. Nous avons supposé les tailles par défaut des Segment, Partition, Shard, Data node, Query node et Index node pour l’architecture Milvus elle-même.
Grâce aux capacités d’autoscaling de Milvus, les performances sont linéaires par rapport à la taille des données et aux ressources du cluster ! Vous trouverez ci-dessous un tableau indiquant les tailles de ressources recommandées pour Milvus et Zilliz Cloud (Milvus entièrement géré) pour différentes capacités de données et exigences de QPS.
Le tableau ci-dessous indique la capacité de données en millions de vecteurs 1024_dimension. Les ressources Milvus sont données en nombre de CPU et en Go de mémoire. À des fins de comparaison des coûts, nous indiquons les tailles de ressources Zilliz Cloud, données en Compute Units (cu), en types performance ou capacité.
Tableau des tailles de ressources Milvus et Zilliz recommandées par niveaux Utilisateurs/RPS
| Utilisateurs | Capacité de données | QPS benchmarké | RPS requis | Ressource Milvus | Ressource Zilliz |
| 3,000 | 1m_1024d vectors | 1200 | 60 | 8CPU, 32G | 1cu-perf |
| 3,000 | 1m_1024d vectors | 2400 | 60 | 16CPU, 64G | 2cu-perf |
| 3,000 | 1m_1024d vectors | 3600 | 60 | 24CPU, 96G | 4cu-perf |
| 10,000 | 3.7m_1024d vectors | 360 | 200 | 16CPU, 64G | 2cu-cap |
| 10,000 | 3.7m_1024d vectors | 700 | 200 | 64CPU, 256G | 4cu-cap |
| 25,000 | 10m_1024d vectors | 600 | 500 | 196CPU, 768G | 12cu- cap |
| 250,000 | 100m_1024d vectors | 6000 | 5000 | 19200CPU, 76800G | 1200cu- cap |
Tableau des tailles de ressources Milvus et Zilliz recommandées par nombre de niveaux Utilisateurs/RPS. La mise à l’échelle de Milvus est linéaire par rapport à la taille des données et au QPS requis.
D’après le tableau ci-dessus, lorsque la taille des données et le QPS doivent atteindre un certain seuil, il peut être plus rentable d’exécuter Milvus depuis Zilliz Cloud plutôt que sur site.
Conclusion
En comprenant les caractéristiques de votre charge de travail, en estimant les besoins en ressources sur la base d’hypothèses et en tirant parti d’outils de test de charge et de benchmarking tels que VectorDBBench, vous pouvez provisionner en toute confiance les ressources nécessaires à votre déploiement Milvus.
Consultez notre guide de dimensionnement des clusters pour approfondir le sujet. N’oubliez pas qu’à mesure que votre charge de travail évolue, il est essentiel de revoir et d’ajuster régulièrement votre allocation de ressources afin de maintenir des performances optimales.
Références
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Architecture Milvus: https://docs.gitlab.com/ee/administration/reference_architectures/
Blog Milvus Packaging Dependencies: https://zilliz.com/blog/Milvus-server-docker-installation-and-packaging-dependencies
Blog Milvus Sizing Tool: https://medium.com/@zilliz_learn/demystifying-the-milvus-sizing-tool-2c0afe7fe963
Shards, Partitions, Segments: https://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Types de CU Zilliz Cloud: https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
Outil VectorDBBench pour le benchmarking de Milvus, Zilliz Cloud et de nombreuses autres bases de données vectorielles courantes
Continuer à lire
Zilliz Cloud Now Available in AWS Europe (Ireland)
Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.