Alibaba Cloud AISearch for Milvus (Milvus) propose différents types de Compute Unit (CU) et un nombre flexible de nœuds de calcul (Query Node). Utilisez cette référence pour sélectionner le type d'instance adapté à votre scénario métier.
Types de CU
Les nœuds de calcul Milvus prennent en charge les types de CU suivants :
Optimisé pour le calcul : Idéal pour les charges de travail exigeant un QPS élevé et une faible latence, telles que la recherche, les systèmes de recommandation, l'IA générative et les chatbots.
-
Optimisé pour le stockage : Conçu pour les volumes de données importants avec des exigences modérées en matière de performances de recherche. Les instances optimisées pour le stockage offrent une capacité quatre fois supérieure à celle des instances optimisées pour le calcul, tout en garantissant d'excellentes performances adaptées à la plupart des scénarios. Elles conviennent parfaitement à la récupération de données non structurées à grande échelle, à la détection de droits d'auteur et à la préparation des données de modèles.
ImportantLes CU optimisées pour le stockage présentent actuellement les limitations suivantes :
Seuls le scale-out et le scale-in sont pris en charge. Les mises à niveau ou rétrogradations verticales ne sont pas disponibles. Vérifiez attentivement les spécifications des CU avant l'achat.
L'index DiskANN est recommandé. Ce type d'index prend uniquement en charge les données vectorielles de type float. Pour mesurer la distance entre les vecteurs, seules la distance euclidienne (L2), le produit scalaire (IP) et la similarité cosinus (COSINE) sont prises en charge.
Comparaison de la capacité de stockage
|
Type de CU |
Type d'index |
Spécifications des CU |
Référence de capacité des données vectorielles (basée sur des données vectorielles SIFT à 128 dimensions) |
Référence de capacité des données vectorielles (basée sur des données vectorielles GIST à 960 dimensions) |
|
Optimisé pour le calcul |
HNSW M:30 efConstruction:360 |
4 vCPU 16 GiB (4 CUs) |
16 millions |
3 millions |
|
8 vCPU 32 GiB (8 CUs) |
32 millions |
6 millions |
||
|
16 vCPU 64 GiB (16 CUs) |
64 millions |
12 millions |
||
|
32 vCPU 128 GiB (32 CUs) |
128 millions |
24 millions |
||
|
Optimisé pour le stockage |
DiskANN |
8 vCPU 32 GiB (8 CUs) |
120 millions |
23 millions |
|
16 vCPU 64 GiB (16 CUs) |
240 millions |
46 millions |
||
|
32 vCPU 128 GiB (32 CUs) |
480 millions |
92 millions |
Les données du tableau proviennent de tests de performance et servent de référence pour l'évaluation de la capacité.
Le jeu de données de test contient uniquement des clés primaires et des données vectorielles, sans champs scalaires. Les clés primaires sont des entiers positifs auto-incrémentés commençant à zéro, convertis en chaînes. Comme les champs scalaires sont indispensables dans la plupart des environnements de production et consomment également de l'espace de stockage, le nombre réel de vecteurs stockables sera inférieur aux valeurs indiquées dans le tableau.
Comparaison des performances de récupération
|
Type de CU |
Spécifications des CU |
Type d'index |
topk=50 |
topk=100 |
topk=250 |
topk=1000 |
||||
|
QPS |
RT_p99 |
QPS |
RT_p99 |
QPS |
RT_p99 |
QPS |
RT_p99 |
|||
|
Optimisé pour le calcul |
16 vCPU 64 GiB (16 CUs) |
HNSW M:30 efConstruction:360 |
2000 |
< 10 ms |
1200 |
< 10 ms |
550 |
< 15 ms |
150 |
< 30 ms |
|
Optimisé pour le stockage |
16 vCPU 64 GiB (16 CUs) |
DiskANN |
700 |
< 15 ms |
550 |
< 20 ms |
200 |
< 30 ms |
60 |
< 50 ms |
Ces données reposent sur les résultats de tests effectués avec le jeu de données Cohere (10 millions de vecteurs, 768 dimensions). Les performances réelles varient selon la distribution des données des différents jeux de données.
La métrique RT_p99 correspond au 99e centile du temps de réponse obtenu en exécutant 1 000 requêtes séquentiellement.
Les données de test contiennent uniquement des clés primaires et des données vectorielles, sans champs scalaires. Les clés primaires sont des entiers positifs auto-incrémentés commençant à zéro. L'index HNSW est utilisé pour les instances optimisées pour le calcul et DiskANN pour les instances optimisées pour le stockage.
Milvus optimise périodiquement les index vectoriels en arrière-plan. Ce processus s'achève généralement dans les 3 heures suivant l'écriture des données, après quoi le système atteint ses performances optimales.
Nombre de nœuds de calcul
Vous pouvez ajuster le nombre de nœuds de calcul (Query Nodes) de 1 à 50. Le QPS augmente linéairement avec le nombre de nœuds. Un nombre plus élevé de nœuds améliore également la disponibilité du service ; pour les environnements de production nécessitant une haute disponibilité, utilisez au moins 2 nœuds.
Analyse de scénario
Imaginons que vous construisiez un système de récupération d'images contenant 20 millions d'images. Chaque image est représentée par un vecteur à 768 dimensions. Votre objectif est de traiter 2 000 requêtes de recherche par seconde et de retourner les 100 premiers résultats en moins de 10 millisecondes. Évaluez vos options comme suit :
Évaluation de la latence : Choisissez un type de CU en fonction de vos exigences de latence. Par exemple, si vous avez besoin d'une latence inférieure à 10 millisecondes, seule la CU optimisée pour le calcul répond à ce critère.
Prise en compte de la capacité : Calculez le nombre de CU requis en fonction du volume de données et des dimensions. Une seule CU optimisée pour le calcul de 16 vCPU 64 GiB (16 CUs) peut gérer 12 millions de vecteurs à 960 dimensions. Pour accueillir 20 millions de vecteurs à 768 dimensions, configurez au moins deux de ces CU, soit un total de 32 CUs.
Validation du débit : Validez le débit de chaque nœud pour votre paramètre top-k spécifié. Par exemple, avec top-k défini sur 100, un nœud optimisé pour le calcul offre un QPS de 1 200. Pour atteindre une performance soutenue de 2 000 QPS, doublez le nombre de nœuds.
Sur la base de cette analyse, choisissez des CU optimisées pour le calcul et configurez quatre nœuds, chacun avec des spécifications de 16 vCPU 64 GiB (16 CUs).