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 for Redis Cluster, tous les niveaux et toutes les régions compatibles.
Seuls les clusters que vous créez après le 13 septembre 2024 sont compatibles avec la recherche vectorielle.
Limites de l'index
Voici 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 de HNSW ne doit pas dépasser 2 millions.
- La valeur EF Construct de HNSW ne doit pas dépasser 4 096.
- La valeur EF Runtime de HNSW ne doit pas non plus dépasser 4 096.
Impact sur les performances
Lorsque vous examinez les performances de la recherche vectorielle, vous devez tenir compte de certaines variables importantes.
Type de nœud
La recherche vectorielle facilite le scaling vertical grâce à l'intégration de pools de threads dédiés à l'exécution des opérations de recherche vectorielle. Cela signifie que les performances seront liées au nombre de processeurs virtuels sur chaque nœud de votre cluster. Pour en savoir plus sur le nombre de processeurs virtuels disponibles sur chaque type de nœud, consultez Caractéristiques des nœuds.
Nombre de segments
Memorystore for Redis Cluster 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 contenus sur ce segment. Par conséquent, la vitesse d'indexation et le nombre total de vecteurs évolueront de manière linéaire en fonction du nombre de segments dans le 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 dans chaque segment du cluster et d'agréger les résultats. Avec un nombre stable de vecteurs, l'augmentation du nombre de segments améliorera 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 seront contenus dans chaque index local.
Notez qu'en raison de l'augmentation du travail nécessaire pour rechercher dans tous les segments, la latence observable pour effectuer une requête de recherche donnée peut augmenter à mesure que des segments sont ajoutés. Malgré cela, même les plus grands clusters sont compatibles avec des latences de quelques millisecondes.
Nombre d'instances dupliquées
L'ajout d'instances dupliquées supplémentaires augmentera le débit de recherche de manière linéaire en permettant l'équilibrage de charge des requêtes de recherche sur les instances dupliquées avec accès en lecture.
Événements de scaling
Lorsque vous redimensionnez votre cluster Redis, les documents de vos index sont déplacés pour distribuer 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 scaling terminée, vous pouvez surveiller la valeur de
mutation_queue_size dans la sortie FT.INFO
pour voir la progression de la réindexation due au redimensionnement de votre cluster.
Consommation de mémoire
Les vecteurs sont dupliqués et stockés à la fois dans l'espace de clés Redis 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.