Démystifier l’outil de dimensionnement Milvus
Introduction
Sélectionner la configuration optimale pour votre déploiement Milvus est essentiel pour optimiser les performances, utiliser efficacement les ressources et gérer les coûts. Que vous construisiez un prototype ou planifiiez un déploiement en production, dimensionner correctement votre instance Milvus peut faire la différence entre une base de données vectorielle qui fonctionne sans accroc et une autre qui peine en matière de performances ou entraîne des coûts inutiles.
Pour simplifier ce processus, nous avons repensé notre outil de dimensionnement Milvus, un calculateur convivial qui génère des estimations de ressources recommandées en fonction de vos exigences spécifiques. Dans ce guide, nous vous expliquerons comment utiliser l’outil et fournirons des informations plus approfondies sur les facteurs qui influencent les performances de Milvus.
Comment utiliser l’outil de dimensionnement Milvus
Cet outil de dimensionnement est très facile à utiliser. Il vous suffit de suivre les étapes suivantes.
Consultez la page de l’outil de dimensionnement Milvus.
Saisissez vos paramètres clés :
Nombre de vecteurs et dimensions par vecteur
Type d’index
Taille des données des champs scalaires
Taille de segment
Votre mode de déploiement préféré
Examinez les recommandations de ressources générées
outil de dimensionnement milvus
Voyons comment chacun de ces paramètres influe sur votre déploiement Milvus.
Sélection de l’index : équilibrer stockage, coût, précision et vitesse
Milvus propose divers algorithmes d’indexation, notamment HNSW, FLAT, IVF_FLAT, IVF_SQ8, ScaNN, DiskANN, et bien d’autres, chacun avec des compromis distincts en matière d’utilisation de la mémoire, d’exigences d’espace disque, de vitesse de requête et de précision de recherche.
Voici ce que vous devez savoir sur les options les plus courantes :
index
HNSW (Hierarchical Navigable Small World)
Architecture : Combine des skip lists avec des graphes Navigable Small Worlds (NSW) dans une structure hiérarchique
Performance : Requêtes très rapides avec d’excellents taux de rappel
Utilisation des ressources : Nécessite le plus de mémoire par vecteur (coût le plus élevé)
Idéal pour : Les applications où la vitesse et la précision sont essentielles et où les contraintes de mémoire sont moins préoccupantes
Note technique : La recherche commence à la couche la plus élevée, qui comporte le moins de nœuds, puis descend à travers des couches de plus en plus denses
FLAT
Architecture : Recherche exhaustive simple sans approximation
Performance : Rappel de 100 %, mais temps de requête extrêmement lents (
O(n)pour une taille de donnéesn)Utilisation des ressources : La taille de l’index est égale à la taille des données vectorielles brutes
Idéal pour : Les petits jeux de données ou les applications nécessitant un rappel parfait
Note technique : Effectue des calculs de distance complets entre le vecteur de requête et chaque vecteur de la base de données
IVF_FLAT
Architecture : Divise l’espace vectoriel en clusters pour une recherche plus efficace
Performance : Rappel moyen à élevé avec une vitesse de requête modérée (plus lent que HNSW, mais plus rapide que FLAT)
Utilisation des ressources : Nécessite moins de mémoire que FLAT, mais plus que HNSW
Idéal pour : Les applications équilibrées où une partie du rappel peut être échangée contre de meilleures performances
Note technique : Lors de la recherche, seuls
nlistclusters sont examinés, ce qui réduit considérablement le calcul
IVF_SQ8
Architecture : Applique une quantification scalaire à IVF_FLAT, en compressant les données vectorielles
Performance : Rappel moyen avec une vitesse de requête moyenne à élevée
Utilisation des ressources : Réduit la consommation de disque, de calcul et de mémoire de 70 à 75 % par rapport à IVF_FLAT
Idéal pour : Les environnements à ressources limitées où la précision peut être légèrement compromise
Note technique : Compresse les valeurs en virgule flottante 32 bits en valeurs entières 8 bits
Options d’index avancées : ScaNN, DiskANN, CAGRA, et plus encore
Pour les développeurs ayant des exigences spécialisées, Milvus propose également :
ScaNN : 20 % plus rapide sur CPU que HNSW avec des taux de rappel similaires
DiskANN : Un index hybride disque/mémoire idéal lorsque vous devez prendre en charge un grand nombre de vecteurs avec un rappel élevé et pouvez accepter une latence légèrement plus longue (~100 ms). Il équilibre l’utilisation de la mémoire et les performances en ne conservant qu’une partie de l’index en mémoire tandis que le reste demeure sur disque.
Index basés sur GPU :
GPU_CAGRA : C’est le plus rapide des index GPU, mais il nécessite une carte d’inférence avec mémoire GDDR plutôt qu’une carte avec mémoire HBM
GPU_BRUTE_FORCE : Recherche exhaustive implémentée sur GPU
GPU_IVF_FLAT : Version accélérée par GPU de IVF_FLAT
GPU_IVF_PQ : Version accélérée par GPU de IVF avec Product Quantization
HNSW-PQ/SQ/PRQ :
HNSW_SQ : Requête à très grande vitesse, ressources mémoire limitées ; accepte un compromis mineur sur le taux de rappel.
HNSW_PQ : Requête à vitesse moyenne ; ressources mémoire très limitées ; accepte un compromis mineur sur le taux de rappel
HNSW_PRQ : Requête à vitesse moyenne ; ressources mémoire très limitées ; accepte un compromis mineur sur le taux de rappel
AUTOINDEX : Utilise HNSW par défaut dans Milvus open source (ou utilise des index propriétaires plus performants dans Zilliz Cloud, le Milvus géré).
Index binaires, clairsemés et autres index spécialisés : Pour des types de données et des cas d’utilisation spécifiques. Consultez cette page de documentation sur les index pour plus de détails.
Taille des segments et configuration du déploiement
Les segments sont les blocs de base fondamentaux de l’organisation interne des données de Milvus. Ils fonctionnent comme des blocs de données qui permettent la recherche distribuée et l’équilibrage de charge dans votre déploiement. Cet outil de dimensionnement Milvus propose trois options de taille de segment (512 Mo, 1024 Mo, 2048 Mo), avec 1024 Mo par défaut.
Comprendre les segments est essentiel pour l’optimisation des performances. À titre indicatif :
Segments de 512 Mo : Idéal pour les nœuds de requête avec 4 à 8 Go de mémoire
Segments de 1 Go : Optimal pour les nœuds de requête avec 8 à 16 Go de mémoire
Segments de 2 Go : Recommandé pour les nœuds de requête avec >16 Go de mémoire
Point de vue développeur : Des segments moins nombreux et plus grands offrent généralement des performances de recherche plus rapides. Pour les déploiements à grande échelle, les segments de 2 Go offrent souvent le meilleur équilibre entre efficacité mémoire et vitesse de requête.
Sélection du système de file d’attente de messages
Lorsque vous choisissez entre Pulsar et Kafka comme système de messagerie :
Pulsar : Recommandé pour les nouveaux projets en raison d’une surcharge plus faible par sujet et d’une meilleure évolutivité
Kafka : Peut être préférable si vous disposez déjà d’une expertise ou d’une infrastructure Kafka dans votre organisation
Optimisations d’entreprise dans Zilliz Cloud
Pour les déploiements en production avec des exigences de performance strictes, Zilliz Cloud (la version entièrement gérée et entreprise de Milvus dans le cloud) offre des optimisations supplémentaires en matière d’indexation et de quantification :
Prévention des dépassements de mémoire (OOM) : Gestion sophistiquée de la mémoire pour éviter les plantages dus au manque de mémoire
Optimisation de la compaction : Améliore les performances de recherche et l’utilisation des ressources
Stockage hiérarchisé : Gérer efficacement les données chaudes et froides avec des unités de calcul appropriées
Unités de calcul standard (CU) pour les données fréquemment consultées
CU de stockage hiérarchisé pour le stockage rentable des données rarement consultées
Pour des options détaillées de dimensionnement d’entreprise, consultez la documentation des plans de service Zilliz Cloud.
Conseils de configuration avancée pour les développeurs
Types d’index multiples : L’outil de dimensionnement se concentre sur un seul index. Pour les applications complexes nécessitant différents algorithmes d’indexation pour diverses collections, créez des collections séparées avec des configurations personnalisées.
Allocation de mémoire: Lors de la planification de votre déploiement, tenez compte à la fois des exigences en mémoire pour les données vectorielles et pour l’index. HNSW nécessite généralement 2 à 3 fois la mémoire des données vectorielles brutes.
Tests de performance: Avant de finaliser votre configuration, évaluez vos modèles de requêtes spécifiques sur un jeu de données représentatif.
Considérations de mise à l’échelle: Tenez compte de la croissance future. Il est plus facile de commencer avec un peu plus de ressources que de reconfigurer plus tard.
Conclusion
L’ outil de dimensionnement Milvus fournit un excellent point de départ pour la planification des ressources, mais n’oubliez pas que chaque application a des exigences uniques. Pour des performances optimales, vous devrez affiner votre configuration en fonction des caractéristiques spécifiques de votre charge de travail, de vos modèles de requêtes et de vos besoins de mise à l’échelle.
Nous améliorons continuellement nos outils et notre documentation en fonction des retours des utilisateurs. Si vous avez des questions ou avez besoin d’une assistance supplémentaire pour dimensionner votre déploiement Milvus, contactez notre communauté sur GitHub ou Discord.
Références
Fendy FengFendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
Ken ZhangKen Zhang is a Senior Product Manager at Zilliz, leading the development of the Milvus vector database by setting its strategic direction and key features. Prior to Zilliz, he served as a kernel engineer at SAP HANA and enhanced his product management skills at PingCAP. Ken holds a master's degree from Fudan University and has over eight years of experience specializing in database development and big data infrastructure management.
Continuer à lire
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.