Operativ oder analytisch? Warum Preisdaten in zwei Datenbanken liegen

Wie trennt man operative und analytische Daten? Warum Senkrondata bei Millionen Preisdatensätzen die OLTP- und die OLAP-Schicht auseinanderhält.

Auf der einen Seite schreiben über 200 Crawler täglich Millionen Preiszeilen. Auf der anderen fragt ein Kunde einen Bericht an: „Preisverlauf dieser 50.000 Produkte über die letzten 6 Monate." Beide Aufgaben klingen nach „denselben Daten", belasten eine Datenbank aber völlig unterschiedlich — und in einem System vermischt, bremsen sie einander aus.

Das ist eine klassische Unterscheidung im Data Engineering: operative (OLTP) und analytische (OLAP) Lasten wollen unterschiedliche Optimierungen.

Zwei Lasten, zwei Naturen

Operative Schreibvorgänge sehen so aus: Ein Crawler aktualisiert den Preis eines Produkts — eine einzelne Zeile, häufig, mit niedriger Latenz. Gebraucht wird die Garantie, dass die Daten im Moment des Schreibens konsistent bleiben und zwei gleichzeitige Updates einander nicht beschädigen. Das ist das natürliche Terrain einer relationalen Datenbank, die auf zeilenweise Updates optimiert ist.

Analytische Lesevorgänge sehen so aus: „Welche 1.000 Produkte haben sich im letzten Monat am stärksten im Preis bewegt, aufgeschlüsselt nach Kategorie?" Diese Abfrage scannt, gruppiert und aggregiert Millionen Zeilen. Auf einer zeilenorientierten Datenbank kann so eine Abfrage das System minutenlang blockieren — genau auf den Tabellen, in die die Crawler im selben Moment schreiben wollen.

Beide Lasten auf dieselbe Datenbank zu legen, erzeugt Konkurrenz zwischen ihnen: Eine schwere Berichtsabfrage bremst die tägliche Datenerhebung — oder umgekehrt.

Die Lösung: an einer Stelle schreiben, an einer anderen lesen

Der übliche Weg aus dieser Konkurrenz ist, die beiden Schichten physisch zu trennen:

1. Operative Schicht: die zeilenorientierte relationale Datenbank, in die Crawler und Integrationen schreiben und die „den aktuellen korrekten Zustand" hält.
2. Analytische Schicht: ein getrennter, spaltenorientierter Speicher, optimiert für große Scans und Aggregationen, in regelmäßigen Abständen aus der operativen Schicht gespiegelt.

Die Spiegelung ist einseitig: Daten fließen von operativ nach analytisch, nie zurück. Die Reporting-Engine liest fast ausschließlich aus der analytischen Schicht — ohne die operative Datenbank zu berühren oder zu belasten.

Was das in der Praxis bringt

• Tempo im Reporting: Ein Monatsbericht über Millionen Zeilen antwortet in Sekunden, weil der Spaltenspeicher genau für solche Abfragen gebaut ist.
• Ununterbrochene Datenerhebung: Crawler schreiben weiter, während der schwerste Bericht läuft; keiner blockiert den anderen.
• Unabhängige Skalierung: Wächst die Schreiblast (mehr Crawler) oder die Leselast (mehr Berichte und Analysen), lassen sich beide Schichten getrennt skalieren.

Die Prinzipien, die das Ganze verlässlich halten

• Die operative Schicht ist die einzige Wahrheitsquelle. Die analytische ist eine Kopie; im Konflikt gewinnt die operative.
• Die Spiegelung hat ihre eigene Aktualitätsgarantie. Die analytische Schicht stimmt „zum Stand der letzten Synchronisierung", nicht „gerade eben" — diesen Abstand zu kennen, gehört zur Einordnung, wie aktuell ein Bericht ist.
• Schreiben und Lesen vermischen sich nie. Eine Berichtsabfrage berührt die operative Schicht nie so, dass die Datenerhebung langsamer würde.

Das Wesentliche

„Dieselben Daten" für zwei Zwecke doppelt zu halten, mag verschwenderisch wirken — es ist das Gegenteil. Diese Trennung ist der Entwurf, der ununterbrochene Datenerhebung und schnelles, schweres Reporting gleichzeitig möglich macht. Je größer die Datenmenge, desto stärker zahlt sie sich aus.

Wenn Sie über Millionen Datensätze zugleich schnell erheben und schnell auswerten wollen, sprechen Sie mit dem Senkrondata-Team.