Betriebsdatenbanken: Wie sie funktionieren und wann man sie einsetzt

Betriebsdatenbanken – auch Online Transaction Processing (OLTP)-Datenbanken genannt – sind für die Verarbeitung von Transaktionen in Echtzeit konzipiert, die den täglichen Geschäftsbetrieb unterstützen. Betriebsdatenbanken sind darauf ausgelegt, Daten schnell zu speichern und abzurufen und den konstanten Strom von Erstellungs-, Lese-, Aktualisierungs- und Löschvorgängen zu verarbeiten, der Anwendungen am Laufen hält und sicherstellt, dass Transaktionen korrekt und zuverlässig abgeschlossen werden.

Diese Anleitung behandelt, wie Betriebsdatenbanken funktionieren, wie sie sich von analytischen Systemen unterscheiden und was erforderlich ist, um sie für Workloads mit hohem Durchsatz und niedriger Latenz in modernen Cloud- und verteilten Umgebungen zu entwerfen.

Kernmerkmale einer Betriebsdatenbank

Betriebsdatenbanken sind darauf ausgelegt, Transaktionsdaten in Echtzeit für den Live-Betrieb effizient und zuverlässig zu speichern und zu aktualisieren. Die Kernmerkmale, die Betriebsdatenbanken definieren, sind:

• Echtzeitverarbeitung: Daten werden sofort geschrieben und sind verfügbar, nicht in Batches. Transaktionen werden in Millisekunden abgeschlossen, sodass Anwendungen immer den neuesten Stand des Geschäfts widerspiegeln.
• CRUD-Operationen: Vier grundlegende Operationen – Create (Erstellen), Read (Lesen), Update (Aktualisieren), Delete (Löschen) – treiben transaktionale Anwendungen an. Jede Benutzerinteraktion, vom Absenden eines Formulars bis zum Abschluss einer Zahlung, löst eine oder mehrere dieser Operationen aus.
• Datenaktualität: Datenbanken speichern Daten im aktuellen Zustand. Bei Lagerbestandsoperationen spiegeln die Daten beispielsweise den aktuellen Lagerbestand wider, nicht den des letzten Quartals. Dies ist entscheidend für operative Entscheidungen und kundenorientierte Systeme.
• Hohe Nebenläufigkeit: Nebenläufigkeitskontrollmechanismen stellen sicher, dass überlappende Transaktionen keine gemeinsamen Daten beschädigen. Tausende von Benutzern können gleichzeitig lesen und schreiben, ohne Konflikte oder Fehler.
• ACID-Garantien: Datenbanken erzwingen ACID-Eigenschaften (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit), um sicherzustellen, dass nur gültige, vollständige Transaktionen gespeichert werden und die Datenintegrität gewahrt bleibt. Jede Transaktion wird entweder korrekt abgeschlossen oder gar nicht.

Betriebsdatenbanken vs. Data Warehouses

Eine Betriebsdatenbank ist für die Speicherung und Verwaltung von Echtzeitdaten zur Unterstützung der laufenden Geschäftsprozesse eines Unternehmens konzipiert. Im Gegensatz dazu ist ein Data Warehouse ein strukturiertes Repository, das Daten für Business Intelligence und Analysen bereitstellt. Daten werden bereinigt, transformiert und in ein Schema integriert, das für Abfragen und Analysen optimiert ist.

Obwohl sowohl Betriebsdatenbanken als auch Data Warehouses Geschäftsdaten speichern, arbeiten sie unterschiedlich und dienen unterschiedlichen Zwecken.

Für die meisten Unternehmen stellt sich nicht die Frage nach entweder/oder – sie benötigen beide Arten von Datensystemen. Betriebsdatenbanken ermöglichen geschäftskritische Transaktionen und erfassen die Daten aus diesen Transaktionen, die oft an Data Warehouses weitergeleitet werden, um weitere Analysen und Erkenntnisse zu ermöglichen. Zunehmend verschwimmt die Grenze zwischen Betriebsdatenbanken und Data Warehouses, da Lakehouse-Architekturen betriebliche und analytische Workloads auf einer einzigen Plattform vereinigen. Diese Konvergenz ermöglicht es Unternehmen, von Batch-Berichten zu nahezu Echtzeit-Analysen überzugehen und die Zeit zwischen Transaktion und Erkenntnis zu verkürzen.

OLTP vs. OLAP: Verstehen der Verarbeitungsmodelle

Sowohl OLTP- als auch Online Analytical Processing (OLAP)-Modelle sind für die Verwaltung und Analyse großer Datenmengen unerlässlich, aber sie sind für unterschiedliche Aufgaben konzipiert und dienen unterschiedlichen Zwecken. Während sich OLTP auf die effiziente und zuverlässige Speicherung und Aktualisierung von Transaktionsdaten in Echtzeit für den Live-Betrieb konzentriert, ist OLAP für Business Intelligence, Data Mining und analytische Berichterstattung konzipiert.

OLTP-Systeme verarbeiten kurze Transaktionen und führen zeilenbasierte Operationen durch, um alltägliche Geschäftsaktivitäten effizient zu verarbeiten. Sie sind für schreibintensive Workloads optimiert und konzentrieren sich auf die Verarbeitung einer hohen Anzahl kleiner, gleichzeitiger Transaktionen unter Beibehaltung von Geschwindigkeit und Datenintegrität. Typischerweise verwenden sie normalisierte Schemata, um die Datenintegrität zu wahren und Redundanzen zu reduzieren.

OLAP-Systeme hingegen eignen sich hervorragend für die Ausführung komplexer Abfragen und die Durchführung spaltenbasierter Scans zur Analyse großer Datenmengen. Sie sind für leseintensive Operationen wie Aggregation und Analyse optimiert und verwenden häufig denormalisierte Schemata zur Verbesserung der Abfrageleistung.

Unternehmen nutzen oft sowohl OLTP- als auch OLAP-Datenverarbeitung für umfassende Business Intelligence. Die OLTP-zu-OLAP-Pipeline verschiebt Transaktionsdaten, die von Betriebsdatenbanken generiert werden, über Extract, Transform, Load (ETL)- oder Change Data Capture (CDC)-Prozesse in ein Data Warehouse oder Lakehouse, wo Analysten sie zur Entscheidungsfindung abfragen. Ein Operational Data Store (ODS) – eine weitere architektonische Komponente – kann zwischen OLTP- und OLAP-Systemen sitzen, um nahezu Echtzeitdaten aus mehreren Quellen für operative Berichte zu integrieren, ohne die Latenz einer vollständigen Warehouse-Ladung.

Warum traditionelle OLTP-Datenbanken für moderne Workloads unzureichend sind

OLTP-Systeme wurden für schnelle, zuverlässige Transaktionsverarbeitung entwickelt, nicht für analytische oder KI-gesteuerte Workloads. Moderne Anwendungen erfordern jedoch Echtzeit-Analysen, flexiblen Datenzugriff und Integration mit KI-Systemen, was zu einer Kluft zwischen den Stärken traditioneller OLTP-Architekturen und den Anforderungen moderner Systeme führt. Hybride Lösungen können helfen, diese Lücke zu schließen.

Einschränkungen von OLTP-Datenbanken für KI und intelligente Anwendungen

Traditionelle OLTP-Datenbanken verfügen nicht über die Fähigkeiten, moderne KI- und intelligente Anwendungen vollständig zu unterstützen. Sie sind oft von analytischen und KI-Workloads isoliert, was erfordert, dass Daten über langsame ETL-Pipelines verschoben werden, bevor sie verwendet werden können. Sie sind für strukturierte Daten konzipiert, ohne native Unterstützung für unstrukturierte Formate, Embeddings oder Vektorsuche – Fähigkeiten, die für moderne KI-Systeme grundlegend sind. Starre Schemata erschweren eine schnelle Iteration, was für sich schnell entwickelnde agentenbasierte und KI-Anwendungen entscheidend ist. Aus Skalierungssicht erreicht die vertikale Skalierung schnell praktische Grenzen, während die horizontale Skalierung über Sharding die betriebliche Komplexität erhöht. Traditionelle OLTP-Systeme verfügen oft auch über keine entscheidenden Data-Governance-Funktionen, die für den verantwortungsvollen KI-Einsatz erforderlich sind, wie z. B. feingranulare Zugriffskontrollen, Abstammungsverfolgung und Compliance-Funktionen.

Anforderungen moderner Datenanwendungen

Moderne Datenanwendungen erfordern Plattformen, die betriebliche und analytische Workloads ohne Batch-Pipeline-Verzögerungen vereinigen können, was einen Echtzeit-Zugriff auf aktuelle Daten ermöglicht. Sie müssen eine breite Palette von Datentypen – einschließlich strukturierter, semistrukturierter, unstrukturierter und Vektordaten – innerhalb eines einzigen Systems unterstützen, um vielfältige Anwendungsfälle zu ermöglichen. Governance, Sicherheit und Abstammung sollten integriert und nicht nachträglich hinzugefügt werden. Diese Anwendungen erfordern auch eine elastische, serverlose Skalierbarkeit, um unvorhersehbare Workloads effizient zu bewältigen, und eine latenzarme Integration mit KI/ML-Pipelines, Feature Stores und agentengesteuerten Kontexten, um intelligente, reaktionsfähige Systeme zu unterstützen, die auf sich ständig weiterentwickelnden Daten operieren.

Wie Databricks Lakebase die Lücke schließt

Ein Lakebase schließt die Lücken traditioneller OLTP-Systeme. Zu den Hauptmerkmalen eines Lakebase gehören:

• Getrennte Speicherung und Compute: Daten werden kostengünstig in Cloud-Objektspeichern gespeichert, während der Compute unabhängig und elastisch läuft. Dies ermöglicht massive Skalierbarkeit, hohe Nebenläufigkeit und die Möglichkeit, in unter einer Sekunde auf Null zu skalieren.
• Unbegrenzte, kostengünstige, dauerhafte Speicherung: Da die Daten im Lake liegen, sind die Speicherkosten deutlich niedriger als bei traditionellen Datenbanksystemen, die eine Infrastruktur mit fester Kapazität erfordern. Und die Speicherung wird durch die Dauerhaftigkeit des Cloud-Objektspeichers unterstützt.
• Elastischer, serverloser Postgres-Compute: Bietet vollständig verwaltetes, serverloses Postgres, das sich sofort an die Nachfrage anpasst und bei Nichtgebrauch skaliert.
• Sofortiges Branching, Klonen und Wiederherstellen: Datenbanken können wie Code verzweigt und geklont werden.
• Vereinigte transaktionale und analytische Workloads: Lakebase integriert sich nahtlos in das Lakehouse und teilt sich dieselbe Speicherschicht für OLTP und OLAP.
• Offen und Multicloud by Design: In offenen Formaten gespeicherte Daten vermeiden proprietäre Lock-ins und ermöglichen echte Portabilität über Clouds hinweg.

Von operativen Daten zu intelligenten Anwendungen

Operative Daten sind wertvoll, da sie KI-Agenten, Echtzeitentscheidungen und intelligente Anwendungen ermöglichen. Traditionelle operative Datenbanken können Echtzeitdaten effizient speichern und verarbeiten, sind aber nicht für die heutigen Anforderungen ausgelegt. Databricks Lakebase hilft Unternehmen, den vollen Wert operativer Daten für KI-gestützte Anwendungen zu erschließen.

Operative Daten als Grundlage für KI

Jede Transaktion innerhalb eines Unternehmens generiert Daten, die KI-Modelle, Agentenentscheidungen und prädiktive Analysen befeuern können. Databricks Lakebase stellt operative Daten nahezu in Echtzeit für KI bereit, indem die Verzögerung durch die Datenverschiebung von operativen Systemen zum Warehouse eliminiert wird. Infolgedessen können Unternehmen Anwendungsfälle realisieren, wie z. B. KI-Agenten, die auf Live-Inventardaten agieren, Betrugserkennungssysteme, die Transaktionen während ihres Auftretens bewerten, und Copiloten, die auf aktuellen Kontodaten arbeiten.

Aufbauend auf der Databricks Platform

Lakebase basiert auf der Databricks Platform, die Daten, Analysen und KI auf einer einzigen Plattform vereint.

• Delta Lake bietet eine zuverlässige Grundlage mit ACID-Transaktionen, Zeitreisen und Schemaerzwingung im Lakehouse-Maßstab für operative Daten, die vertrauenswürdig und flexibel sind
• Mosaic AI verbindet operative Daten direkt mit dem Modelltraining, Fine-Tuning, Agenten und RAG und ermöglicht eine nahtlose KI-Entwicklung auf Live-Daten
• Unity Catalog liefert eine einzige, konsistente Governance-Schicht mit einheitlichen Berechtigungen und End-to-End-Lineage über alle Daten hinweg
• Serverless SQL und integriertes Streaming unterstützen Echtzeitabfragen und kontinuierliche Erfassung, ohne dass Infrastruktur verwaltet werden muss

Erste Schritte mit Databricks Lakebase

Um mit Databricks Lakebase zu beginnen, verbinden Sie Ihre vorhandenen OLTP-Systeme über CDC- oder Streaming-Pipelines mit Delta Lake und eliminieren Sie so die Notwendigkeit einer Batch-orientierten Datenbewegung. Nach der Erfassung sind operative Daten sofort auf der gesamten Plattform verfügbar, sodass SQL-Analysen, BI-Dashboards, ML-Workflows und KI-Agenten auf frischen, kontinuierlich aktualisierten Daten operieren können. Dieser optimierte Ansatz ermöglicht es Teams, schnell von der Erfassung zu Erkenntnissen und Aktionen zu gelangen, ohne die traditionellen Verzögerungen oder die Komplexität separater Systeme.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag