Towards Effective Orchestration of AI x DB Workloads

Dieser Artikel beleuchtet die Herausforderungen und Lösungsansätze für die effiziente Orchestrierung von KI- und Datenbank-Workloads, indem er eine integrierte Architektur vorschlägt, die Performance, Sicherheit und Datenintegrität in heterogenen Systemen verbessert.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungspapiers „Towards Effective Orchestration of AI x DB Workloads" auf Deutsch, verpackt in anschauliche Bilder und Metaphern.

Das große Problem: Der umständliche Umzug

Stellen Sie sich vor, Sie haben eine riesige Bibliothek (die Datenbank), in der alle Ihre Bücher, Daten und Informationen perfekt sortiert sind. Daneben steht ein genialer, aber etwas chaotischer Assistent (die Künstliche Intelligenz oder KI), der diese Bücher lesen und analysieren soll, um Ihnen die beste Antwort zu geben.

Wie es heute läuft (das alte System):
Der Assistent muss erst alle relevanten Bücher aus der Bibliothek heraustragen, sie in sein eigenes, kleines Arbeitszimmer bringen, sie dort lesen, seine Notizen machen und dann die Ergebnisse zurück in die Bibliothek tragen.

• Das Problem: Das ist extrem langsam. Es kostet viel Energie (Rechenleistung), die Bücher sind unterwegs unsicher (Sicherheitsrisiko), und wenn sich im Arbeitszimmer etwas ändert, während die Bücher noch unterwegs sind, sind die Daten veraltet. Es ist wie ein ständiger Umzug, der nur Zeit kostet.

Die Lösung: Ein neues Haus mit integriertem Assistenten

Die Autoren dieses Papiers schlagen vor, die Bibliothek und den Assistenten nicht mehr zu trennen. Sie wollen eine neue Art von Datenbank bauen, in der der Assistent direkt im Regal sitzt und die Bücher sofort lesen kann, ohne sie bewegen zu müssen.

Sie nennen dieses Konzept „AI×DB" (Künstliche Intelligenz mal Datenbank). Das Ziel ist es, dass die Datenbank nicht nur Daten speichert, sondern die KI-Aufgaben direkt dort erledigt, wo die Daten liegen.

Die drei goldenen Regeln für dieses neue Haus

Damit das funktioniert, müssen drei Dinge anders gemacht werden:

1. Der perfekte Taktgeber (Ganzheitliche Optimierung)

Stellen Sie sich vor, die Bibliothek hat einen Chef, der entscheidet, wer was macht.

• Alt: Der Chef sagt: „Du, Assistent, nimm diese Bücher und lies sie." Dann sagt er: „Du, Bibliothekar, sortiere diese Bücher." Beide arbeiten getrennt und wissen nicht, was der andere tut.
• Neu: Der Chef denkt: „Wenn der Assistent diese Bücher liest, kann der Bibliothekar schon mal die nächsten Bücher vorbereiten, die der Assistent gleich braucht." Sie arbeiten Hand in Hand.
• Das Ziel: Alles wird gemeinsam geplant, damit keine Zeit verloren geht. Die Datenbank weiß genau, wie lange die KI braucht, und die KI weiß, wie schnell die Datenbank liefert.

2. Der gemeinsame Werkzeugkasten (Einheitlicher Cache)

Stellen Sie sich vor, der Assistent hat oft das gleiche Buch in der Hand, das er für verschiedene Fragen braucht.

• Alt: Jedes Mal, wenn er das Buch braucht, holt er es neu aus dem Keller. Das ist mühsam.
• Neu: Die Datenbank hat einen „Werkzeugkasten" direkt am Arbeitsplatz. Wenn der Assistent ein Buch oder eine Notiz (ein KI-Ergebnis) einmal gelesen hat, wird es dort abgelegt. Wenn er es wieder braucht, greift er sofort zu, ohne den Weg zum Keller zu gehen.
• Das Ziel: Nichts wird doppelt berechnet oder zweimal heruntergeladen. Das spart Zeit und Strom.

3. Der strenge Türsteher (Feingliedrige Kontrolle)

Da viele Assistenten (KI-Agenten) gleichzeitig in der Bibliothek arbeiten, muss jeder genau wissen, was er darf.

• Alt: Oft darf der Assistent alles sehen, was im Raum ist, auch wenn er nur nach einem bestimmten Buch suchen sollte. Das ist gefährlich für die Privatsphäre.
• Neu: Die Datenbank hat einen sehr cleveren Türsteher. Er sagt: „Du darfst nur die Seiten lesen, die für deine Aufgabe erlaubt sind. Alles andere bleibt verdeckt." Und wenn der Assistent eine Notiz macht, die zu sensibel ist, wird sie sofort wieder gelöscht.
• Das Ziel: Sicherheit und Privatsphäre werden nicht vergessen, nur weil die KI arbeitet.

Der Prototyp: „NeurEngine"

Die Forscher haben einen ersten Entwurf gebaut, den sie NeurEngine nennen.

• Sie haben getestet, wie gut das System funktioniert, wenn viele Leute gleichzeitig Fragen stellen.
• Das Ergebnis: Das neue System ist viel schneller als das alte. Es nutzt die Grafikkarten (die starken Gehirne der KI) viel effizienter aus und schafft es, mehr Fragen pro Minute zu beantworten, ohne dass die Antwortqualität leidet.

Zusammenfassung in einem Satz

Statt die Daten aus dem Haus zu tragen, um sie im Labor zu bearbeiten, bringen wir das Labor direkt in das Haus, damit die Arbeit schneller, sicherer und effizienter erledigt wird.

Dieser Ansatz ist der Schlüssel dafür, dass KI-Agenten in Zukunft nicht nur einfache Fragen beantworten, sondern komplexe Aufgaben direkt mit unseren Datenbanken lösen können, ohne dass wir uns um Geschwindigkeit oder Sicherheit sorgen müssen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Towards Effective Orchestration of AI x DB Workloads" auf Deutsch:

Titel: Towards Effective Orchestration of AI x DB Workloads

Autoren: Naili Xing et al. (NUS, BIT, RUC, ZJU)

---

1. Problemstellung

Der aktuelle Standard für datenzentrierte KI-Anwendungen folgt einem ineffizienten „Export-Execute-Import"-Paradigma. Daten werden aus der Datenbank extrahiert, in externen Laufzeitumgebungen (z. B. Python/PyTorch) verarbeitet und die Ergebnisse zurückgeschrieben. Dies führt zu mehreren kritischen Problemen:

• Hoher Overhead: Datenübertragung und Kontextwechsel verursachen Latenz.
• Fehlende Robustheit: Schwierigkeiten beim Umgang mit Daten-Drift (Änderungen in den Datenverteilungen).
• Sicherheitsrisiken: Erweiterte Angriffsfläche, insbesondere in Multi-Tenant-Umgebungen.
• Inkompatible Paradigmen: Datenbanken sind für globale Optimierung, deklarative Abfragen und strenge Zugriffskontrolle ausgelegt, während KI-Laufzeiten lokale Modelloptimierung priorisieren und globale Orchestrierung oft extern regeln.
• Black-Box-Problem: KI-Operatoren werden als undurchsichtige Einheiten behandelt, was eine gemeinsame Optimierung von relationalen und KI-Operatoren sowie eine feingranulare Zugriffskontrolle verhindert.

Das Ziel des Papers ist es, eine datenbanknative Orchestrierung zu etablieren, bei der KI-Operatoren und ihre Artefakte als „First-Class Citizens" innerhalb des Datenbankkerns behandelt werden.

---

2. Methodik und Design-Prinzipien

Die Autoren definieren den AI×DB-Workload als einen Stream von Abfragen, die relationale Verarbeitung mit KI-Ausführungen (Training, Feinabstimmung, Inferenz) verflechten. Diese Workloads zeichnen sich durch drei Merkmale aus:

1. Iterativ: Adaptive Schleifen zur Verfeinerung von Ergebnissen.
2. Konkurrent: Burst-artige Parallelität durch KI-Agenten.
3. Teilbar: Hohe Überlappung bei Datenabrufen und Berechnungen über Iterationen hinweg.

Basierend darauf werden drei Kernprinzipien für das neue Datenbank-Design abgeleitet:

A. Ganzheitliche AI×DB-Co-Optimierung

Statt KI und Datenbank separat zu optimieren, soll der Optimierer beide Domänen gemeinsam betrachten:

• Gemeinsame Optimierung: Wahl physischer Implementierungen für DB- und KI-Operatoren unter Berücksichtigung von Qualitäts- und Latenzgrenzen.
• Cross-Operator-Vereinfachung: Push-Down von Prädikaten durch Feature-Pipelines, um irrelevante Modell-Subgraphen zu überspringen.
• Cross-Query-Optimierung: Wiederverwendung von Caches und Subplänen über parallele Abfragen hinweg.

B. Einheitliches AI×DB-Cache-Management

• Schaffung einer einheitlichen Abstraktion für heterogene Artefakte (Embeddings, Key-Value-Caches, Modellzustände).
• Intelligente Platzierung und Eviction-Strategien, die über traditionelle LRU/FIFO-Policies hinausgehen und die spezifischen Zugriffsmuster von KI-Modellen (z. B. Token-basierte Kosten bei Generativen Modellen) berücksichtigen.

C. Feingranulare Zugriffskontrolle und Isolation

• Access Control: Sicherstellung, dass KI-Inferenz nur auf autorisierten Daten basiert (Vermeidung von Modell-Leaks durch unautorisierte Features).
• Isolation: Anpassung der Transaktionsmechanismen an heterogene Workloads (kurze Updates vs. lange KI-Tasks) und Unterstützung von „forkable" Transaktionen für KI-Agenten, die parallele Lösungspfade erkunden.

---

3. Architektur: NeurEngine

Als Proof-of-Concept wurde NeurEngine entwickelt, ein Prototyp, der auf einer disaggregierten CPU/GPU-Infrastruktur läuft und auf PostgreSQL basiert.

• Schnittstelle: Erweiterung von SQL um PREDICT (für Inferenz) und TRAIN ON (für Feature-Definition).
• Holistischer Compiler & Optimierer:
  • Wandelt logische Pläne in physische Pläne um.
  • Sucht im gemeinsamen Raum von DB- und KI-Implementierungen (z. B. Geräte-Platzierung, Modell-Auswahl).
  • Nutzt Cache-Wissen, um Subpläne wiederzuverwenden (siehe Abbildung 2 im Paper).
• Self-Driving Execution Engine:
  • Reconciliert (versöhnt) stream-basierte DB-Verarbeitung mit batch-basierten KI-Ausführungen durch dynamisches Batching.
  • Führt Common Subexpression Elimination (CSE) über Abfragen hinweg durch, um redundante Berechnungen zu vermeiden.
  • Unterstützt dynamisches Rescheduling: Bei Überlastung (z. B. GPU-Speicher) werden laufende Anfragen und ihre Zustände (inkl. KV-Caches) auf andere Instanzen migriert.
• Shared Buffer Manager: Verwaltet Daten und Modellartefakte in einem gemeinsamen Speicherpool und lernt aus Runtime-Telemetrie, um Platzierung und Prefetching zu optimieren.

---

4. Ergebnisse (Evaluation)

Die Evaluation erfolgte auf einem Server mit 8 NVIDIA RTX 3090 GPUs unter Verwendung zweier Workloads (Empfehlungssystem und Text-Embeddings).

• Skalierbarkeit: NeurEngine skaliert nahezu linear mit der Anzahl der KI-Engines (bis zu 16), während Baseline-Systeme (externe Aufrufe) aufgrund von Datenübertragungs-Overhead und fehlender Co-Optimierung nur geringe Beschleunigungen zeigen.
• Multi-Tenant-Performance: Unter hoher Konkurrenz (8 gleichzeitige Mieter) erreicht NeurEngine einen höheren Durchsatz als Baselines mit isolierten Modellen oder sequentiellem Batching.
• Speichereffizienz: Durch das Teilen von Modellinstanzen und intelligentes Batching (Bucketing nach Sequenzlänge) reduziert NeurEngine den GPU-Speicherverbrauch signifikant im Vergleich zu dedizierten Modell-Instanzen pro Mieter.
• Latenz: Die dynamische Rescheduling-Funktion hilft, Tail-Latenzen bei Lastspitzen zu stabilisieren.

---

5. Bedeutung und Ausblick

Das Paper leistet einen wesentlichen Beitrag zur Forschung, indem es:

1. Ein neues Paradigma etabliert: Es schlägt vor, KI nicht als externes Add-on, sondern als integralen Bestandteil des Datenbankkerns zu behandeln.
2. Lücken schließt: Es adressiert die Lücke zwischen relationaler Optimierung und KI-Ausführung, insbesondere in Bezug auf Co-Optimierung, Caching und Sicherheit.
3. Eine Forschungsagenda definiert: Es identifiziert offene Herausforderungen wie die Modellierung von Kosten/Qualität für generative Modelle, die Sicherheit von KI-Abfragen und adaptive Transaktionsmechanismen.
4. Praktische Machbarkeit zeigt: Mit NeurEngine wird demonstriert, dass eine native Orchestrierung signifikante Leistungs- und Effizienzgewinne bietet.

Zusammenfassend fordert das Paper die Datenmanagement-Community auf, Datenbank-Designs neu zu überdenken, um effiziente, ressourcenschonende und governable AI×DB-Engines zu entwickeln, die die wachsende Komplexität von KI-Agenten und datenzentrierten Entscheidungen bewältigen können.