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.

Aperçu de la recherche vectorielle

La recherche vectorielle repose sur la création, la maintenance et l'utilisation d'index. Chaque opération de recherche vectorielle spécifie un seul index et son opération est limitée à cet index, c'est-à-dire que les opérations sur un index ne sont pas affectées par les opérations sur un autre index. À l'exception des opérations de création et de destruction d'index, un certain nombre d'opérations peuvent être effectuées sur n'importe quel index à tout moment, ce qui signifie qu'au niveau du cluster, plusieurs opérations sur plusieurs index peuvent être en cours simultanément.

Les index individuels sont des objets nommés qui existent dans un espace de noms unique, distinct des autres OSS espaces de noms Valkey et Redis : clés, fonctions, etc. Chaque index est conceptuellement similaire à une table de base de données classique dans la mesure où il est structuré en deux dimensions : colonne et lignes. Chaque ligne du tableau correspond à une clé. Chaque colonne de l'index correspond à un membre ou à une partie de cette clé. 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 essentiellement identiques et sont également utilisés de manière interchangeable.

Il n'existe aucune commande spéciale pour ajouter, supprimer ou modifier des données indexées. Au contraire, JSON les commandes existantes HASH ou qui modifient une clé figurant dans un index mettent également automatiquement à jour l'index.

Les index et le keyspace Valkey et Redis OSS

Les index sont construits et gérés sur un sous-ensemble de l'espace de touches Valkey et Redis. OSS Plusieurs index peuvent choisir des sous-ensembles disjoints ou superposés de l'espace-clé sans limitation. 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. Les index sont également saisis dans la mesure où ils ne couvrent que les clés dont le type correspond. Actuellement, seuls JSON les HASH index sont pris en charge. 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.

Lorsqu'une JSON commande HASH ou modifie une touche qui se trouve dans un espace clé d'un index, cet index est mis à jour. Ce processus consiste à extraire les champs déclarés pour chaque index et à mettre à jour l'index avec la nouvelle valeur. Le processus de mise à jour est effectué dans un fil de discussion en arrière-plan, ce qui signifie que les index ne sont cohérents qu'en fin de compte avec leur contenu keyspace. Ainsi, l'insertion ou la mise à jour d'une clé ne sera pas visible dans les résultats de recherche pendant une courte période. Pendant les périodes de forte charge du système et/ou de forte mutation des données, le délai de visibilité peut s'allonger.

La création d'un index est un processus en plusieurs étapes. La première étape consiste à exécuter le FT. CREATEcommande 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 d'index est en cours d'exécution, les mutations de clés indexées sont autorisées, il n'y a aucune restriction et le processus de remplissage d'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. L'achèvement du processus de remblayage peut être déterminé à partir de la sortie de la FT.INFO commande pour cet index ('backfill_status').

Types de champs d'index

Chaque champ (colonne) d'un index possède un type spécifique déclaré lors de la création de l'index et un emplacement dans une clé. 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 JSON chemin. 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 quatre types de champs, comme expliqué ci-dessous :

Algorithmes d'index vectoriel

Deux algorithmes d'index vectoriel sont fournis :

Les deux algorithmes de recherche vectorielle (Flat etHNSW) 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 algorithmes de recherche vectorielle tels que ceux-ci 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 un and/or degraded recall quality. Reindexing is one method for restoring optimal memory usage and/or rappel d'une consommation excessive de mémoire d'index.

Expression de requête de recherche vectorielle

Le FT. SEARCHet FT. AGGREGATEles commandes nécessitent une expression de requête. Cette expression est un paramètre de chaîne unique composé d'un ou de plusieurs opérateurs. Chaque opérateur utilise un champ de l'index pour identifier un sous-ensemble des clés de l'index. Plusieurs opérateurs peuvent être combinés à l'aide de combineurs booléens ainsi que de parenthèses pour améliorer ou restreindre davantage le jeu de clés collecté (ou le jeu de résultats).

Caractère générique

L'opérateur générique, l'astérisque (« * »), correspond à toutes les clés de l'index.

Plage numérique

La syntaxe de l'opérateur de plage numérique est la suivante :

<range-search> ::= '@' <numeric-field-name> ':' '[' <bound> <bound> ']'
<bound>  ::= <number> | '(' <number>
<number> ::= <integer> | <fixed-point> | <floating-point> | 'Inf' | '-Inf' | '+Inf'

Le < numeric-field-name > doit être un champ de type déclaréNUMERIC. Par défaut, la borne est inclusive, mais une parenthèse ouverte initiale ['('] peut être utilisée pour rendre une borne exclusive. La recherche par plage peut être convertie en une comparaison relationnelle unique (<, <=, >, >=) en utilisant Inf +Inf ou -Inf comme l'une des limites. Quel que soit le format numérique spécifié (entier, virgule fixe, virgule flottante, infini), le nombre est converti en virgule flottante de 64 bits pour effectuer des comparaisons, réduisant ainsi la précision en conséquence.

@numeric-field:[0 10]                      // 0   <= <value> <= 10
@numeric-field:[(0 10]                     // 0   <  <value> <= 10
@numeric-field:[0 (10]                     // 0   <= <value> <  10
@numeric-field:[(0 (10]                    // 0   <  <value> <  10
@numeric-field:[1.5 (Inf]                  // 1.5 <= value

Tag : comparer

La syntaxe de l'opérateur de comparaison de balises est la suivante :

<tag-search> ::= '@' <tag-field-name> ':' '{' <tag> [ '|' <tag> ]* '}'

Si l'une des balises de l'opérateur correspond à l'une des balises du champ de balise de l'enregistrement, l'enregistrement est inclus dans le jeu de résultats. Le champ conçu par <tag-field-name> doit être un champ de l'index déclaré avec typeTAG. Voici des exemples de comparaison de balises :

@tag-field:{ atag }
@tag-field: { tag1 | tag2 }

Combinaisons booléennes

Les ensembles de résultats d'un opérateur numérique ou d'un opérateur de balise peuvent être combinés à l'aide de la logique booléenne : and/or. Parentheses can be used to group operators and/or modifiez l'ordre d'évaluation. La syntaxe des opérateurs de logique booléenne est la suivante :

<expression> ::= <phrase> | <phrase> '|' <expression> | '(' <expression> ')'
<phrase> ::= <term> | <term> <phrase>
<term> ::= <range-search> | <tag-search> | '*'

Plusieurs termes combinés dans une phrase sont « et ». Les phrases multiples combinées avec le tube (« | ») sont de type « ou ».

Recherche vectorielle

Les index vectoriels prennent en charge deux méthodes de recherche différentes : le voisin le plus proche et le range. Une recherche dans le plus proche voisin permet de localiser un certain nombre, K, des vecteurs de l'index les plus proches du vecteur (de référence) fourni. C'est ce que l'on appelle communément « K » voisins KNN les plus proches. La syntaxe d'une KNN recherche est la suivante :

<vector-knn-search> ::= <expression> '=>[KNN' <k> '@' <vector-field-name> '$' <parameter-name> <modifiers> ']'
<modifiers> ::= [ 'EF_RUNTIME' <integer> ] [ 'AS' <distance-field-name>]

Une KNN recherche vectorielle n'est appliquée qu'aux vecteurs qui répondent aux critères, <expression> qui peuvent être n'importe quelle combinaison des opérateurs définis ci-dessus : caractère générique, recherche par plage, recherche par étiquette et/ou combinaisons booléennes de ces derniers.

Une recherche par plage permet de localiser tous les vecteurs situés à une distance (rayon) spécifiée par rapport à un vecteur de référence. La syntaxe d'une recherche par plage est la suivante :

<vector-range-search> ::= ‘@’ <vector-field-name> ‘:’ ‘[’ ‘VECTOR_RANGE’ ( <radius> | ‘$’ <radius-parameter> )  $<reference-vector-parameter> ‘]’ [ ‘=’ ‘>’ ‘{’ <modifiers> ‘}’ ] 
<modifiers> ::= <modifier> | <modifiers>, <modifier> 
<modifer> ::= [ ‘$yield_distance_as’ ‘:’ <distance-field-name> ] [ ‘$epsilon’ ‘:’ <epsilon-value> ]

Où :

INFOcommande

La recherche vectorielle complète les OSS INFOcommandes Valkey et Redis avec plusieurs sections supplémentaires de statistiques et de compteurs. Une demande de récupération de la section SEARCH permet de récupérer toutes les sections suivantes :

search_memory Section

search_index_stats Section

search_ingestion Section

search_backfill Section

search_query Section

Sécurité de la recherche vectorielle

ACL(Listes de contrôle d'accès) Les mécanismes de sécurité pour l'accès aux commandes et aux données sont étendus pour contrôler la fonction de recherche. ACLle contrôle des commandes de recherche individuelles est entièrement pris en charge. Une nouvelle ACL catégorie est fournie et de nombreuses catégories existantes (@fast,, @read@write, etc.) sont mises à jour pour inclure les nouvelles commandes. @search Les commandes de recherche ne modifient pas les données clés, ce qui signifie que les ACL mécanismes existants pour l'accès en écriture sont préservés. 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 comportant un index est également contrôlé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 peut être facile de créer une situation dans laquelle un utilisateur a accès en lecture et/ou en écriture à une clé mais ne peut pas accéder à un index contenant cette clé. Notez que seul l'accès en lecture au keyspace 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.

Pour plus d'informations sur l'utilisation ACLs de MemoryDB, voir Authentification des utilisateurs avec des listes de contrôle d'accès (). ACLs