FAQ sur les produits

Combien coûte Milvus ?

Milvus est un projet open-source 100% gratuit.

Veuillez respecter la licence Apache 2.0 lorsque vous utilisez Milvus à des fins de production ou de distribution.

Zilliz, la société à l'origine de Milvus, propose également une version cloud entièrement gérée de la plateforme pour ceux qui ne souhaitent pas construire et maintenir leur propre instance distribuée. Zilliz Cloud maintient automatiquement la fiabilité des données et permet aux utilisateurs de ne payer que pour ce qu'ils utilisent.

Milvus prend-il en charge les architectures non-x86 ?

Milvus ne peut pas être installé ou exécuté sur des plates-formes non-x86.

Votre processeur doit prendre en charge l'un des jeux d'instructions suivants pour exécuter Milvus : SSE4.2, AVX, AVX2, AVX512. Il s'agit de jeux d'instructions SIMD dédiés à l'architecture x86.

Où Milvus stocke-t-il les données ?

Milvus traite deux types de données : les données insérées et les métadonnées.

Les données insérées, y compris les données vectorielles, les données scalaires et le schéma spécifique à la collection, sont stockées dans un stockage persistant sous forme de journal incrémentiel. Milvus prend en charge plusieurs backends de stockage d'objets, notamment MinIO, AWS S3, Google Cloud Storage (GCS), Azure Blob Storage, Alibaba Cloud OSS et Tencent Cloud Object Storage (COS).

Les métadonnées sont générées au sein de Milvus. Chaque module Milvus a ses propres métadonnées qui sont stockées dans etcd.

Pourquoi n'y a-t-il pas de données vectorielles dans etcd ?

etcd stocke les métadonnées des modules Milvus ; MinIO stocke les entités.

Milvus prend-il en charge l'insertion et la recherche de données simultanément ?

Oui. Les opérations d'insertion et les opérations de recherche sont gérées par deux modules distincts qui sont mutuellement indépendants. Du point de vue du client, une opération d'insertion est terminée lorsque les données insérées entrent dans la file d'attente des messages. Cependant, les données insérées ne sont pas consultables tant qu'elles ne sont pas chargées dans le nœud d'interrogation. Si la taille du segment n'atteint pas le seuil de construction de l'index (512 Mo par défaut), Milvus a recours à la recherche par force brute et les performances de la requête peuvent être réduites.

Les vecteurs dont les clés primaires sont dupliquées peuvent-ils être insérés dans Milvus ?

Oui. Milvus ne vérifie pas si les clés primaires des vecteurs sont dupliquées.

Lorsque des vecteurs avec des clés primaires dupliquées sont insérés, Milvus les traite-t-il comme une opération de mise à jour ?

Non. Milvus ne prend pas actuellement en charge les opérations de mise à jour et ne vérifie pas si les clés primaires des entités sont dupliquées. Il vous incombe de vous assurer que les clés primaires des entités sont uniques et, si ce n'est pas le cas, Milvus peut contenir plusieurs entités avec des clés primaires dupliquées.

Dans ce cas, la copie de données qui sera renvoyée lors d'une requête reste un comportement inconnu. Cette limitation sera corrigée dans les prochaines versions.

Quelle est la longueur maximale des clés primaires d'entité auto-définies ?

Les clés primaires des entités doivent être des nombres entiers non négatifs de 64 bits.

Quelle est la quantité maximale de données pouvant être ajoutées par opération d'insertion ?

La taille d'une opération d'insertion ne doit pas dépasser 1 024 Mo. Il s'agit d'une limite imposée par gRPC.

La taille de la collection a-t-elle un impact sur les performances de la requête lors d'une recherche dans une partition spécifique ?

Non. Si des partitions sont spécifiées pour une recherche, Milvus recherche uniquement dans les partitions spécifiées.

Milvus doit-il charger l'ensemble de la collection lorsque des partitions sont spécifiées pour une recherche ?

Cela dépend des données nécessaires à la recherche. Toutes les partitions susceptibles d'apparaître dans les résultats de la recherche doivent être chargées avant la recherche.

• Par exemple, si vous ne souhaitez rechercher qu'une ou plusieurs partitions spécifiques, il n'est pas nécessaire de charger toutes les partitions. Appelez load_partition() pour charger la ou les partition(s) voulue(s) , puis spécifiez la ou les partition(s) dans l'appel de la méthode search().
• Si vous souhaitez rechercher toutes les partitions, appelez load_collection() pour charger l'ensemble de la collection, y compris toutes les partitions.
• Si vous ne chargez pas la collection ou une ou plusieurs partitions spécifiques avant d'effectuer la recherche, Milvus renvoie une erreur.

Peut-on créer des index après avoir inséré des vecteurs ?

Oui. Si un index a été construit pour une collection par create_index() auparavant, Milvus construira automatiquement un index pour les vecteurs insérés ultérieurement. Toutefois, Milvus ne construit pas d'index tant que les vecteurs nouvellement insérés ne remplissent pas un segment entier et que le fichier d'index nouvellement créé n'est pas séparé du précédent.

En quoi les index FLAT et IVF_FLAT sont-ils différents ?

L'index IVF_FLAT divise l'espace vectoriel en groupes de listes. Avec la valeur de liste par défaut de 16 384, Milvus compare les distances entre le vecteur cible et les centroïdes de tous les 16 384 clusters pour renvoyer les clusters les plus proches de la sonde. Milvus compare ensuite les distances entre le vecteur cible et les vecteurs des grappes sélectionnées pour obtenir les vecteurs les plus proches. Contrairement à IVF_FLAT, FLAT compare directement les distances entre le vecteur cible et tous les autres vecteurs.

Lorsque le nombre total de vecteurs est approximativement égal à nlist, il y a peu de différence entre IVF_FLAT et FLAT en termes d'exigences de calcul et de performances de recherche. Toutefois, lorsque le nombre de vecteurs dépasse nlist d'un facteur de deux ou plus, IVF_FLAT commence à présenter des avantages en termes de performances.

Voir Index des vecteurs pour plus d'informations.

Comment Milvus extrait-il les données ?

Milvus renvoie un succès lorsque les données insérées sont ingérées dans la file d'attente des messages. Toutefois, les données ne sont pas encore transférées sur le disque. Le nœud de données de Milvus écrit alors les données de la file d'attente de messages dans le stockage persistant sous forme de journaux incrémentiels. Si flush() est appelé, le nœud de données est forcé d'écrire immédiatement toutes les données de la file d'attente des messages dans le stockage permanent.

Qu'est-ce que la normalisation ? Pourquoi la normalisation est-elle nécessaire ?

La normalisation est le processus de conversion d'un vecteur de sorte que sa norme soit égale à 1. Si le produit intérieur est utilisé pour calculer la similarité vectorielle, les vecteurs doivent être normalisés. Après normalisation, le produit intérieur est égal à la similarité en cosinus.

Voir Wikipedia pour plus d'informations.

Pourquoi la distance euclidienne (L2) et le produit intérieur (PI) donnent-ils des résultats différents ?

Pour les vecteurs normalisés, la distance euclidienne (L2) est mathématiquement équivalente au produit intérieur (PI). Si ces mesures de similarité donnent des résultats différents, vérifiez si vos vecteurs sont normalisés.

Y a-t-il une limite au nombre total de collections et de partitions dans Milvus ?

Oui. Vous pouvez créer jusqu'à 65 535 collections dans une instance Milvus. Lors du calcul du nombre de collections existantes, Milvus prend en compte toutes les collections contenant des tessons et des partitions.

Par exemple, supposons que vous ayez déjà créé 100 collections, avec 2 shards et 4 partitions dans 60 d'entre elles et avec 1 shard et 12 partitions dans les 40 collections restantes. Le nombre actuel de collections peut être calculé comme suit :

60 * 2 * 4 + 40 * 1 * 12 = 960

Pourquoi est-ce que j'obtiens moins de k vecteurs lorsque je cherche topk vecteurs ?

Parmi les index pris en charge par Milvus, IVF_FLAT et IVF_SQ8 mettent en œuvre la méthode de regroupement k-means. Un espace de données est divisé en nlist clusters et les vecteurs insérés sont distribués dans ces clusters. Milvus sélectionne ensuite les nprobe grappes les plus proches et compare les distances entre le vecteur cible et tous les vecteurs dans les grappes sélectionnées pour renvoyer les résultats finaux.

Si nlist et topk sont grands et que nprobe est petit, le nombre de vecteurs dans les grappes nprobe peut être inférieur à k. Par conséquent, lorsque vous recherchez les vecteurs les plus proches topk, le nombre de vecteurs renvoyés est inférieur à k.

Pour éviter cela, essayez d'augmenter nprobe et de réduire nlist et k.

Voir Index des vecteurs pour plus d'informations.

Quelle est la dimension vectorielle maximale prise en charge par Milvus ?

Milvus peut gérer des vecteurs ayant jusqu'à 32 768 dimensions par défaut. Vous pouvez augmenter la valeur de Proxy.maxDimension pour permettre un vecteur de plus grande dimension.

Milvus prend-il en charge le processeur Apple M1 ?

La version actuelle de Milvus ne prend pas directement en charge le processeur Apple M1. Après Milvus 2.3, Milvus fournit des images Docker pour l'architecture ARM64.

Quels types de données Milvus prend-il en charge dans le champ de clé primaire ?

Dans la version actuelle, Milvus prend en charge à la fois INT64 et les chaînes de caractères.

Milvus est-il évolutif ?

Oui. Vous pouvez déployer le cluster Milvus avec plusieurs nœuds via Helm Chart sur Kubernetes. Reportez-vous au Guide de mise à l'échelle pour plus d'instructions.

Qu'est-ce qu'un segment croissant et un segment scellé ?

Lorsqu'une demande de recherche arrive, Milvus recherche à la fois des données incrémentielles et des données historiques. Les données incrémentielles sont des mises à jour récentes, elles sont stockées dans les segments croissants, qui sont mis en mémoire tampon avant d'atteindre le seuil de persistance dans le stockage d'objets et un index plus efficace est construit pour elles, tandis que les données historiques sont des mises à jour qui datent d'il y a un certain temps. Elles se trouvent dans les segments scellés qui ont été conservés dans le stockage d'objets. Les données incrémentielles et les données historiques constituent ensemble l'ensemble des données à rechercher. Grâce à cette conception, toutes les données intégrées à Milvus peuvent être recherchées instantanément. Pour Milvus Distribué, il existe des facteurs plus complexes qui déterminent quand un enregistrement qui vient d'être ingéré peut apparaître dans les résultats de recherche. Pour en savoir plus, consultez les niveaux de cohérence.

Milvus est-il disponible pour la recherche simultanée ?

Oui. Pour les requêtes sur la même collection, Milvus recherche simultanément les données incrémentielles et historiques. Toutefois, les requêtes sur différentes collections sont effectuées en série. Alors que les données historiques peuvent constituer un ensemble de données extrêmement volumineux, les recherches sur les données historiques prennent relativement plus de temps et sont essentiellement effectuées en série.

Pourquoi les données de MinIO sont-elles conservées après l'abandon de la collection correspondante ?

Les données dans MinIO sont conçues pour rester pendant un certain temps afin de faciliter le retour en arrière des données.

Milvus prend-il en charge des moteurs de messages autres que Pulsar ?

Oui. Kafka est pris en charge dans Milvus 2.1.0.

Quelle est la différence entre une recherche et une requête ?

Dans Milvus, une recherche de similarité vectorielle récupère des vecteurs sur la base du calcul de similarité et de l'accélération de l'index vectoriel. Contrairement à une recherche de similarité vectorielle, une requête vectorielle récupère des vecteurs via un filtrage scalaire basé sur une expression booléenne. L'expression booléenne filtre les champs scalaires ou le champ de clé primaire, et récupère tous les résultats qui correspondent aux filtres. Dans une requête, ni la métrique de similarité ni l'index vectoriel ne sont impliqués.

Pourquoi une valeur vectorielle flottante a-t-elle une précision de 7 chiffres après la virgule dans Milvus ?

Milvus prend en charge le stockage des vecteurs en tant que tableaux Float32. Une valeur Float32 a une précision de 7 chiffres après la virgule. Même avec une valeur Float64, telle que 1.3476964684980388, Milvus la stocke sous la forme 1.347696. Par conséquent, lorsque vous récupérez un tel vecteur dans Milvus, la précision de la valeur Float64 est perdue.

Comment Milvus gère-t-il les types de données vectorielles et la précision ?

Milvus prend en charge les types de vecteurs Binary, Float32, Float16 et BFloat16.

• Vecteurs binaires : Stockent des données binaires sous forme de séquences de 0 et de 1. Ils sont utilisés dans le traitement des images et la recherche d'informations.
• Vecteurs de type Float32 : Stockage par défaut avec une précision d'environ 7 chiffres après la virgule. Même les valeurs Float64 sont stockées avec une précision Float32, ce qui peut entraîner une perte de précision lors de la recherche.
• Vecteurs Float16 et BFloat16 : Ils offrent une précision et une utilisation de la mémoire réduites. Float16 convient aux applications dont la bande passante et le stockage sont limités, tandis que BFloat16 équilibre la portée et l'efficacité, couramment utilisé dans l'apprentissage profond pour réduire les exigences de calcul sans avoir d'impact significatif sur la précision.

Milvus prend-il en charge la spécification de valeurs par défaut pour les champs scalaires ou vectoriels ?

Actuellement, Milvus 2.4.x ne prend pas en charge la spécification de valeurs par défaut pour les champs scalaires ou vectoriels. Cette fonctionnalité est prévue pour les prochaines versions.

L'espace de stockage est-il libéré immédiatement après la suppression des données dans Milvus ?

Non, l'espace de stockage n'est pas immédiatement libéré lorsque vous supprimez des données dans Milvus. Bien que la suppression de données marque les entités comme "logiquement supprimées", l'espace réel peut ne pas être libéré instantanément. Voici pourquoi :

• Compactage: Milvus compacte automatiquement les données en arrière-plan. Ce processus fusionne des segments de données plus petits en segments plus grands et supprime les données supprimées logiquement (entités marquées pour la suppression) ou les données qui ont dépassé leur durée de vie (TTL). Cependant, le compactage crée de nouveaux segments tout en marquant les anciens comme "abandonnés".
• Collecte des déchets: Un processus distinct appelé Garbage Collection (GC) supprime périodiquement ces segments "abandonnés", libérant ainsi l'espace de stockage qu'ils occupaient. Cela garantit une utilisation efficace de l'espace de stockage, mais peut entraîner un léger délai entre la suppression et la récupération de l'espace.

Puis-je voir les données insérées, supprimées ou réinsérées immédiatement après l'opération, sans attendre la vidange ?

Oui, dans Milvus, la visibilité des données n'est pas directement liée aux opérations de vidage en raison de son architecture de désagrégation du stockage et du calcul. Vous pouvez gérer la lisibilité des données à l'aide des niveaux de cohérence.

Lors de la sélection d'un niveau de cohérence, tenez compte des compromis entre la cohérence et les performances. Pour les opérations nécessitant une visibilité immédiate, utilisez un niveau de cohérence "fort". Pour des écritures plus rapides, donnez la priorité à une cohérence plus faible (les données peuvent ne pas être immédiatement visibles). Pour plus d'informations, reportez-vous à la section Cohérence.

Après avoir activé la fonction de clé de partition, quelle est la valeur par défaut de num_partitions dans Milvus, et pourquoi ?

Lorsque la fonction de clé de partition est activée, la valeur par défaut de num_partitions dans Milvus est définie sur 16. Cette valeur par défaut est choisie pour des raisons de stabilité et de performances. Vous pouvez ajuster la valeur de num_partitions selon vos besoins en la spécifiant dans la fonction create_collection.

Existe-t-il une limite de longueur maximale pour les expressions de filtrage scalaire ?

Oui, la longueur maximale d'une expression de filtrage scalaire est limitée par la limite de transfert RPC, qui est définie dans le fichier de configuration milvus.yaml. Plus précisément, la limite est fixée par le paramètre serverMaxRecvSize dans la section proxy :

proxy:
  grpc:
    serverMaxRecvSize: 67108864 # The maximum size of each RPC request that the proxy can receive, unit: byte

Par défaut, la taille maximale de chaque requête RPC est de 64 Mo. Par conséquent, la longueur de l'expression de filtrage doit être inférieure à cette limite pour garantir un traitement réussi.

Lors d'une recherche de vecteurs en masse, combien de vecteurs peuvent être spécifiés à la fois ? Y a-t-il une limite ?

Oui, le nombre de vecteurs qui peuvent être spécifiés dans une recherche de vecteurs en bloc est limité par la taille du transfert RPC, telle qu'elle est définie dans le fichier de configuration milvus.yaml. Cette limite est déterminée par le paramètre serverMaxRecvSize dans la section proxy :

proxy:
  grpc:
    serverMaxRecvSize: 67108864 # The maximum size of each RPC request that the proxy can receive, unit: byte

Par défaut, la taille maximale de chaque requête RPC est de 64 Mo. Par conséquent, la taille totale des vecteurs d'entrée, y compris leurs données dimensionnelles et leurs métadonnées, doit être inférieure à cette limite pour garantir une exécution réussie.

Vous avez encore des questions ?

Vous pouvez le faire :

• Consulter Milvus sur GitHub. Vous pouvez poser des questions, partager des idées et aider les autres.
• Rejoignez notre communauté Slack pour trouver de l'aide et vous engager avec notre communauté open-source.