Eine Datenbank, zwei Workloads, viele Probleme: OLTP vs. OLAP P. 1

Für Echtzeit-Transaktionen wird ein Systemtyp benötigt: OLTP (Online Transaction Processing). Für Analysen benötigt man einen anderen: OLAP (Online Analytical Processing). OLTP ist wie Sonic the Hedgehog: ständig in Bewegung, rast mit Höchstgeschwindigkeit vorwärts, reagiert sofort auf Hindernisse und sammelt dabei Ringe ein. OLTP verarbeitet jede Transaktion schnell und vorhersehbar.

OLAP hingegen ist eher wie Kirby – es saugt alles ein, was ihm in den Weg kommt: Objektstapel, Gegner, ganze Welten. OLAP-Systeme nehmen enorme Datenmengen auf, Millionen und Milliarden von Zeilen, um sie später zu verarbeiten und in etwas Sinnvolles zu verwandeln, etwa einen Bericht.

Und weil die Anwendungsfälle so unterschiedlich sind, ist es nur logisch, dass sich auch Serverarchitektur, Speichersysteme und sogar die Datenbank-Engines unterscheiden.
Genau hier kommen wir zum eigentlichen Thema. In diesem Long Read sprechen wir über OLAP, OLTP und die dahinterstehende Hardware.

OLAP und OLTP: Was sie sind und warum es sie gibt Tauchen wir nun etwas tiefer in die Technik ein.

OLAP und OLTP verfolgen völlig unterschiedliche Ziele und basieren auf unterschiedlichen Architekturen. Deshalb besteht für die meisten Unternehmen die eigentliche Herausforderung nicht darin, sich für eines von beiden zu entscheiden, sondern darin, beide sinnvoll innerhalb einer gemeinsamen Infrastruktur zu kombinieren.

OLAP ist ein Werkzeug für komplexe Analysen großer Datenmengen. So gewinnen Unternehmen belastbare analytische Erkenntnisse. Nehmen wir den Lebensmitteleinzelhandel als Beispiel: Das Analytics-Team sammelt alle Verkaufsdaten eines bestimmten Zeitraums aus mehreren Quellen, wie operativen Datenbanken, externen Services und anderen Systemen. Diese Daten werden anschließend in ein spezialisiertes Speichersystem geladen, ein Data Warehouse, das für multidimensionale Analysen optimiert ist.

Danach stellen die Analysten eine Anfrage:

„Wie viel Butter und Brot wurden im Juni 2024 in allen Filialen einer bestimmten Region verkauft, wie haben sich diese Zahlen im Juni 2025 verändert und wie hängen diese Produkte miteinander zusammen?“

Die Beantwortung einer solchen Frage erfordert das Aggregieren von Millionen von Zeilen, das Filtern nach Regionen, Kategorien und Zeiträumen sowie das Berechnen von Korrelationen, Veränderungen und Prognosen. Solche Abfragen können, in vertretbarem Rahmen, lange dauern, und das ist völlig normal, da die Ergebnisse zur Entscheidungsfindung und zur Definition langfristiger Strategien genutzt werden.

Im OLAP-Bereich sind Vollständigkeit und Genauigkeit wichtiger als eine sofortige Antwortzeit. Deshalb können strategische Analysen, wie etwa Jahresberichte oder langfristige Prognosen, ein oder zwei Stunden laufen. Anders sieht es hingegen bei operativen Analysen für tägliche Entscheidungen aus, etwa bei Preisänderungen: Wenn diese Stunden benötigen, ist das meist ein Zeichen für eine ungeeignete Infrastruktur.

Im Kern von OLAP stehen multidimensionale Datenstrukturen (Cubes), die es erlauben, Daten aus verschiedenen Perspektiven zu betrachten, beispielsweise nach Zeit, Region, Produkt oder Kunde. Das macht OLAP zu einem idealen Werkzeug für strategische Analysen. Im Gegensatz dazu zielen CRM-Systeme in erster Linie auf das operative Management von Kunden und Transaktionen ab, nicht auf die Ausführung komplexer Abfragen über Terabytes historischer Verkaufsdaten.

Zu den klassischen OLAP-Tools zählen ClickHouse, Greenplum, Hadoop/Spark und Amazon Redshift. Sie sind für großskalige Verarbeitung und Parallelisierung ausgelegt.

OLTP hingegen ist auf Geschwindigkeit bei der Verarbeitung einzelner Operationen optimiert. An der Supermarktkasse muss jede Transaktion – Scannen eines Artikels, Zahlung, Schreiben des Datensatzes – sofort erfolgen. Jede Verzögerung führt sonst zu längeren Warteschlangen und verärgerten Kunden. Niemand wartet drei Minuten pro Artikel, nur um Butter und Brot zu kaufen.

OLTP-Systeme sind genau für diese schnellen und häufigen Echtzeitoperationen optimiert. Für strategische Analysen sind sie jedoch nahezu ungeeignet, da komplexe Abfragen über riesige Datenmengen nicht zu ihrem Design gehören.

Typische OLTP-Datenbanken sind PostgreSQL, MySQL/InnoDB, Oracle Database und Microsoft SQL Server.

Es gibt auch hybride Ansätze, sogenannte HTAP-Systeme (Hybrid Transactional/Analytical Processing), die versuchen, Transaktionen und Analysen in einem einzigen System zu vereinen. Beispiele hierfür sind TiDB, SAP HANA oder YugabyteDB. In der Praxis trennen die meisten Unternehmen jedoch weiterhin ihre Workloads: Eine Datenbank für schnelle operative Prozesse, eine andere für Analysen. Der Komfort hybrider Systeme geht allerdings mit einer höheren Infrastrukturkomplexität und steigenden Hardwareanforderungen einher.

Und genau an diesem Punkt beginnen IT-Architekten, Administratoren oder andere Verantwortliche, Fragen zu stellen. Welcher Server eignet sich für OLAP, welcher für OLTP? Sollten das getrennte Server sein? Virtuelle Maschinen? Ein Cluster? Rechenknoten mit separatem Storage? Wie viele Speichersysteme werden benötigt? Falls es mehrere sind: Active-Active oder Active-Standby? Und das ist erst der Anfang – es gibt Dutzende, wenn nicht Hunderte ähnlicher Details.

Diese Details wirken sich direkt auf das Geschäft aus.

Ich kann nicht jede mögliche Frage beantworten, da jede Umgebung ihre eigenen Workloads hat, aber ich versuche, brauchbare Orientierungspunkte zu liefern. Und wie immer sind die Kommentare offen.

Wie man Server und Storage für OLTP und OLAP auswählt

Die Auswahl von Servern für OLTP und OLAP sind zwei grundlegend unterschiedliche Aufgaben, und Fehler sind hier teuer. Langsamer Storage unter OLTP führt zu Warteschlangen und unzufriedenen Kunden. OLAP auf ungeeigneter Hardware bedeutet Abfragen, die wochenlang laufen. Einsparungen bei der Redundanz von Daten oder Komponenten … nun, wie das endet, ist bekannt.

In hochbelasteten Datenbanksystemen hängen Performance und Zuverlässigkeit direkt von Architektur und Hardware ab. Doch bevor Hardware beschafft wird, müssen zunächst architektonische Entscheidungen getroffen werden. Beginnen wir mit OLTP.

OLTP-Architektur: Geschwindigkeit und Vorhersagbarkeit

OLTP-Systeme sind die Frontlinie des Geschäfts. Online-Banking, Payment-Gateways und E-Commerce-Plattformen laufen auf ihnen. Diese Systeme haben klare Anforderungen: Zehn- oder hunderttausende Transaktionen pro Sekunde, strikte Latenz-SLAs im Millisekundenbereich und Datenintegrität – der Verlust auch nur eines Transaktionsdatensatzes ist gleichbedeutend mit Geldverlust.

• Jedes Transaktionssystem basiert auf den ACID-Anforderungen (Atomicity, Consistency, Isolation, Durability).

• Vereinfacht gesagt: Eine Transaktion wird vollständig ausgeführt oder gar nicht (Atomicity).

• Daten bleiben in einem konsistenten Zustand (Consistency).

• Parallele Operationen beeinflussen sich nicht gegenseitig (Isolation).

• Daten gehen auch im Fehlerfall nicht verloren (Durability).

Beim Blick auf ein solches System denkt ein IT-Architekt nicht zuerst an Hardware. Die zentralen Fragen sind: Wie werden Daten normalisiert, damit Transaktionen schnell und konsistent bleiben? Wie wird Last über Sharding und Replikation auf Cluster verteilt? Und wie wird Fehlertoleranz so gestaltet, dass der Ausfall eines – oder sogar mehrerer – Knoten nicht das gesamte System lahmlegt?

Was ist also das Fazit?
Wenn Einfachheit wichtig ist und die erwartete Last moderat bleibt, ist eine Kombination aus Replikation und Caching die optimale Wahl, beispielsweise PostgreSQL oder MySQL mit Redis. Wachsen Datenvolumen und Last hingegen linear und ist strikte globale Konsistenz nicht kritisch, sind Shared-Nothing-Architekturen mit Sharding sinnvoller. Hat strikte Konsistenz höchste Priorität und das Budget erlaubt es, sind Shared-Disk-Lösungen wie Oracle RAC die bessere Wahl. Für Systeme mit extremen Performance-Anforderungen oder Echtzeitanalysen lohnt sich der Blick auf In-Memory-Datenbanken.

In der folgenden Tabelle habe ich die wichtigsten Architekturansätze für OLTP-Systeme zusammengefasst.

Das Fazit ist einfach. Optimiert man OLTP wie OLAP, zerstört man die Latenz. Betreibt man OLAP auf einer OLTP-tauglichen Infrastruktur, starren Analysten auf Fortschrittsbalken statt auf Dashboards. Architekturelle Fehlentscheidungen zeigen sich nicht in Benchmarks, sondern in Umsatzeinbußen, gebrochenen SLAs und äußerst unangenehmen Meetings.