Cette page fournit des informations sur les fonctionnalités et les limites de la recherche vectorielle.
Disponibilité
La recherche vectorielle est disponible sur toutes les versions de Memorystore pour Valkey, quel que soit le niveau et la région.
Seules les instances créées après la date de lancement du 13 septembre 2024 ont la recherche vectorielle activée.
Restrictions d'index
Vous trouverez ci-dessous les limites de l'index:
- Le nombre maximal d'attributs dans un index ne peut pas dépasser 10.
- La dimension d'un vecteur ne peut pas dépasser 32 768.
- La valeur M pour HNSW ne doit pas dépasser 2 millions.
- La valeur EF Construct pour HNSW ne doit pas dépasser 4 096.
- La valeur de l'environnement d'exécution EF pour HNSW ne doit pas non plus dépasser 4 096.
Impact sur les performances
Plusieurs variables importantes sont à prendre en compte pour évaluer les performances de la recherche vectorielle.
Type de nœud
La recherche vectorielle facilite la mise à l'échelle verticale grâce à l'intégration de pools de threads dédiés à l'exécution d'opérations de recherche vectorielle. Cela signifie que les performances seront liées au nombre de vCPU sur chaque nœud de votre cluster. Pour en savoir plus sur le nombre de vCPU disponibles pour chaque type de nœud, consultez la section Spécifications du cluster et des nœuds.
Nombre de partitions
Memorystore pour Valkey implémente une technique d'indexation locale pour tous les vecteurs. Cela signifie que l'index stocké sur chaque segment ne contient que les documents de ce segment. Par conséquent, la vitesse d'indexation et le nombre total de vecteurs évolueront de manière linéaire avec le nombre de segments du cluster.
Étant donné que chaque index local ne contient que le contenu d'un seul segment, la recherche dans le cluster nécessite de rechercher chaque segment du cluster et d'agréger les résultats. Avec un nombre de vecteurs stable, augmenter le nombre de fragments améliore les performances de recherche de manière logarithmique pour les index HNSW et de manière linéaire pour les index FLAT, car moins de vecteurs sont contenus dans chaque index local.
Notez qu'en raison de l'augmentation de la quantité de travail nécessaire pour rechercher tous les fragments, la latence observable pour effectuer une requête de recherche donnée peut augmenter à mesure que des fragments sont ajoutés. Malgré cela, même les plus grands clusters acceptent des latences de l'ordre de quelques millisecondes.
Nombre d'instances dupliquées
L'ajout de réplicas supplémentaires augmente le débit de recherche de manière linéaire en permettant l'équilibrage de la charge des requêtes de recherche sur les réplicas de lecture.
Événements de mise à l'échelle
Lorsque vous redimensionnez votre instance Memorystore pour Firebase Key, les documents de vos index sont déplacés pour répartir uniformément les données sur le nouveau nombre de segments. Dans ce cas, les documents déplacés entre les nœuds sont indexés en arrière-plan. Une fois l'opération de mise à l'échelle terminée, vous pouvez surveiller la valeur de mutation_queue_size dans la sortie FT.INFO pour voir la progression de l'indexation en raison du redimensionnement de votre cluster.
Consommation de mémoire
Les vecteurs sont dupliqués et stockés à la fois dans l'espace de clés et dans l'algorithme de recherche vectorielle.
Transactions
En raison de la nature asynchrone de l'exécution des tâches par les pools de threads, les opérations de recherche vectorielle ne respectent pas la sémantique transactionnelle.