Während Datenbanken das Fundament vieler Softwaresysteme bilden, müssen Datenbankkomponenten wie Anfrageoptimierer häufig neu entworfen werden, um der zunehmenden Vielfalt an Arbeitslasten, Daten und Hardwaredesigns gerecht zu werden, was einen erheblichen technischen Aufwand für die Anpassung ihres Designs bedeutet. Vor kurzem wurde daher vorgeschlagen, DBMS-Komponenten wie Optimierer, Kardinalitätsschätzer etc. durch ML-Modelle zu ersetzen, wodurch nicht nur der Entwicklungsaufwand entfällt, sondern auch eine bessere Leistung für viele Komponenten erzielt wird.

Der vorherrschende Ansatz zur Erstellung solcher gelernten Komponenten ist das Workload-getriebene Lernen, bei dem zunächst zehntausende Abfragen ausgeführt werden müssen, um die erforderlichen Trainingsdaten zu erhalten. Leider muss die Erhebung von Trainingsdaten, die selbst für mittelgroße Datensätze Tage dauern kann, für jede neue Datenbank (d. h. Kombination aus Datensatz, Schema und Arbeitslast) wiederholt werden. Dies ist vor allem bei Cloud-Datenbanken wie Snowflake oder Redshift problematisch, da dieser Aufwand für jeden Kunden anfällt.

In dieser Dissertation werden daher dateneffiziente gelernte Datenbankkomponenten vorgeschlagen, die die hohen Kosten der Trainingsdatenerhebung für gelernte Datenbankkomponenten entweder reduzieren oder ganz eliminieren. Insbesondere werden in dieser Dissertation drei Richtungen vorgeschlagen, nämlich zielen wir (i) zunächst darauf ab, die Anzahl der benötigten Trainingsabfragen für Workload-getrieben Komponenten zu reduzieren, bevor wir (ii) datengetriebenes Lernen vorschlagen, das die in der Datenbank gespeicherten Daten als Trainingsdaten anstelle von Abfragen verwendet, und (iii) gelernte Zero-Shot-Komponenten einführen, die out-of-the-Box auf neue Datenbanken verallgemeinert werden können, d.h. bei denen keine Trainingsdatenerfassung erforderlich ist.

Zunächst haben wir als Ziel, die Anzahl der für Workload-getriebene Komponenten erforderlichen Trainingsabfragen zu reduzieren, indem wir Simulationsmodelle verwenden, um die grundlegenden Effekte des zugrunde liegenden Problems zu vermitteln, z.B. dass bei der Datenbankpartitionierung die Netzwerkkosten für das Verteilen von Tupeln über das Netzwerk für Joins der dominierende Faktor sind. Dies reduziert die Anzahl der Trainingsabfragen erheblich, da die grundlegenden Prinzipien bereits durch das Simulationsmodell abgedeckt sind und somit nur noch die Feinheiten, die nicht durch das Simulationsmodell erfasst sind, durch Beobachtung von Abfrageausführungen erlernt werden müssen, was wir für das Problem der Datenbankpartitionierung demonstrieren werden. Eine alternative Richtung ist, Domänenwissen (z.B. könnten wir in einem Kostenmodell kodieren, dass die Scankosten linear mit der Anzahl der Tupel ansteigen) in die Komponenten einzubauen, indem wir sie mit differenzierbarer Programmierung entwerfen. Dies reduziert die Anzahl der lernbaren Parameter und damit auch die Anzahl der erforderlichen Trainingsabfragen erheblich. Wir demonstrieren die Machbarkeit des Ansatzes für das Problem der Kostenabschätzung in Datenbanken. Obwohl beide Ansätze die Anzahl der Trainingsabfragen reduzieren, ist immer noch eine erhebliche Anzahl von Trainingsabfragen für ungesehene Datenbanken erforderlich.

Dies motiviert unseren zweiten Ansatz des datengetriebenen Lernens. Wir schlagen insbesondere vor, die Datenbankkomponente zu trainieren, indem wir die Datenverteilung in einer Datenbank lernen, anstatt die Ausführung von Abfragen zu beobachten. Dies macht nicht nur das Sammeln von Trainingsdaten überflüssig, sondern kann sogar den Stand der Technik bei Problemen wie der Kardinalitätsschätzung oder AQP verbessern. Während wir die Anwendbarkeit auf eine breite Auswahl zusätzlicher Datenbankaufgaben wie die Vervollständigung unvollständiger relationaler Datensätze demonstrieren, ist datengetriebenes Lernen nur für Probleme nützlich, bei denen die Datenverteilung ausreichende Informationen für die zugrunde liegende Datenbankaufgabe liefert. Für Aufgaben, bei denen Beobachtungen von Abfrageausführungen unverzichtbar sind, wie z.B. bei der Kostenschätzung, kann datengetriebenes Lernen jedoch nicht genutzt werden.

In einer dritten Richtung schlagen wir daher Zero-Shot-gelernte Datenbankkomponenten vor, die auf eine breitere Palette von Aufgaben anwendbar sind, einschließlich solcher, die Beobachtungen von Abfragen erfordern. Motiviert durch die jüngsten Fortschritte im Transfer-Lernen schlagen wir vor, ein Modell einmalig auf einer Vielzahl von Datenbanken und Arbeitslasten vorzutrainieren und so der Komponente zu ermöglichen, sofort auf unbekannte Datenbanken zu generalisieren. Ähnlich wie beim datengesteuerten Lernen müssen also keine Trainingsabfragen gesammelt werden. In dieser Dissertation zeigen wir, dass Zero-Shot-Learning tatsächlich gelernte Kostenmodelle hervorbringen kann, die Abfragelatenzen auf gänzlich unbekannten Datenbanken genauer vorhersagen können als moderne Workload-getriebene Ansätze, die zehntausende von Abfrageausführungen auf jeder unbekannten Datenbank erfordern.

Insgesamt liefern die vorgeschlagenen Verfahren für viele Datenbankaufgaben eine Leistung auf dem neuesten Stand der Technik, während die teure Erhebung von Trainingsdaten für unbekannte Datenbanken erheblich reduziert oder ganz vermieden wird. Während die vorgeschlagenen Richtungen die vorherrschende Datenineffizienz von gelernten Datenbankkomponenten adressieren, gibt es jedoch noch viele Möglichkeiten, gelernte Komponenten in Zukunft zu verbessern. Erstens sollten die Robustheit und die Debugging-Fähigkeit der gelernten Komponenten verbessert werden, da sie derzeit nicht die gleiche Transparenz wie Standardcode in Datenbanken bieten, was die Komponenten für den Einsatz in Produktionssystemen weniger attraktiv machen kann. Um die Anwendbarkeit von datengetriebenen Modellen zu erhöhen, ist es außerdem wünschenswert, die Abdeckung der unterstützten Abfragen zu erhöhen, z.B. Abfragen mit Wildcard-Prädikaten auf String-Spalten, die derzeit nicht von datengetriebenem Lernen unterstützt werden. Schließlich könnten in Zukunft viele weitere Aufgaben durch Zero-Shot-Modelle unterstützt werden (z.B. Abfrageoptimierung), was vollständige Zero-Shot-gelernte Systemen ermöglichen könnte.