Cette page décrit la version 18.1.0 d'AlloyDB Omni à l'aide de l'option de déploiement Conteneurs. Choisissez une autre option de déploiement.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Régler les performances des requêtes vectorielles dans AlloyDB Omni

Sélectionnez une version de la documentation :

Ce document explique comment ajuster vos index pour obtenir des requêtes plus rapides et un meilleur rappel dans AlloyDB Omni.

Avant de commencer

Avant de créer un index ScaNN, procédez comme suit :

Assurez-vous qu'une table contenant vos données a déjà été créée.
Pour éviter les problèmes lors de la génération de l'index, assurez-vous que la valeur que vous définissez pour les options maintenance_work_mem et shared_buffers est inférieure à la mémoire totale de la machine.
Pour utiliser des index à quatre niveaux, vous devez d'abord activer la fonctionnalité Preview pour votre instance. Pour activer la fonctionnalité Aperçu, choisissez l'une des deux méthodes suivantes :
- Activez le flag de base de données scann.enable_preview_features.
- Définissez le flag de base de données scann.max_allowed_num_levels au niveau de la session sur 3. sql SET scann.max_allowed_num_levels = 3;

Régler un index `ScaNN`

Suivez les conseils ci-dessous pour déterminer le nombre de niveaux nécessaires pour votre index ScaNN :

Pour 0 à 10 millions de lignes : choisissez un index à deux niveaux.
Pour 10 millions à 100 millions de lignes :
- Pour privilégier le rappel de recherche, choisissez un index à deux niveaux.
- Pour privilégier la durée de la compilation de l'index, choisissez un index à trois niveaux.
Pour 100 millions à 1 milliard de lignes :
- Pour privilégier le rappel de recherche, choisissez un index à trois niveaux.
- Pour privilégier la durée de la compilation de l'index, choisissez un index à quatre niveaux (dans Aperçu).
Pour 1 milliard à 10 milliards de lignes : choisissez un index à quatre niveaux (dans Aperçu).

Observez les exemples suivants pour les index ScaNN à deux, trois et quatre niveaux, qui montrent comment les paramètres d'optimisation sont définis pour une table comportant 1 000 000 de lignes :

Index à deux niveaux

SET LOCAL scann.num_leaves_to_search = 1;
SET LOCAL scann.pre_reordering_num_neighbors=50;

CREATE INDEX my-scann-index ON my-table
  USING scann (vector_column cosine)
  WITH (num_leaves = [power(1000000, 1/2)]);

Index à trois niveaux

SET LOCAL scann.num_leaves_to_search = 10;
SET LOCAL scann.pre_reordering_num_neighbors=50;

CREATE INDEX my-scann-index ON my-table
  USING scann (vector_column cosine)
  WITH (num_leaves = [power(1000000, 2/3)], max_num_levels = 2);

Index à quatre niveaux

(en version Preview)

SET LOCAL scann.num_leaves_to_search = 100;
SET LOCAL scann.pre_reordering_num_neighbors=50;

CREATE INDEX my-scann-index ON my-table
  USING scann (vector_column cosine)
  WITH (num_leaves = [power(1000000, 3/4)], max_num_levels = 3);

Gérer les invalidations LMD dues à l'accélération avec le moteur de données en colonnes

Si vous avez choisi d'accélérer vos recherches vectorielles avec le moteur de données en colonnes, sachez que les invalidations LMD et LDD sur les tables de base peuvent avoir un impact sur les performances des requêtes vectorielles. En cas de débit LMD élevé, envisagez d'ajuster l'indicateur de base de données google_columnar_engine.refresh_threshold_percentage ou d'actualiser manuellement l'index à l'aide de la commande google_columnar_engine_refresh_index.

Analyser vos requêtes

Utilisez la commande EXPLAIN ANALYZE pour analyser les insights sur les requêtes, comme indiqué dans l'exemple de requête SQL suivant.

  EXPLAIN ANALYZE SELECT result-column
  FROM my-table
  ORDER BY EMBEDDING_COLUMN <-> embedding('text-embedding-005', 'What is a database?')::vector
  LIMIT 1;

L'exemple de réponse QUERY PLAN inclut des informations telles que le temps écoulé, le nombre de lignes analysées ou renvoyées, ainsi que les ressources utilisées.

Limit  (cost=0.42..15.27 rows=1 width=32) (actual time=0.106..0.132 rows=1 loops=1)
  ->  Index Scan using my-scann-index on my-table  (cost=0.42..858027.93 rows=100000 width=32) (actual time=0.105..0.129 rows=1 loops=1)
        Order By: (embedding_column <-> embedding('text-embedding-005', 'What is a database?')::vector(768))
        Limit value: 1
Planning Time: 0.354 ms
Execution Time: 0.141 ms

Afficher les métriques d'index vectoriel

Vous pouvez utiliser les métriques d'index vectoriel pour examiner les performances de votre index vectoriel, identifier les points à améliorer et ajuster votre index en fonction des métriques, si nécessaire.

Pour afficher toutes les métriques d'index vectoriel, exécutez la requête SQL suivante, qui utilise la vue pg_stat_ann_indexes :

SELECT * FROM pg_stat_ann_indexes;

Vous obtenez un résultat semblable à celui-ci :

-[ RECORD 1 ]----------+---------------------------------------------------------------------------
relid                  | 271236
indexrelid             | 271242
schemaname             | public
relname                | t1
indexrelname           | t1_ix1
indextype              | scann
indexconfig            | {num_leaves=100,max_num_levels=1,quantizer=SQ8}
indexsize              | 832 kB
indexscan              | 0
insertcount            | 250
deletecount            | 0
updatecount            | 0
partitioncount         | 100
distribution           | {"average": 3.54, "maximum": 37, "minimum": 0, "outliers": [37, 12, 11, 10, 10, 9, 9, 9, 9, 9]}
distributionpercentile |{"10": { "num_vectors": 0, "num_partitions": 0 }, "25": { "num_vectors": 0, "num_partitions": 30 }, "50": { "num_vectors": 3, "num_partitions": 30 }, "75": { "num_vectors": 5, "num_partitions": 19 }, "90": { "num_vectors": 7, "num_partitions": 11 }, "95": { "num_vectors": 9, "num_partitions": 5 }, "99": { "num_vectors": 12, "num_partitions": 4 }, "100": { "num_vectors": 37, "num_partitions": 1 }}

Pour afficher le nombre de lignes créées au moment de la création de l'index, exécutez la commande suivante :

SELECT * FROM pg_stat_ann_index_creation;