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 Redis Cluster, dans tous les niveaux et dans toutes les régions compatibles.
Seules les instances créées après la date de lancement du 13 septembre 2024 sont compatibles avec la recherche vectorielle.
Restrictions concernant 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 pour HNSW ne doit pas dépasser 2M.
- La valeur EF Construct pour HNSW ne doit pas dépasser 4096.
- La valeur EF Runtime pour HNSW ne doit pas non plus dépasser 4 096.
Impact sur les performances
Lorsque vous évaluez les performances de la recherche vectorielle, vous devez tenir compte de plusieurs 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 Spécifications des clusters et des nœuds.
Nombre de partitions
Memorystore for Redis Cluster implémente une technique d'indexation locale pour tous les vecteurs. Cela signifie que l'index stocké sur chaque partition ne contient que les documents présents sur cette partition. 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 shard, la recherche dans le cluster nécessite de rechercher chaque shard du cluster et d'agréger les résultats. Avec un nombre stable de vecteurs, l'augmentation du nombre de partitions 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 chaque index local contiendra moins de vecteurs.
Notez qu'en raison de la quantité de travail accrue nécessaire pour rechercher tous les fragments, la latence observable pour exécuter une requête de recherche donnée peut augmenter à mesure que des fragments sont ajoutés. Malgré cela, même les plus grands clusters sont compatibles avec des latences de l'ordre 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 vers 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 répartir uniformément les données sur le nouveau nombre de partitions. Dans ce cas, les documents déplacés d'un nœud à un autre seront 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 suivre 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.