Auf dieser Seite finden Sie einen konzeptionellen Überblick über das adaptive Filtern in AlloyDB AI, einer Funktion zur Optimierung gefilterter Vektorsuchen.
Was ist die adaptive Filterung?
Beim adaptiven Filtern werden Abfragemuster und Datenverteilungen während der Abfrageausführung analysiert, um dynamisch die effizienteste Filterstrategie auszuwählen, z. B. Inline- oder Vorfilterung.
Der AlloyDB AI-Abfrageoptimierer verwendet eine kostenbasierte Analyse, um zu ermitteln, ob Inline-Filterung oder Vorabfilterung zu einem bestimmten Zeitpunkt während der Abfrageausführung die beste Leistung bietet.
Diese Art der Optimierung unterstützt die gefilterten Vektorsuchen von AlloyDB AI, bei denen das adaptive Filtern automatisch zwischen der Verwendung von Vektor- und Metadatenindex wechselt, um effiziente und genaue Ergebnisse ohne manuellen Eingriff zu erzielen.
Dynamisches Wechseln zwischen Filterstrategien
Beim adaptiven Filtern wird während der Abfrageausführung automatisch und dynamisch zwischen Inline- und Vorfilterstrategien gewechselt. Die Entscheidung basiert auf Echtzeit-Abfragemustern und Datenverteilungen. Der AlloyDB AI-Abfrageoptimierer verwendet eine kostenbasierte Analyse, um zu ermitteln, welche Strategie zu einem bestimmten Zeitpunkt die beste Leistung bietet.
Von der Inline- zur Vorfilterung
Wenn das Optimierungsprogramm feststellt, dass Vorabfilterung effizienter ist, wird durch adaptives Filtern während der Ausführung ein Wechsel von Inline-Filtern zu Vorfiltern ausgelöst. Der Abfrageplan wird dynamisch angepasst.
Im Plan kann beispielsweise Bitmap assisted pre-filtering im Feld Ausführungsstrategie angezeigt werden, wenn das Optimierungsprogramm feststellt, dass Vorabfilterung an dieser Stelle in der Abfrage effizienter ist. Diese dynamische Änderung erfolgt, wenn das System sich an die tatsächlichen Daten anpasst, die während der Ausführung der Abfrage auftreten.
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)
Bei Verwendung von Execution Strategy: Bitmap assisted pre-filtering wird ein großer Datensatz zuerst durch ein separates Bitmap Index Scan gefiltert. Wenn durch diese Vorfilterung die Kandidaten effektiv eingegrenzt werden, wird der Vektorindex nicht für die endgültige Suche nach Vektorähnlichkeit verwendet.
Von der Vorfilterung zur Inline-Filterung
Beim adaptiven Filtern kann auch dynamisch von Vorabfilterung zu Inline-Filterung gewechselt werden, wenn der AlloyDB AI-Abfrageoptimierer feststellt, dass Inline-Filterung für die aktuellen Abfrageeigenschaften effizienter ist.
In solchen Fällen wird der Abfrageplan dynamisch angepasst, um eine direktere Verarbeitung der Vektordaten ohne expliziten Vorfilterschritt vor dem Vektorscan zu ermöglichen. Diese Anpassungsfähigkeit trägt dazu bei, dass eine optimale Leistung erzielt wird, wenn sich Datenverteilungen oder Suchparameter während der Laufzeit ändern.
Im Abfrageplan wird beispielsweise vector scan im Feld Ausführungsstrategie angezeigt, wenn das Optimierungsprogramm feststellt, dass eine Inline-Filterstrategie für die angegebene Abfrage effizienter ist.
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)
In diesem Beispiel wird Execution Strategy als Bitmap assisted vector Scan on scann_idx dargestellt, mit einem zugrunde liegenden Bitmap Index Scan auf btree_idx. Das bedeutet, dass bei der Vektorsuche ein Bitmap-Filter verwendet wird, der vom Bitmap-Indexscan auf Grundlage der int_col <= 100000000-Bedingung generiert wird. Custom Scan (vector scan) verarbeitet dann nur die durch diese Bitmap identifizierten Zeilen und integriert die Filterung direkt in den Vektorscanprozess.
Beispiel: Selektivität löst dynamischen Wechsel aus
Die adaptive Filterung basiert auf der Selektivität Ihrer Standardfilter. Wenn durch einen Filter eine große Menge an Daten entfernt wird, wählt der Optimizer wahrscheinlich die Vorfilterung aus. Wenn der Filter die meisten Daten unverändert lässt, wählt der Optimizer wahrscheinlich die Inline-Filterung aus.
Sie können diesen dynamischen Wechsel in Echtzeit beobachten, indem Sie dieselbe Abfrage ausführen und die Selektivität Ihrer WHERE-Klausel anpassen.
Wenn Sie beispielsweise eine große Tabelle mit Einzelhandelsprodukten abfragen, möchten Sie möglicherweise nur für Artikel unter einem bestimmten Preis eine Vektorsuche durchführen.
Geringe Selektivität
Zuerst suchen Sie nach Produkten unter 1.000 $. Da fast jedes Produkt in der Datenbank weniger als 1.000 $kostet, ist die Selektivität des Filters gering. Der AlloyDB AI-Abfrageoptimierer stellt fest, dass das Erstellen einer vorab gefilterten Liste, die fast die gesamte Datenbank umfasst, ineffizient ist. Daher wird ein Inline-Vektorscan durchgeführt.
Wenn Sie sich den Abfrageplan ansehen, sehen Sie, dass das System sich dynamisch an den riesigen Datensatz angepasst und die Inline-Filterung ausgewählt hat.
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)
Hohe Selektivität
Als Nächstes ändern Sie die Abfrage, um nach Produkten unter 10 $zu suchen. Wenn die Ausführung der Abfrage beginnt, bereitet sich der AlloyDB AI-Abfrageoptimierer zunächst auf die Verwendung der Inline-Filterung vor. Der Planer geht fälschlicherweise davon aus, dass der Filter nicht sehr selektiv ist. Das passiert häufiger als erwartet, weil die Statistiken, die für diese Schätzungen verwendet werden, nicht immer genau oder aktuell sind. Es wird jedoch schnell festgestellt, dass der Preisfilter eine hohe Selektivität hat: Nur sehr wenige Artikel in der Datenbank haben einen so niedrigen Preis. Der Optimierer stellt fest, dass das Erfassen dieser wenigen Zeilen vor dem Ausführen des Vektorscans viel schneller ist. Daher wird die Strategie dynamisch auf Vorfiltern umgestellt.
Der Abfrageplan spiegelt diese Echtzeit-Umstellung wider. Das System hat das kleine Dataset vor dem Scannen der Vektoren vorab gefiltert.
Erste Wahl des Planers
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)
Tatsächliche Ausführung (adaptiver Schalter)
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)
Sie müssen Ihren Anwendungscode nicht neu schreiben oder Datenbankindexe manuell aktualisieren, wenn sich die Datenverteilung im Laufe der Zeit ändert. AlloyDB AI übernimmt die Routing-Logik für jede Abfrage und sorgt so für eine hohe Leistung.