Recherche vectorielle dans Cloud SQL pour MySQL

Cette page explique comment les recherches vectorielles sont implémentées sur les instances Cloud SQL pour MySQL. Cloud SQL vous permet de stocker des embeddings vectoriels, de créer des index vectoriels et d'effectuer des recherches vectorielles en même temps que vos autres données stockées.

Stockage d'embeddings vectoriels

Vous stockez les embeddings vectoriels dans une table conforme aux propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID). Comme pour les autres données relationnelles de la table, vous pouvez accéder aux embeddings vectoriels de la table avec la sémantique transactionnelle existante.

Pour établir un mappage entre les lignes de table et les représentations vectorielles, vous devez créer une colonne dans votre table pour stocker vos embeddings vectoriels. La colonne doit utiliser le type de données VECTOR. La colonne d'embeddings vectoriels ne peut stocker que des embeddings vectoriels qui utilisent exactement les mêmes dimensions que celles que vous spécifiez lorsque vous définissez la colonne. Le nombre de lignes dans la table où vous stockez les embeddings vectoriels n'est pas limité.

Si vous disposez de suffisamment d'espace de stockage et de mémoire sur votre instance Cloud SQL, vous pouvez avoir plusieurs tables avec leurs propres colonnes d'embeddings vectoriels.

La réplication des données fonctionne de la même manière pour la colonne d'embeddings vectoriels que pour les autres colonnes MySQL InnoDB.

Pour obtenir la liste des limites et restrictions concernant les tables, les colonnes, et les instructions LMD d'embeddings vectoriels, consultez la section Limites.

Index vectoriels

Vous devez utiliser un index vectoriel pour effectuer des recherches de similarité ANN sur vos embeddings vectoriels. Cloud SQL crée des index vectoriels à l'aide de l' algorithme ScaNN (Scalable Nearest Neighbors).

Les index vectoriels sont soumis aux exigences suivantes :

  • Vous ne pouvez créer qu'un seul index vectoriel par table.
  • Si votre instance comporte plusieurs tables avec des embeddings vectoriels, vous pouvez créer des index vectoriels pour chacune d'elles.
  • Si vous créez un index vectoriel, vous ne pouvez pas ajouter de contrainte à la clé primaire de la table indexée.

Pour une meilleure qualité de recherche, ne créez un index vectoriel qu'après avoir chargé la majeure partie de vos données dans la table de base. Si la table de base contient moins de 1 000 embeddings, la création de l'index échoue.

Lorsque vous décidez de créer ou non un index vectoriel, si vous avez un petit nombre de lignes, déterminez si vous pouvez effectuer une recherche KNN à la place. La décision d'utiliser une recherche KNN ou ANN dépend également du nombre de dimensions de l'embedding vectoriel. Un plus grand nombre d'embeddings peut nécessiter un index vectoriel.

Pour obtenir la liste des limites et restrictions concernant les index vectoriels, consultez la section Limites. Pour savoir comment créer un index vectoriel, consultez Créer et gérer des index vectoriels.

Mises à jour des index vectoriels

Cloud SQL met à jour les index vectoriels en temps réel. Toute transaction effectuant des opérations LMD (langage de manipulation de données) sur la table de base propage également les modifications apportées aux index vectoriels associés. Les index vectoriels se comportent de la même manière que tout autre index secondaire de la table. Les index vectoriels sont entièrement cohérents sur le plan transactionnel et conformes à la norme ACID. Si vous effectuez un rollback sur une transaction, les modifications de rollback correspondantes se produisent également dans l'index vectoriel.

Réplication des index vectoriels

Cloud SQL réplique les index vectoriels sur toutes les instances dupliquées avec accès en lecture, y compris pour les instances dupliquées en cascade. Lorsque vous créez une instance dupliquée avec accès en lecture à partir d'une instance principale comportant un embedding vectoriel, l'instance dupliquée avec accès en lecture hérite des paramètres d'embedding vectoriel de l'instance principale. Pour les instances dupliquées avec accès en lecture existantes, vous devez activer la compatibilité avec les embeddings vectoriels sur chacune d'elles.

En termes d'impact sur le délai de réplication, la création et la gestion des index vectoriels fonctionnent de la même manière que les index MySQL classiques.

Persistance, mise hors service et impact sur la maintenance

Les index vectoriels sont conservés de la même manière que les tables de base, avec une compatibilité ACID complète. Les index vectoriels sont toujours synchronisés avec les données de leur table de base et présentent la même visibilité, le même isolement et la même sécurité en cas de plantage. L'arrêt ou la maintenance de l'instance n'a aucun impact sur l'index vectoriel.

Maintenance des index

Après avoir effectué des opérations LMD étendues sur la table de base, l'index vectoriel que vous avez entraîné sur les données initiales (au moment de la création de l'index) peut ne pas refléter le nouvel état. Cela peut avoir un impact sur la qualité de la recherche.

L'index comporte deux parties :

  • L'arborescence d'index. Elle est créée en entraînant les données existantes. Elle reste inchangée pendant toute la durée de vie de l'index.
  • Les feuilles d'index. Elles contiennent toutes les lignes de données. Les feuilles d'index ne sont jamais désynchronisées.

L'arborescence d'index peut devenir moins efficace après l'exécution d'un grand nombre d'instructions LMD, car les lignes passent d'une feuille à une autre. Pour actualiser l'arborescence d'index, vous devez recréer l'index.

Opérations LDD non compatibles sur les tables avec index vectoriels

Les opérations LDD (langage de définition de données) suivantes ne sont pas compatibles avec les tables comportant des index vectoriels.

  • Opérations de modification de table nécessitant l'algorithme de copie
  • Opérations de modification de table nécessitant la recréation de la table
  • Supprimer ou modifier la clé primaire
  • Déplacer la table vers un espace de table général

Cloud SQL fournit des fonctions de distance vectorielle que vous utilisez pour effectuer des recherches de similarité vectorielle ANN (Approximate Nearest Neighbor) et KNN (K-Nearest Neighbors) sur votre instance. Lorsque vous exécutez une requête, le vecteur de requête est comparé aux vecteurs de votre ensemble de données. Les fonctions de distance calculent la distance entre les vecteurs à l'aide d'une métrique de similarité telle que le cosinus. Les vecteurs dont la distance est la plus courte sont les plus similaires et sont renvoyés dans les résultats de recherche.

Cloud SQL utilise les fonctions suivantes pour mesurer la distance entre les vecteurs dans les recherches vectorielles lorsque vous effectuez des recherches vectorielles ANN et KNN :

  • Cosinus: mesure le cosinus de l'angle entre deux vecteurs. Une valeur plus petite indique une plus grande similarité entre les vecteurs.
  • Produit scalaire: calcule le cosinus de l'angle multiplié par le produit des magnitudes vectorielles correspondantes.
  • Distance L2 au carré: mesure la distance euclidienne entre deux vecteurs en ajoutant la distance au carré sur chaque dimension.

Une recherche vectorielle KNN est la méthode de recherche privilégiée lorsque vous avez besoin de résultats exacts ou que vous souhaitez ajouter un filtrage sélectif. La recherche KNN effectue un calcul de distance du vecteur de requête avec chaque embedding de l'ensemble de données pour trouver le voisin le plus proche. Les recherches KNN dans Cloud SQL offrent un rappel parfait. Les recherches KNN n'utilisent pas d'index vectoriel. Elles constituent donc une bonne option lorsque vous travaillez avec des ensembles de données plus petits.

Pour effectuer une recherche KNN, vous utilisez la fonction vector_distance qui prend deux vecteurs en entrée : le vecteur de requête (ce que vous recherchez) et un vecteur candidat de votre ensemble de données. Elle calcule la distance entre ces deux vecteurs. Vous utilisez vector_distance dans une instruction SELECT. Pour en savoir plus, consultez Rechercher les k plus proches voisins (KNN).

Si vous constatez que KNN ne fonctionne pas correctement, vous pouvez créer un index vectoriel ultérieurement et continuer à utiliser approx_distance dans votre application pour les recherches ANN.

Une recherche vectorielle ANN est le type de recherche privilégié lorsque l'efficacité des requêtes est un problème. Elle accélère les recherches de similarité en calculant la distance entre votre vecteur de requête et seulement une partie des vecteurs de votre ensemble de données. Pour ce faire, Cloud SQL organise les données en clusters ou en partitions, puis concentre la recherche sur les clusters les plus proches de la requête. Les recherches ANN nécessitent des index vectoriels. Ces index privilégient la vitesse de recherche par rapport au rappel parfait. Dans Cloud SQL, le TREE_SQ est utilisé pour les recherches ANN.

Pour effectuer une recherche ANN, vous utilisez la approx_distance fonction avec une option de mesure de distance. Vous utilisez approx_distance dans une liste ORDER BY ou SELECT, et une clause LIMIT est autorisée pour limiter les résultats de recherche. Vous pouvez également ajouter une clause WHERE pour effectuer un post-filtrage de vos résultats de recherche. Si vous souhaitez mieux contrôler le nombre de résultats renvoyés lorsque vous effectuez une recherche ANN avec des filtres, vous pouvez utiliser le filtrage itératif. Avec le filtrage itératif, votre requête de recherche peut renvoyer davantage de résultats de recherche en analysant davantage l'index vectoriel jusqu'à ce que le nombre de voisins préféré soit trouvé.

Vous pouvez activer le filtrage itératif pour votre requête de recherche en définissant l'indicateur cloudsql_vector_iterative_filtering sur ON au niveau de la session pour des clients individuels ou au niveau mondial pour tous les clients qui se connectent à l'instance.

Pour en savoir plus, consultez Rechercher les plus proches voisins approximatifs (ANN).

Dans certains cas, une recherche ANN revient à une recherche KNN. Pour en savoir plus, consultez Vérifier l'état de secours pour les recherches ANN.

Différences de compatibilité vectorielle dans les versions de Cloud SQL pour MySQL

Cloud SQL pour MySQL a introduit la compatibilité avec la recherche vectorielle dans la version 8.0.36 et versions ultérieures. À partir de Cloud SQL pour MySQL version 9.7, Cloud SQL a modifié des fonctionnalités spécifiques de recherche vectorielle pour mieux s'intégrer aux fonctionnalités de compatibilité et de stockage vectorielles développées par la communauté introduites dans MySQL 9.0 développé par la communauté.

Le tableau suivant compare les versions de Cloud SQL pour MySQL et explique comment les différences de version peuvent affecter l'utilisation de la recherche vectorielle dans Cloud pour MySQL.

Zone de compatibilité Cloud SQL pour MySQL 8.4 et versions antérieures Cloud SQL pour MySQL 9.7 et versions ultérieures
Activation vectorielle Pour ajouter des embeddings vectoriels à votre base de données MySQL et utiliser la recherche vectorielle, vous devez définir l'indicateur cloudsql_vector sur on pour votre instance Cloud SQL. Si vous souhaitez créer des index vectoriels et effectuer une recherche ANN, vous devez définir l'indicateur cloudsql_vector sur on.
Colonnes d'embeddings vectoriels dans une table Une table ne peut comporter qu'une seule colonne d'embeddings vectoriels. Vous êtes limité à une seule colonne d'embeddings vectoriels par table uniquement si vous créez un index sur la table. Si vous ne créez pas d'index sur la table, celle-ci peut comporter plusieurs colonnes d'embeddings vectoriels.
Utilisation de COMMENT et CONSTRAINT pour identifier les colonnes d'embeddings vectoriels Pour distinguer la colonne d'embeddings vectoriels des autres colonnes, Cloud SQL ajoute une annotation COMMENT spéciale et une règle CONSTRAINT à la colonne. La contrainte est requise pour la validation des entrées, et l'annotation de la colonne d'embeddings vectoriels est visible en tant que commentaire. Vous ne pouvez pas modifier ni supprimer le commentaire ou la contrainte. L'annotation COMMENT et la règle CONSTRAINT ne sont plus utilisées pour identifier les colonnes d'embeddings vectoriels dans Cloud SQL pour MySQL 9.7.
Limite de dimensions Un embedding vectoriel est limité à 16 000 dimensions sans valeur par défaut. Un embedding vectoriel est limité à 16 383 dimensions avec une valeur par défaut de 2 048.
Format de stockage vectoriel Format VARBINARY Format de stockage basé sur la communauté
Syntaxe de déclaration du type de données vectorielles VECTOR(VECTOR_DIMENSIONS)
USING VARBINARY 		VECTOR(VECTOR_DIMENSIONS)
[USING VARBINARY]
Différences de fonction de conversion La sortie de la fonction vector_to_string est imprimée comme valeur entière. La sortie de la vector_to_string fonction est affichée en notation scientifique, qui est la norme de la communauté.

Limites

Les limites suivantes s'appliquent à toutes les versions de Cloud SQL compatibles avec les vecteurs :

  • Il ne peut y avoir qu'un seul index vectoriel par table.
  • La colonne d'embeddings vectoriels ne peut pas être une colonne générée.
  • Le partitionnement au niveau de la table sur les tables comportant des colonnes d'embeddings vectoriels n'est pas accepté.
  • Les clés primaires qui utilisent les types de données BIT, BINARY, VARBINARY, JSON, BLOB, TEXT ou les données spatiales ne sont pas compatibles avec les index vectoriels. Les clés primaires composites ne peuvent inclure aucun de ces types.
  • Si un index vectoriel est présent, vous ne pouvez pas ajouter de contrainte à la clé primaire de la table de base.
  • Lorsqu'un index vectoriel est présent dans une table, certaines opérations LDD ne peuvent pas être effectuées. Pour en savoir plus, consultez Opérations LDD non compatibles sur les tables avec index vectoriels.

Les restrictions suivantes s'appliquent aux requêtes de recherche vectorielle :

  • La fonction approx_distance ne peut être utilisée que dans une liste ORDER BY ou SELECT.
  • Les prédicats impliquant la table de base peuvent être utilisés dans la condition WHERE en combinaison avec des expressions approx_distance dans la liste ORDER BY ou SELECT. Les prédicats de condition WHERE sont évalués après l'évaluation des fonctions vectorielles approx_distance.

Étape suivante