Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Présentation de la recherche vectorielle
ElastiCache for Valkey fournit des fonctionnalités permettant d'indexer, de rechercher et de mettre à jour des milliards d'intégrations vectorielles de grande dimension. La recherche vectorielle vous permet de créer, de gérer et d'utiliser des index secondaires pour une recherche efficace et évolutive. Chaque opération de recherche vectorielle s'applique à un seul index. Les opérations d'indexation s'appliquent uniquement à l'index spécifié. Un certain nombre d'opérations peuvent être effectuées sur n'importe quel index à tout moment, à l'exception des opérations de création et de suppression d'index. Au niveau du cluster, plusieurs opérations portant sur plusieurs index peuvent être en cours simultanément.
Dans ce document, les termes clé, ligne et enregistrement sont identiques et utilisés de manière interchangeable. De même, les termes colonne, champ, chemin et membre sont également utilisés de manière interchangeable.
La FT.CREATE commande peut être utilisée pour créer un index pour un sous-ensemble de clés avec les types d'index spécifiés. FT.SEARCHexécute des requêtes sur les index créés et FT.DROPINDEX supprime un index existant ainsi que toutes les données associées. Il n'existe aucune commande spéciale pour ajouter, supprimer ou modifier des données indexées. Les JSON commandes existantes HASH ou qui modifient une clé figurant dans un index mettent automatiquement à jour l'index.
Rubriques
Les index et le keyspace Valkey OSS
Les index sont construits et gérés sur un sous-ensemble de l'espace de touches Valkey OSS. L'espace-clé de chaque index est défini par une liste de préfixes clés fournis lors de la création de l'index. La liste des préfixes est facultative et si elle est omise, l'espace clé entier fera partie de cet index. Plusieurs index peuvent choisir des sous-ensembles disjoints ou superposés de l'espace-clé sans limitation.
Les index sont également saisis dans la mesure où ils ne couvrent que les clés dont le type correspond. Actuellement, les index ne sont pris en charge que sur les HASH types JSON et. Un HASH index indexe uniquement les HASH clés couvertes par sa liste de préfixes. De même, un JSON index indexe uniquement les JSON clés couvertes par sa liste de préfixes. Les clés de la liste de préfixes d'espaces de touches d'un index qui n'ont pas le type désigné sont ignorées et n'affectent pas les opérations de recherche.
Un index est mis à jour lorsqu'une commande modifie une touche située dans l'espace-clé de l'index. Valkey extrait automatiquement les champs déclarés pour chaque index et met à jour l'index avec la nouvelle valeur. Le processus de mise à jour comporte trois étapes. Dans un premier temps, la clé HASH ou JSON est modifiée et le client demandeur est bloqué. La deuxième étape est exécutée en arrière-plan et met à jour chacun des index contenant la clé modifiée. Dans la troisième étape, le client est débloqué. Ainsi, pour les opérations de requête effectuées sur la même connexion qu'une mutation, cette modification est immédiatement visible dans les résultats de recherche.
La création d'un index est un processus en plusieurs étapes. La première étape consiste à exécuter la commande FT.CREATE qui définit l'index. L'exécution réussie d'une création initie automatiquement la deuxième étape : le remblayage. Le processus de remplissage s'exécute dans un fil d'arrière-plan et analyse l'espace des touches à la recherche de clés figurant dans la liste de préfixes du nouvel index. Chaque clé trouvée est ajoutée à l'index. Finalement, l'espace clé entier est scanné, complétant ainsi le processus de création de l'index. Notez que lorsque le processus de remplissage des index est en cours d'exécution, les mutations des clés indexées sont autorisées, il n'y a aucune restriction et le processus de remplissage de l'index ne sera pas terminé tant que toutes les clés ne seront pas correctement indexées. Les opérations de requête tentées alors qu'un index est en cours de remblayage ne sont pas autorisées et se terminent par une erreur. La commande FT.INFO renvoie l'état du processus de remblayage dans le champ « backfill_status ».
Types de champs d'index
Chaque index possède un type spécifique déclaré lors de la création de l'index, ainsi que l'emplacement d'un champ (colonne) à indexer. Pour HASH les clés, l'emplacement est le nom du champ dans leHASH. Pour JSON les clés, l'emplacement est une description du chemin JSON. Lorsqu'une clé est modifiée, les données associées aux champs déclarés sont extraites, converties dans le type déclaré et stockées dans l'index. Si les données sont manquantes ou ne peuvent pas être converties correctement dans le type déclaré, ce champ est omis de l'index. Il existe trois types de champs, comme expliqué ci-dessous :
-
Les champs vectoriels contiennent un vecteur de nombres, également connu sous le nom d'intégration vectorielle. Les champs vectoriels peuvent être utilisés pour filtrer les vecteurs en fonction de mesures de distance spécifiées qui mesurent la similitude. Pour les
HASHindex, le champ doit contenir le vecteur entier codé au format binaire (little-endian IEEE 754). PourJSONles clés, le chemin doit faire référence à un tableau de la bonne taille rempli de chiffres. Notez que lorsqu'un tableau JSON est utilisé comme champ vectoriel, la représentation interne du tableau dans la clé JSON est convertie dans le format requis par l'algorithme sélectionné, ce qui réduit la consommation de mémoire et la précision. Les opérations de lecture ultérieures à l'aide des commandes JSON produiront la valeur de précision réduite. -
Les champs numériques contiennent un seul chiffre. Les champs numériques peuvent être utilisés avec l'opérateur de recherche par plage. En
HASHeffet, le champ est censé contenir le texte ASCII d'un nombre écrit dans le format standard des nombres à virgule fixe ou flottante. PourJSONles champs, les règles numériques des numéros JSON doivent être respectées. Quelle que soit la représentation dans la clé, ce champ est converti en un nombre à virgule flottante de 64 bits pour être stocké dans l'index. Les nombres sous-jacents étant stockés en virgule flottante avec ses limites de précision, les règles habituelles relatives aux comparaisons numériques pour les nombres à virgule flottante s'appliquent. -
Les champs de balises contiennent zéro ou plusieurs valeurs de balise codées sous la forme d'une seule chaîne UTF-8. Les champs de balises peuvent être utilisés pour filtrer les requêtes relatives à l'équivalence des valeurs de balises par une comparaison entre majuscules et minuscules. La chaîne est analysée en valeurs de balise à l'aide d'un caractère séparateur (la valeur par défaut est une virgule mais peut être remplacée), les espaces blancs de début et de fin étant supprimés. Un seul champ de balise peut contenir autant de valeurs de balise que vous le souhaitez.
Algorithmes d'index vectoriel
Deux algorithmes d'index vectoriel sont pris en charge dans Valkey :
-
Plat — L'algorithme Flat est un traitement linéaire par force brute de chaque vecteur de l'indice, fournissant des réponses exactes dans les limites de précision des calculs de distance. En raison du traitement linéaire de l'indice, les temps d'exécution de cet algorithme peuvent être très élevés pour les grands indices. Les index plats favorisent des vitesses d'ingestion plus élevées.
-
Petits mondes navigables hiérarchiques (HNSW) — L'algorithme HNSW est une alternative qui fournit les correspondances vectorielles les plus proches approximatives en échange de temps d'exécution nettement plus courts. L'algorithme est contrôlé par trois paramètres
M,EF_CONSTRUCTIONetEF_RUNTIME. Les deux premiers paramètres sont spécifiés au moment de la création de l'index et ne peuvent pas être modifiés. LeEF_RUNTIMEparamètre possède une valeur par défaut qui est spécifiée lors de la création de l'index, mais qui peut ensuite être remplacée lors de n'importe quelle opération de requête individuelle. Ces trois paramètres interagissent pour équilibrer la consommation de mémoire et de processeur lors des opérations d'ingestion et de requête, ainsi que pour contrôler la qualité de l'approximation d'une recherche KNN exacte (connue sous le nom de ratio de rappel).
Dans HNSW, le paramètre M contrôle le nombre maximum de voisins auxquels chaque nœud peut se connecter, façonnant ainsi la densité de l'indice. Un M plus élevé, tel que 32 ou plus, produit un graphe plus connecté, ce qui améliore la vitesse de rappel et de requête, car il existe davantage de chemins pour atteindre les voisins pertinents. Cependant, cela augmente la taille de l'index, l'utilisation de la mémoire et ralentit l'indexation. Un M inférieur, tel que 8 ou moins, produit un faster-to-build index plus petit avec une utilisation de mémoire plus faible, mais les rappels diminuent et les requêtes peuvent prendre plus de temps en raison du nombre réduit de connexions.
Le paramètre EF_Construction indique le nombre de connexions candidates à évaluer lors de la création de l'index. Un EF_Construction plus élevé, tel que 400 ou plus, signifie que l'indexeur prend en compte davantage de chemins avant de sélectionner des voisins, ce qui permet d'obtenir un graphique qui améliore à la fois le rappel et l'efficacité des requêtes par la suite, mais au prix d'une indexation plus lente et d'une utilisation accrue du processeur et de la mémoire pendant la construction. Un EF_Construction faible, tel que 64-120, accélère l'indexation et réduit l'utilisation des ressources, mais le graphe qui en résulte peut réduire les rappels et ralentir les requêtes même si EF_Runtime est défini sur un niveau élevé.
Enfin, EF_Runtime régit l'étendue de la recherche lors de l'interrogation, en contrôlant le nombre de voisins candidats explorés lors de l'exécution. Une valeur élevée augmente le rappel et la précision, mais au détriment de la latence des requêtes et de l'utilisation du processeur. Un EF_Runtime faible rend les requêtes plus rapides et plus légères, mais avec un rappel réduit. Contrairement à M ou EF_Construction, ce paramètre n'affecte pas la taille de l'index ni le temps de création, ce qui en fait le paramètre permettant d'ajuster les compromis entre rappel et latence après la création d'un index.
Les deux algorithmes de recherche vectorielle (Flat et HNSW) prennent en charge un INITIAL_CAP paramètre facultatif. Lorsqu'il est spécifié, ce paramètre préalloue de la mémoire aux index, ce qui permet de réduire la charge de gestion de la mémoire et d'augmenter les taux d'ingestion de vecteurs. Les indices plats permettent de meilleures vitesses d'ingestion que le HNSW.
Les algorithmes de recherche vectorielle tels que HNSW peuvent ne pas gérer efficacement la suppression ou le remplacement de vecteurs précédemment insérés. L'utilisation de ces opérations peut entraîner une consommation excessive de mémoire d'index et une and/or dégradation de la qualité du rappel. La réindexation est une méthode permettant de rétablir un rappel optimal de l'utilisation and/or de la mémoire.
Sécurité de la recherche vectorielle
Les mécanismes de sécurité Valkey ACL (Access Control Lists)@search,, est fournie et de nombreuses catégories existantes (@fast,, @read@write, etc.) sont mises à jour pour inclure les nouvelles commandes. Les commandes de recherche ne modifient pas les données clés, ce qui signifie que le mécanisme ACL existant pour l'accès en écriture est préservé. Les règles d'accès HASH et les JSON opérations ne sont pas modifiées par la présence d'un index ; le contrôle d'accès normal au niveau des clés est toujours appliqué à ces commandes.
L'accès aux commandes de recherche avec index est également contrôlé via ACL. Les contrôles d'accès sont effectués au niveau de l'index complet, et non au niveau de chaque clé. Cela signifie que l'accès à un index n'est accordé à un utilisateur que s'il est autorisé à accéder à toutes les clés possibles dans la liste des préfixes d'espace-touches de cet index. En d'autres termes, le contenu réel d'un index ne contrôle pas l'accès. C'est plutôt le contenu théorique d'un index tel que défini par la liste de préfixes qui est utilisé pour le contrôle de sécurité. Il est possible qu'un utilisateur dispose d'un accès en lecture et en and/or écriture à une clé mais ne puisse pas accéder à un index contenant cette clé. Notez que seul un accès en lecture à l'espace de touches est requis pour créer ou utiliser un index ; la présence ou l'absence d'accès en écriture n'est pas prise en compte.
