Le filtrage adaptatif dans AlloyDB AI optimise les recherches vectorielles filtrées en sélectionnant de manière dynamique la stratégie de filtrage la plus efficace lors de l'exécution des requêtes. Comprendre comment l'optimiseur de requêtes bascule entre le filtrage intégré et le préfiltrage vous aide à concevoir des requêtes vectorielles hautes performances sans réglage manuel des index.
Qu'est-ce que le filtrage adaptatif ?
Le filtrage adaptatif analyse les schémas de requêtes et les distributions de données lors de l'exécution des requêtes pour choisir de manière dynamique 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 une analyse basée sur les coûts pour déterminer si le filtrage intégré ou le préfiltrage offre les meilleures performances à un moment donné lors de l'exécution des requêtes.
Ce type d'optimisation est compatible avec les recherches Vector Search filtrées d'AlloyDB AI, où le filtrage adaptatif bascule automatiquement entre l'utilisation d'index vectoriels et de métadonnées, ce qui génère des résultats efficaces et précis sans intervention manuelle.
Basculement dynamique entre les stratégies de filtrage
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 schémas 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é.
Du filtrage intégré au préfiltrage
Lorsque l'optimiseur détermine que le préfiltrage est plus efficace, le filtrage adaptatif déclenche un basculement du filtrage intégré vers le 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 Execution Strategy (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, une Bitmap Index Scan distincte 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 lors de l'exécution.
Par exemple, le plan de requête affiche vector scan dans le champ Execution Strategy (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, la Execution Strategy affiche Bitmap assisted vector Scan on scann_idx, avec une Bitmap Index Scan sous-jacente 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. L'Custom Scan (vector scan) traite ensuite uniquement 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 basculement 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 choisit 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 basculement 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 de vente au détail, vous pouvez effectuer une Vector Search uniquement sur les articles dont le prix est inférieur à un certain montant.
Faible sélectivité
Tout d'abord, vous recherchez les produits dont le prix est inférieur à 1 000 $. Comme 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 constatez 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
Ensuite, vous modifiez la requête pour rechercher les produits dont le prix est inférieur à 10 $. Au début de l'exécution de la requête, 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 effectuer ces estimations ne sont pas toujours exactes ni à jour. Cependant, il détermine rapidement que le filtre de prix a une sélectivité élevée : très peu d'articles de la base de données sont vendus à ce prix. L'optimiseur détermine qu'il est beaucoup plus rapide de collecter ces quelques lignes avant d'effectuer l'analyse vectorielle. Il bascule donc dynamiquement vers le préfiltrage.
Le plan de requête reflète ce pivot 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 (basculement 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 la base de données lorsque la distribution de vos données change au fil du temps. AlloyDB AI gère la logique de routage pour vous sur chaque requête, ce qui garantit des performances élevées.