Vektordatenbank, relationale Datenbank oder Objektspeicher – was gehört wohin?
Kurz gesagt
Nein. Die häufigste Fehlannahme ist, eine Vektordatenbank sei der zentrale Speicher einer KI-Anwendung. Tatsächlich brauchen produktive Systeme mehrere spezialisierte Speicher: eine relationale Datenbank als verbindliche Quelle für Kunden, Aufträge und Zustände, einen Objektspeicher für Originaldokumente, einen Such- oder Vektorindex für das Auffinden von Inhalten sowie ein Ereignisprotokoll und einen Cache. Jeder Speicher hat einen klaren Zweck – keiner ersetzt die anderen.
Die relationale Datenbank bleibt die Autorität
Für Kunden, Aufträge, Rollen, Zustände, Freigaben und Abrechnung zählen Eigenschaften wie Transaktionssicherheit, Integritätsregeln und Isolation zwischen gleichzeitigen Zugriffen mehr als semantische Ähnlichkeit. Diese Eigenschaften liefert eine relationale Datenbank zuverlässig, ein reiner Vektorspeicher dagegen nicht. Ein Vektorindex kann zwar technisch als Erweiterung derselben Datenbank betrieben werden – das kann Konsistenz und Betrieb vereinfachen, ist aber nicht automatisch für jede Datenmenge oder jede geforderte Antwortzeit die optimale Lösung. Entscheidend sind gemessene Werte und die tatsächliche Betriebsfähigkeit, nicht die Produktkategorie an sich.
Volltextindex: für exakte Begriffe unverzichtbar
Ein Volltextindex verarbeitet Begriffe, Wörterbücher, Rangfolgen und Phrasen und ist besonders wertvoll für Eigennamen, Artikelnummern, Paragraphen, Zitate und exakte Fachterminologie. In einem KI-gestützten Suchsystem sollte er nicht vorschnell durch reine Embedding-Suche ersetzt werden – wo exakte Begriffe entscheidend sind, bleibt er das robustere Werkzeug.
Objektspeicher: für Originaldateien, nicht für strukturierte Daten
Ein Objektspeicher eignet sich für Original-PDFs, Bilder, Audiodateien, große Exporte und unveränderte Rohdaten. Die Anwendung sollte dabei zusätzlich Prüfsumme, Dateityp, Größe, Verschlüsselungs- beziehungsweise Zugriffskontext und einen Verweis auf die fachlichen Metadaten speichern. Eine öffentlich erreichbare Adresse für eine Datei ist dabei ausdrücklich kein Rechtemodell – der Zugriffsschutz muss unabhängig davon geregelt sein.
Ereignisprotokoll und Cache: nützlich, aber nie alleinige Wahrheit
Ein Ereignisprotokoll (Event Log) beschreibt Vorgänge über die Zeit hinweg und kann eine Wiederholung sowie mehrere gleichzeitige Konsumenten der Daten ermöglichen. Ein Cache speichert abgeleitete Ergebnisse vorübergehend, um wiederholte Berechnungen zu vermeiden. Beide dürfen aber nie unbemerkt zur einzigen Quelle eines verbindlichen Zustands werden – geht der Cache verloren oder wird das Ereignisprotokoll nicht vollständig verarbeitet, muss der eigentliche, verbindliche Datenstand in der relationalen Datenbank weiterhin korrekt und vollständig sein.
Die Grundregel für die Zuordnung
Für jeden Datentyp lässt sich ein führender Speicher benennen, aus dem abgeleitete Speicher wie Cache oder Suchindex gespeist werden – nicht umgekehrt:
- Kunden- und Auftragsstatus gehören in die relationale Datenbank; Cache und Suchindex sind hier nur abgeleitete Kopien.
- Das Originaldokument gehört in den Objektspeicher; Auszug, Textabschnitte und Embeddings sind daraus abgeleitete Artefakte.
- Die Suchrepräsentation gehört in den Volltext- oder Vektorindex; ein Abfrage-Cache ist davon abgeleitet.
- Ereignisse gehören ins Ereignisprotokoll oder in eine Warteschlange, je nach Zweck; daraus lassen sich zusammengefasste Sichten ableiten.
- Sitzungszustand und Erinnerung gehören in einen Sitzungsspeicher beziehungsweise Memory-Speicher mit Herkunftsnachweis; der aktuelle Promptkontext ist daraus nur abgeleitet.
Für jeden abgeleiteten Speicher gilt: Nur die eigentliche Transaktion im führenden Speicher verändert den verbindlichen Zustand. Jeder Indexeintrag sollte auf seine Quelle und Version verweisen, Ereignisse und Schemata sollten versioniert werden, und für abgeleitete Daten braucht es klare Aufbewahrungsfristen und eine saubere Mandantentrennung.