Cette page présente un aperçu conceptuel du filtrage adaptatif dans AlloyDB/AI, une fonctionnalité conçue pour optimiser les recherches vectorielles filtrées.
Qu'est-ce que le filtrage adaptatif ?
Le filtrage adaptatif analyse les modèles de requête et les distributions de données lors de l'exécution des requêtes pour choisir dynamiquement la stratégie de filtrage la plus efficace, comme le filtrage intégré ou le préfiltrage.
L'optimiseur de requêtes AlloyDB/AI utilise l'analyse basée sur les coûts pour déterminer si le filtrage intégré ou le préfiltrage offrent les meilleures performances à un moment donné de l'exécution des requêtes.
Ce type d'optimisation est compatible avec les recherches vectorielles filtrées d'AlloyDB/AI, où le filtrage adaptatif bascule automatiquement entre l'utilisation de l'index vectoriel et de l'index de métadonnées, ce qui produit des résultats efficaces et précis sans intervention manuelle.
Passer dynamiquement d'une stratégie de filtrage à une autre
Le filtrage adaptatif bascule automatiquement et de manière dynamique entre les stratégies de filtrage intégré et de préfiltrage lors de l'exécution des requêtes, en fonction des modèles de requêtes et des distributions de données en temps réel. L'optimiseur de requêtes AlloyDB/AI utilise une analyse basée sur les coûts pour déterminer la stratégie qui offre les meilleures performances à un moment donné.
De l'intégration à la pré-filtration
Lorsque l'optimiseur détermine que le préfiltrage est plus efficace, le filtrage adaptatif déclenche un basculement du filtrage intégré au préfiltrage lors de l'exécution. Le plan de requête change de manière dynamique pour refléter cela.
Par exemple, le plan peut afficher Bitmap assisted pre-filtering dans le champ Stratégie d'exécution lorsque l'optimiseur détermine que le préfiltrage est plus efficace à ce stade de la requête. Ce changement dynamique se produit lorsque le système s'adapte aux données réelles qu'il rencontre lors de l'exécution de la requête.
Limit (actual rows=10 loops=1)
-> Custom Scan (vector scan) on t1 (actual rows=10 loops=1)
Execution Strategy: Bitmap assisted pre-filtering
Order By: (vec_col <=> '[...]'::vector)
Limit: 10
-> Bitmap Index Scan on btree_idx (actual rows=10000 loops=1)
Index Cond: (int_col <= 100000000)
Lorsque vous utilisez Execution Strategy: Bitmap assisted pre-filtering, un Bitmap Index Scan distinct filtre d'abord un grand ensemble de données. Si ce préfiltrage réduit efficacement le nombre de candidats, l'index vectoriel n'est pas utilisé pour la recherche finale de similarité vectorielle.
Du préfiltrage au filtrage intégré
Le filtrage adaptatif peut également passer dynamiquement du préfiltrage au filtrage intégré si l'optimiseur de requêtes AlloyDB AI détermine que le filtrage intégré est plus efficace pour les caractéristiques de la requête actuelle.
Dans ce cas, le plan de requête s'ajuste de manière dynamique pour refléter un traitement plus direct des données vectorielles, sans étape de préfiltrage explicite précédant l'analyse vectorielle. Cette adaptabilité permet d'obtenir des performances optimales lorsque les distributions de données ou les paramètres de requête changent pendant l'exécution.
Par exemple, le plan de requête affiche vector scan dans le champ Stratégie d'exécution lorsque l'optimiseur détermine qu'une stratégie de filtrage intégré est plus efficace pour la requête donnée.
Limit (actual rows=10 loops=1)
-> Custom Scan (vector scan) on t1 (actual rows=10 loops=1)
Execution Strategy: Bitmap assisted vector Scan on scann_idx
Order By: (vec_col <=> '[...]'::vector)
Limit: 10
Num Requalifications: 0
Num filtered: 1000
-> Bitmap Index Scan on btree_idx (actual rows=10000 loops=1)
Index Cond: (int_col <= 100000000)
Dans cet exemple, Execution Strategy affiche Bitmap assisted vector Scan on scann_idx, avec un Bitmap Index Scan sous-jacent sur btree_idx. Cela indique que la recherche vectorielle utilise un filtre bitmap, que l'analyse d'index bitmap génère en fonction de la condition int_col <= 100000000. Custom Scan (vector scan) ne traite ensuite que les lignes identifiées par ce bitmap, en intégrant le filtrage directement dans le processus d'analyse vectorielle.
Exemple : Comment la sélectivité déclenche un changement dynamique
Le filtrage adaptatif base ses décisions sur la sélectivité de vos filtres standards. Si un filtre élimine une grande quantité de données, l'optimiseur choisira probablement le préfiltrage. Si le filtre laisse la plupart des données intactes, l'optimiseur choisit probablement le filtrage intégré.
Vous pouvez observer ce changement dynamique en temps réel en exécutant la même requête et en ajustant la sélectivité de votre clause WHERE.
Par exemple, lorsque vous interrogez une grande table de produits commerciaux, vous pouvez effectuer une recherche vectorielle uniquement sur les articles dont le prix est inférieur à un certain montant.
Faible sélectivité
Commencez par rechercher des produits de moins de 1 000 $. Étant donné que presque tous les produits de la base de données coûtent moins de 1 000 $, le filtre a une faible sélectivité. L'optimiseur de requêtes AlloyDB/AI détermine qu'il est inefficace de rassembler la quasi-totalité de la base de données dans une liste préfiltrée. Il effectue donc une analyse vectorielle intégrée.
Si vous examinez le plan de requête, vous constaterez que le système s'est adapté de manière dynamique à l'ensemble de données volumineux et a choisi le filtrage intégré.
Limit (actual rows=10)
-> Custom Scan (vector scan)
Execution Strategy: Bitmap assisted vector Scan on scann_idx
Order By: (vec <=> '[...]'::vector)
-> Bitmap Index Scan
Index Cond: (price <= 1000)
Sélectivité élevée
Vous modifiez ensuite la requête pour rechercher des produits à moins de 10 $. Lorsque la requête commence à s'exécuter, l'optimiseur de requêtes AlloyDB AI se prépare initialement à utiliser le filtrage intégré. Le planificateur suppose à tort que le filtre n'est pas très sélectif. Cela se produit plus souvent que prévu, car les statistiques utilisées pour établir ces estimations ne sont pas toujours précises ni à jour. Toutefois, il détermine rapidement que le filtre de prix a une sélectivité élevée : très peu d'articles dans la base de données sont proposés à ce prix. L'optimiseur détermine que la collecte de ces quelques lignes avant d'effectuer l'analyse vectorielle est beaucoup plus rapide. Il change donc de stratégie de manière dynamique pour le préfiltrage.
Le plan de requête reflète ce tableau croisé dynamique en temps réel. Le système a choisi de préfiltrer le petit ensemble de données avant d'analyser les vecteurs.
Choix initial du planificateur
Limit (actual rows=10)
-> Custom Scan (vector scan)
Execution Strategy: Bitmap assisted vector Scan on scann_idx
Order By: (vec <=> '[...]'::vector)
-> Bitmap Index Scan
Index Cond: (price <= 10)
Exécution réelle (commutateur adaptatif)
Limit (actual rows=10)
-> Custom Scan (vector scan)
Execution Strategy: Bitmap assisted pre-filtering
Order By: (vec <=> '[...]'::vector)
-> Bitmap Index Scan
Index Cond: (price <= 10)
Vous n'avez pas besoin de réécrire le code de votre application ni de mettre à jour manuellement les index de base de données à mesure que la distribution de vos données change au fil du temps. AlloyDB/AI gère la logique de routage pour vous à chaque requête, ce qui garantit des performances élevées.