OLAP vs. OLTP: Analyse und Transaktionen unterscheiden

OLTP verarbeitet einzelne Geschäftsvorfälle zuverlässig: einen Auftrag anlegen, eine Zahlung verbuchen, einen Bestand ändern. OLAP wertet viele Vorgänge aus: Umsatz nach Monat und Region vergleichen, Abweichungen untersuchen, Trends erkennen. Das sind Schwerpunkte von Arbeitslasten, keine starre Trennung zwischen zwei Datenbankmarken. Ein System kann beides unterstützen; ob es Ihre Anforderungen gleichzeitig erfüllt, muss an der konkreten Last geprüft werden. Microsoft beschreibt neben getrennten Architekturen auch hybride transaktionale und analytische Verarbeitung (HTAP). Quelle: Microsoft Azure Architecture Center zu OLTP und zu OLAP.

OLAP vs. OLTP im direkten Vergleich

Die Gegenüberstellung beschreibt typische Anforderungen, keine Verbote. Microsoft nennt für OLTP unter anderem atomare und konsistente Transaktionen sowie normalisierte Datenmodelle; OLAP zielt auf leseintensive Berechnungen und Aggregationen. Gleichzeitig nennt die Dokumentation Ausnahmen und hybride Verfahren. Quelle: OLTP und OLAP.

Ein Auftrag ist eine Transaktion – zehn Aufträge werden zur Analyse

Angenommen, ein Shop erfasst zehn erfundene Aufträge. In der operativen Anwendung muss Auftrag 6 über 90 € zuverlässig gespeichert werden; gleichzeitig darf eine fehlgeschlagene Zahlung keinen widersprüchlichen Zustand erzeugen. Das ist die transaktionale Frage. Für eine BI-Frage werden dieselben Aufträge nach Monat und Region gruppiert. Jede Zeile ist hier genau ein Auftrag mit einem festgelegten Nettoumsatz in Euro; Retouren und Korrekturen sind ausgeschlossen.

Die analytische Frage „Wie entwickelt sich der Umsatz?“ liefert 410 € im Januar und 340 € im Februar. Nord kommt insgesamt auf 400 €, Süd auf 350 €. Wer Januar und Nord gemeinsam filtert, erhält 240 € aus Auftrag 1, 2 und 5. Das Ergebnis ist bei zehn Zeilen leicht im operativen System zu berechnen. Bei Millionen Vorgängen, weiteren Datenquellen und vielen parallelen Berichten werden Abfrageform, Ressourcenverbrauch und Aktualisierungspfad zum Architekturthema. Eine prinzipielle Unmöglichkeit, direkt auf OLTP-Daten zu berichten, folgt daraus nicht. Microsoft weist darauf hin, dass große Aggregationen OLTP-Systeme belasten können, und nennt ausdrücklich Ausnahmen bei gut geplanter Struktur. Quelle: Microsoft.

Warum können sich beide Arbeitslasten stören?

Ein Auftragsschreibvorgang und eine breite analytische Abfrage beanspruchen unterschiedliche Ressourcen. Die eine Arbeit betrifft wenige konkrete Datensätze und verlangt einen konsistenten Zustand. Die andere liest unter Umständen viele Zeilen, verbindet Tabellen und berechnet Gruppenwerte. Treffen beide unter hoher Last auf dieselbe Infrastruktur, können Speicher, CPU und Ein-/Ausgabe zum Engpass werden; je nach Datenbank und Isolation können auch Sperren eine Rolle spielen. Ob das in Ihrer Umgebung geschieht, lässt sich nur anhand realer Abfragen und Last messen. Eine feste Aussage wie „OLAP ist 10- bis 100-mal schneller“ ist ohne Datensatz, Abfrage, Indexe und Hardware wertlos.

Normalisierte Datenmodelle helfen häufig, transaktionale Änderungen widerspruchsfrei zu halten. Für Berichte brauchen Fachleute dann oft mehrere Joins und eindeutige Kennzahlendefinitionen. Analytische Modelle können diese Logik zugänglicher machen; ein Sternschema ist eine verbreitete Möglichkeit, aber keine Bedingung für OLAP. Auch ein Spaltenspeicher kann bestimmte Scans und Aggregationen begünstigen, ist jedoch nicht mit OLAP gleichzusetzen. Microsoft beschreibt OLAP sowohl mit multidimensionalen Würfeln als auch mit tabellarischen Modellen und nennt hybride Datenbankfunktionen. Quelle: Microsoft Azure Architecture Center.

Wann lohnt ein eigener Analysepfad?

Ein getrennter Analysepfad ist besonders prüfenswert, wenn Berichte operative Prozesse spürbar beeinträchtigen, mehrere Quellsysteme zusammengeführt werden müssen oder Kennzahlen über längere Zeit vergleichbar sein sollen. Ein möglicher Weg lautet: Ereignisse im OLTP-System erfassen, sie in eine analytische Datenbasis übernehmen, dort Geschäftsregeln und Historisierung festlegen und Berichte darauf ausführen. Wie oft Daten übernommen werden, richtet sich nach der Entscheidung, die der Bericht unterstützt. Ein Monatsabschluss braucht andere Frische als ein Bestandsalarm.

Die Trennung kostet ebenfalls etwas: Übernahmefehler, Verzögerung, zusätzliche Speicherung und die Pflege zweier Zustände. Definieren Sie deshalb vorab, welche Quelle für welchen Vorgang maßgeblich ist, wie Korrekturen ankommen und welchen Zeitstempel ein Bericht zeigt. Bei kleinen Datenmengen oder begrenzten Berichten können gut geplante Abfragen, eine Replik oder hybride Verfahren ausreichen. Microsoft beschreibt HTAP als Arbeitslast mit transaktionalen und analytischen Anteilen und nennt Columnstore-Indizes als eine mögliche technische Umsetzung. Quelle: Microsoft.

Ein pragmatischer Entscheidungstest: Messen Sie die wichtigsten Berichte unter realistischer Parallelität, während typische Schreibvorgänge laufen. Prüfen Sie dann Korrektheit, Antwortzeit, Auswirkungen auf Buchungen, Datenfrische und Betriebsaufwand. Erst wenn die Anforderungen klar sind, wählen Sie eine Architektur. Für die begriffliche Grundlage lesen Sie Was OLAP bedeutet; die Produktauswahl liegt im Verzeichnis OLAP-Datenbanken.

Vier häufige Irrtümer

„OLTP speichert nur aktuelle Daten.“ Transaktionssysteme können Bestellungen, Ereignisse und Änderungen über Jahre bewahren. Ob Historie vorhanden und für eine bestimmte Analyse nutzbar ist, hängt vom Datenmodell und von Aufbewahrungsregeln ab. Umgekehrt historisiert eine analytische Kopie geänderte Stammdaten nicht automatisch. Microsoft beschreibt lange Transaktionshistorien sogar als möglichen Performancefaktor, nicht als Widerspruch zum OLTP-Begriff. Quelle: Microsoft.

„OLAP hat nur wenige Nutzer.“ Analytische Arbeitslasten können von einer kleinen Controllinggruppe oder von vielen Dashboard-Nutzern kommen. Die Zahl der gleichzeitigen Abfragen ist eine Auslegungsgröße. Die Apache-Pinot-Dokumentation beschreibt ausdrücklich nutzerseitige Analyse-Dashboards mit hoher Parallelität als Anwendungsfall – das ist ein Produktbeispiel, kein Leistungsversprechen für Ihre Umgebung.

„OLAP bedeutet Echtzeit.“ Das Akronym „online“ beschreibt die interaktive Analyse, nicht eine garantierte Latenz vom Ereignis bis zum Bericht. Ein Würfel kann periodisch aktualisiert werden; andere Systeme arbeiten mit frischen Ereignissen. Datenfrische muss als konkrete Zeitspanne vereinbart und Ende zu Ende geprüft werden. Microsoft dokumentiert sogar unterschiedliche Aktualisierungs- und Speicheroptionen innerhalb eines OLAP-Produkts.

„Für OLAP braucht man zwingend einen Cube und ein Star Schema.“ Traditionelle multidimensionale Modelle nutzen Cubes; tabellarische Modelle und analytische Abfragen auf relationalen Daten sind weitere Wege. Für ein durchgerechnetes Beispiel mit Dimensionen, Kennzahlen und Drill-down lesen Sie OLAP-Würfel: Rechenweg. Microsoft stellt tabellarische und multidimensionale Modelle explizit gegenüber. Quelle: Microsoft Learn.

Die tragfähige Abgrenzung bleibt eine Frage: Wollen Sie einen Vorgang korrekt verändern oder viele Vorgänge für eine Entscheidung verstehen? Daraus folgen die Anforderungen an Konsistenz, Modell, Antwortzeit und Datenfrische. Eine allgemeine „Siegertechnologie“ gibt es ohne diese Anforderungen nicht.