Das adaptive Filtern in AlloyDB AI optimiert gefilterte Vektorsuchen, indem während der Abfrageausführung dynamisch die effizienteste Filterstrategie ausgewählt wird. Wenn Sie wissen, wie der Abfrageoptimierer zwischen Inline-Filterung und Vorabfilterung wechselt, können Sie leistungsstarke Vektorabfragen ohne manuelle Indexoptimierung entwerfen.
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 gefilterte Vektorsuchen in AlloyDB AI, bei denen die adaptive Filterung automatisch zwischen der Verwendung von Vektor- und Metadatenindex wechselt. So werden effiziente und genaue Ergebnisse ohne manuellen Eingriff erzielt.
Dynamischer Wechsel zwischen Filterstrategien
Beim adaptiven Filtern wird während der Abfrageausführung automatisch und dynamisch zwischen Inline-Filterung und Vorfilterung gewechselt, basierend auf Echtzeit-Abfragemustern und Datenverteilungen. Der AlloyDB KI-Abfrageoptimierer verwendet eine kostenbasierte Analyse, um zu ermitteln, welche Strategie zu einem bestimmten Zeitpunkt die beste Leistung bietet.
Von der Inline-Filterung zur Vorfilterung
Wenn das Optimierungsprogramm feststellt, dass die Vorabfilterung effizienter ist, wird durch die adaptive Filterung während der Ausführung ein Wechsel von der Inline-Filterung zur Vorabfilterung ausgelöst. Der Abfrageplan ändert sich dynamisch, um dies widerzuspiegeln.
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)
Wenn Sie Execution Strategy: Bitmap assisted pre-filtering verwenden, wird ein großes Dataset zuerst mit einem separaten Bitmap Index Scan gefiltert. Wenn diese Vorfilterung die Kandidaten effektiv eingrenzt, wird der Vektorindex nicht für die endgültige Vektorähnlichkeitssuche verwendet.
Von der Vorfilterung zur Inline-Filterung
Beim adaptiven Filtern kann auch dynamisch von der Vorabfilterung zur Inline-Filterung gewechselt werden, wenn der AlloyDB AI-Abfrageoptimierer feststellt, dass die Inline-Filterung für die aktuellen Abfragemerkmale effizienter ist.
In solchen Fällen wird der Abfrageplan dynamisch angepasst, um eine direktere Verarbeitung der Vektordaten ohne einen expliziten Vorfilterungsschritt vor dem Vektorscan zu ermöglichen. Diese Anpassungsfähigkeit trägt dazu bei, eine optimale Leistung zu erzielen, wenn sich die Datenverteilung oder die Abfrageparameter 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 jeweilige 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 zeigt die Execution Strategy Bitmap assisted vector Scan on scann_idx mit einem zugrunde liegenden Bitmap Index Scan auf btree_idx. Das bedeutet, dass bei der Vektorsuche ein Bitmap-Filter verwendet wird, den der Bitmap-Indexscan basierend auf der int_col <= 100000000-Bedingung generiert. Die Custom Scan (vector scan) verarbeitet dann nur die durch diese Bitmap identifizierten Zeilen und integriert die Filterung direkt in den Vektorscanprozess.
Beispiel: Wie Selektivität einen dynamischen Wechsel auslöst
Die adaptive Filterung basiert auf der Selektivität Ihrer Standardfilter. Wenn durch einen Filter eine große Datenmenge eliminiert wird, wählt der Optimierer wahrscheinlich die Vorfilterung aus. Wenn der Filter den Großteil der Daten intakt lässt, wählt der Optimierer wahrscheinlich die Inline-Filterung aus.
Sie können diesen dynamischen Wechsel in Echtzeit beobachten, indem Sie dieselbe Abfrage ausführen und die Selektivität der WHERE-Klausel anpassen.
Wenn Sie beispielsweise eine große Tabelle mit Einzelhandelsprodukten abfragen, möchten Sie möglicherweise eine Vektorsuche nur für Artikel unter einem bestimmten Preis 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, hat der Filter eine geringe Selektivität. Der AlloyDB AI-Abfrageoptimierer stellt fest, dass es ineffizient ist, fast die gesamte Datenbank in einer vorab gefilterten Liste zu erfassen, und führt daher einen Inline-Vektorscan durch.
Wenn Sie sich den Abfrageplan ansehen, sehen Sie, dass sich das System dynamisch an das riesige Dataset 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. Zu Beginn der Abfrageausführung 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 auf dem neuesten Stand sind. Es wird jedoch schnell festgestellt, dass der Preisfilter eine hohe Selektivität hat: Nur sehr wenige Artikel in der Datenbank sind so günstig. Der Optimierer stellt fest, dass das Erfassen dieser wenigen Zeilen vor dem Ausführen des Vektorscans viel schneller ist, und wechselt daher dynamisch zur Strategie des Vorfilterns.
Der Abfrageplan spiegelt diese Echtzeit-Unterstützung wider. Das System hat das kleine Dataset vor dem Scannen der Vektoren vorgefiltert.
Ursprüngliche Auswahl 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 Wechsel)
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 weder den Anwendungscode neu schreiben noch Datenbankindexe manuell aktualisieren, wenn sich die Datenverteilung im Laufe der Zeit ändert. AlloyDB AI übernimmt die Routinglogik für jede Abfrage und sorgt so für eine hohe Leistung.