Echtzeit-Petabyte-Analysen ohne Auswirkungen auf die Datenbank
Wie analysiert man Petabytes an Daten in Echtzeit, ohne die Produktionsdatenbank zu verlangsamen?
Wachsende Anwendungen erreichen alle denselben Wendepunkt, an dem ein Unternehmen eine PostgreSQL- oder MySQL-Datenbank mit Petabytes an Daten auf eine Weise abfragen möchte, für die sie nie konzipiert wurde.
Das Ergebnis: Eine Dashboard-Abfrage, die 200ms dauern sollte, dauert 40 Sekunden, da die Analyse 500M Zeilen scannt und CPU sowie I/O überlastet. Benutzer warten zu lange auf Abfrageergebnisse, und am Ende steht die gesamte SLA-Vereinbarung auf dem Spiel.
Es ist kein Problem, das Sie durch Tuning beheben können; stattdessen erfordert es eine Änderung der Architektur: Sie müssen aufhören, schwere Abfragen auf Ihrer Produktionsdatenbank auszuführen.
In diesem Artikel erfahren Sie das Architekturmuster zur Trennung von OLTP und OLAP, wie Sie Daten sicher in ClickHouse streamen und warum der Managed Service von OVHcloud die richtige Wahl für SaaS-, FinTech-, AdTech- und E-Commerce-Teams ist, die auf Milliarden von Zeilen skalieren.
Warum Ihre Produktionsdatenbank der falsche Ort für Analysen ist
Eine Produktions-Public Cloud-Datenbankinstanz ist für Transaktionen gebaut, nicht für Analysen. Wenn Geschäftsteams anfangen, nach Echtzeit-Dashboards, Betrugserkennung oder Kundensegmentierungsabfragen für Terabytes an historischen Daten zu fragen... nun, dann bricht die Leistung zusammen.
Das passiert nicht so sehr, weil die Infrastruktur schwach ist, sondern weil die Anwendung das falsche Werkzeug für die Aufgabe verwendet.
OLTP vs. OLAP
OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing) befinden sich an entgegengesetzten Enden des Datenarchitekturspektrums.
OLTP -Systeme priorisieren Korrektheit und Präzision auf Transaktionsebene und verarbeiten Tausende von kleinen, schnellen Schreib- und Lesevorgängen pro Sekunde. Sie speichern Daten zeilenweise, optimiert für das Nachschlagen eines einzelnen Kundendatensatzes oder das Aktualisieren eines Bestellstatus in Millisekunden.
OLAP -Systeme hingegen sind darauf ausgelegt, Billionen von Zeilen für komplexe Aggregationen zu scannen. Sie verwenden spaltenorientierte Speicherung, bei der jede Spalte unabhängig gespeichert wird. Das bedeutet, wenn Sie SUM(revenue) WHERE date > '2025-01-01' abfragen, liest die Datenbank nur die Spalten „revenue“ und „date“ und überspringt alles andere. In ClickHouse beispielsweise werden Operationen in vektorisierter Ausführung ausgeführt. ClickHouse verarbeitet ganze Arrays von Werten auf einmal anstatt einzelner Zeilen, was den CPU-Overhead drastisch reduziert und die Cache-Auslastung maximiert.
Keine Menge an Datenindizierung, Abfrageoptimierung oder Hardware-Upgrades wird eine zeilenorientierte Datenbank effizient bei Spaltenscans machen. Die Architekturen sind grundlegend verschieden.
Warum Read-Replikate das Problem nicht lösen werden
Read-Replikate in Public Cloud Databases sind die häufigste erste Reaktion auf Analysedruck bei Produktionsdatenbanken. Sie entlasten den primären Knoten vom Lese-Traffic, beheben jedoch nicht die architektonische Diskrepanz.
Ein Read-Replikat mag zwar die Konkurrenz auf Ihrer primären Datenbank verringern, aber wenn Sie SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' über 500 Mio. Zeilen ausführen, liest und verwirft das Replikat dennoch fast jede Zeile.
Diese Analyseabfragen konkurrieren mit Produktionstransaktionen um CPU, Arbeitsspeicher und E/A. Die App-Latenz steigt, SLAs sind gefährdet und Echtzeit-Anwendungsfälle wie Betrugserkennung oder Anomalieüberwachung werden unmöglich.
Die 40-Sekunden-Abfrage, die 200 ms dauern sollte
Hier ist das typische Szenario für ein SaaS-Scale-up oder ein FinTech-Plattformunternehmen, das den Daten-Wendepunkt erreicht. Eine Abfrage wird ausgeführt, die darauf abzielt, den täglichen Umsatz nach Kundensegment über 18 Monate (500 Mio. Zeilen) zu aggregieren,
Die erwartete Ausführungszeit unter dem OLAP-Domänenmodell beträgt 200 ms, aber die tatsächliche Zeit unter der OLTP-Plattform beläuft sich am Ende auf 40 Sekunden. Warum? Nun, das passiert im Hintergrund:
Vollständiger Tabellenscan: Die PostgreSQL/MySQL-Plattform muss alle 500 Mio. Zeilen lesen, da der Index bei umfassenden Aggregationen nicht hilft.
Zeilenweise Verarbeitung: Jede Zeile wird einzeln dekomprimiert, geparst und ausgewertet.
E/A-Engpass: Festplattenlesevorgänge dominieren – der Großteil der gelesenen Daten wird verworfen.
CPU-Verschwendung: CPU-Zyklen werden für das Zeilen-Parsing anstatt für die Aggregationsqualität aufgewendet.
Speicherdruck: Große Sortierungen und Hash-Joins werden auf die Festplatte ausgelagert.
Die geschäftlichen Auswirkungen sind unmittelbar und kumulativ, da das, was ein stündliches Daten-Dashboard sein sollte, in der Praxis nur einmal täglich generiert werden kann, was Geschäftsentscheidungen verzögert.
Geschäftsentscheidungen werden verzögert, weil minutengenaue Analysen zu teuer werden und Echtzeitfunktionen bei großen Datenmengen unmöglich werden. Und das ist wichtig – Echtzeit-Reaktionsfähigkeit ist für Anwendungsfälle wie Betrugserkennung, Personalisierung und Anomalieüberwachung unerlässlich. Diese Anwendungsfälle sind mit einer Abfragelatenz von 40 Sekunden nicht praktikabel.
Das Architekturmuster: Trennung von OLTP und OLAP
Die Lösung ist eine architektonische Trennung: Führen Sie Transaktionen auf einer OLTP-Datenbankinstanz aus und streamen Sie Daten in eine separate OLAP-Instanz, die für das Scannen von Milliarden von Zeilen in Sub-Sekunden-Zeit ausgelegt ist. Jedes System tut das, wofür es entwickelt wurde, ohne das andere zu beeinträchtigen.
Spaltenspeicherung und vektorisierte Ausführung erklärt
PostgreSQL und MySQL speichern Daten zeilenweise, was für technische Transaktionen, die einzelne Datensätze abrufen, sinnvoll ist, aber für Analysen, die eine Spalte über Milliarden von Zeilen aggregieren, katastrophal ist. ClickHouse speichert Daten stattdessen spaltenweise.
Wenn Sie SUM(revenue) über 5 Milliarden Zeilen abfragen, wird nur die Umsatzspalte gelesen und alles andere übersprungen. Dies reduziert die E/A um 90 % oder mehr und ermöglicht eine aggressive Komprimierung, da die Werte in einer Spalte ähnlich sind.
Vektorisierte Ausführung ist der zweite Multiplikator. Traditionelle Datenbanken verarbeiten eine Zeile nach der anderen. ClickHouse verarbeitet ganze Arrays von Werten auf einmal, lädt einen Block der Umsatzspalte in den CPU-Cache und führt Operationen über das gesamte Vektorvolumen in einer einzigen Anweisung aus. Dies reduziert den CPU-Overhead drastisch.
Die Kombination ermöglicht Abfragen im Sub-Sekunden-Bereich bei Milliarden von Zeilen. Spaltenspeicherung minimiert Festplattenlesevorgänge; vektorisierte Ausführung minimiert die CPU-Arbeit. ClickHouse kann 10 Milliarden Zeilen in unter einer Sekunde aggregieren, während eine PostgreSQL-Instanz Minuten benötigt.
Materialisierte Sichten: Voraggregation zum Zeitpunkt der Aufnahme
Selbst bei spaltenorientierter Datenspeicherung ist das Scannen von Rohdaten jedes Mal kostspielig. Materialisierte Sichten berechnen Aggregate zum Zeitpunkt der Aufnahme vor.
In ClickHouse ist eine materialisierte Sicht eine aktive Pipeline, kein passiver Snapshot. Wenn Sie Daten einfügen, wertet ClickHouse die Abfrage der Sicht automatisch aus und schreibt die Ergebnisse in eine separate Tabelle.
Wenn Sie 100.000 Ereignisse pro Sekunde mit einer Sicht aufnehmen, die nach Minute und Segment aggregiert, berechnet ClickHouse diese Aggregate in Echtzeit.
Ihr Dashboard fragt die voraggregierte Tabelle ab, anstatt Rohereignisse zu scannen. Dies verlagert die Kosten von der Abfragezeit auf die Aufnahmezeit und nimmt einen geringen Schreibaufwand für sofortige Abfrageantworten in Kauf. Für minutengenaue Dashboards und Betrugserkennung eliminieren materialisierte Sichten die Latenz zwischen dem Eintreffen der Daten und deren Abfragbarkeit.
Sie ermöglichen auch Analysen mit mehreren Auflösungen: Bewahren Sie Rohdaten für die Forensik auf, während Sie stündliche/tägliche Aggregate für Dashboards beibehalten. Wenn Daten altern, fragen Sie gröbere Aggregate ab, um die Leistung bei der Skalierung von Terabytes auf Petabytes konsistent zu halten.
Tiered Storage, um die Kosten bei Petabyte-Skalierung linear zu halten
Das Speichern von Petabytes auf SSDs ist unerschwinglich teuer. Tiered Storage verschiebt ältere Daten auf günstigeren Objektspeicher, während aktuelle Daten auf schnellen lokalen Festplatten verbleiben.
Zum Beispiel implementiert OVHcloud Managed ClickHouse dies nativ in Tools mit OVHcloud Object Storage (S3-kompatibler)* Stream-Verarbeitung. Aktuelle Daten (30–90 Tage) verbleiben im Stream auf NVMe-SSDs.
Ältere Daten migrieren automatisch in einen OVHcloud Object Storage-Bucket zu einem Bruchteil der Kosten und ermöglichen weiterhin schnelle Abfragen, da ClickHouse nur die benötigten Spalten liest. Die Kosten für Ingenieure bleiben bei der Skalierung linear: Jedes zusätzliche Terabyte kostet bei 10 TB oder 100 TB gleich viel.
ClickHouse fragt OVHcloud Object Storage-Daten ohne Athena, Presto oder Spark ab. Heiße Daten auf SSD, kalte Daten auf S3, alles über dieselbe SQL-Schnittstelle. Dies macht die Wartung separater Systeme für heiße und kalte Daten überflüssig.
Tiered Storage vereinfacht zudem die langfristige Datenaufbewahrung: Bewahren Sie Rohdaten unbegrenzt für Compliance-Zwecke auf, ohne Ihr Budget zu sprengen. 18 Monate alte Daten für Untersuchungen abfragen? ClickHouse liest sie aus dem OVHcloud Object Storage S3*, der langsamer, aber für Ad-hoc-Analysen immer noch schnell genug ist.
Wie Sie Daten in Ihre analytische Ebene einspeisen
Sobald Sie die OLTP-Instanz von OLAP-Tools getrennt haben, müssen Sie Daten aus Ihrer Produktionsdatenbank in ClickHouse verschieben. Es gibt drei Hauptmuster, jedes mit unterschiedlichen Kompromissen bei Latenz, Komplexität und operativem Aufwand.
Batch-ETL mit Airflow, dbt oder Cron-Jobs
Batch-ETL ist der einfachste Ausgangspunkt. Extrahieren Sie Daten nach einem Zeitplan (stündlich oder täglich) aus Ihrer Produktionsdatenbank, transformieren Sie diese mit dbt und laden Sie sie in ClickHouse. Airflow orchestriert die Pipeline, oder Cron-Jobs übernehmen einfache Skripte.
Dies funktioniert, wenn Sie keine minutengenaue Aktualität benötigen. Stündliche Dashboards sind für viele Geschäftsanwendungsfälle ausreichend, und die Stapelverarbeitung ist einfacher zu debuggen und zu überwachen. Fehlgeschlagene Jobs werden zum nächsten geplanten Zeitpunkt erneut ausgeführt, und das Nachfüllen historischer Daten ist unkompliziert.
Der Kompromiss ist die Latenz, die Sie erzeugen. Daten sind zwischen den Batches veraltet, daher sind Echtzeit-Betrugserkennung oder Live-Personalisierung nicht möglich. Sie führen während des Batch-Fensters auch rechenintensive Extraktionsabfragen auf der Produktion aus, was zu Konflikten führen kann, wenn diese nicht in Zeiten mit geringem Datenverkehr geplant werden. Batch-ETL ist richtig, wenn Sie mit ClickHouse beginnen, keine Streaming-Expertise haben oder stündlich alte Daten tolerieren können.
Echtzeit-CDC mit Apache Kafka und Debezium
Change Data Capture (CDC) streamt jedes Insert, Update und Delete von der Produktion in nahezu Echtzeit zu ClickHouse. Debezium liest das Transaktionsprotokoll Ihrer Datenbank (WAL für PostgreSQL, Binlog für MySQL) und veröffentlicht Änderungen in Apache Kafka. ClickHouse konsumiert aus Kafka und fügt sofort ein.
CDC-Tools erreichen eine Latenz von unter einer Sekunde bis zu wenigen Sekunden und ermöglichen echte Echtzeit-Datenanalysen: Betrugserkennung, die Transaktionen erkennt und blockiert, während sie stattfinden, Anomalieüberwachung, die innerhalb von Sekunden alarmiert, Personalisierung, die sofort reagiert, um das Nutzerverhalten zu unterstützen.
Während die Komplexität der Einrichtung höher ist, ist CDC der Standard für Echtzeitanalysen in großem Maßstab. Der Overhead ist gerechtfertigt, wenn Geschäftsentscheidungen von der Datenaktualität abhängen. Viele Teams nutzen verwaltetes Kafka, um die Belastung zu reduzieren, oder beginnen mit Batch und migrieren zu CDC, sobald der Echtzeitwert validiert ist.
Direkte Anwendungsschreibvorgänge effizient für rein ereignisgesteuerte Workloads
Ihre Anwendung schreibt direkt in ClickHouse-Tools neben Ihrer kritischen OLTP-Datenbank. Dies funktioniert am besten für ereignisgesteuerte Workloads, bei denen jede Benutzeraktion ein Ereignis ist, das es wert ist, analysiert zu werden: Seitenaufrufe, Klicks, API-Aufrufe, Sensordaten. Die Anwendung sendet das Ereignis parallel an beide Systeme oder verwendet ClickHouse als primäres System und synchronisiert für Transaktionen mit PostgreSQL.
Dies eliminiert die ETL-Schicht vollständig. Kein Kafka, kein Debezium, keine Batch-Jobs. Die Anwendung schreibt einmal, die Daten sind sofort abfragbar und die Latenz ist minimal.
Warum ClickHouse die richtige OLAP-Engine für Echtzeitanalysen ist
ClickHouse wurde von Grund auf für Echtzeitanalysen auf riesigen Datensätzen entwickelt. Im Gegensatz zu Allzweck-Data-Warehouses, die für Batch-Workloads optimiert sind, oder wenn Sie oder diejenigen, die für interaktive BI optimieren, priorisiert ClickHouse eine Abfragelatenz im Sub-Sekundenbereich, selbst beim Scannen von Milliarden von Zeilen.
Dies macht es zur richtigen Wahl für SaaS-, FinTech-, AdTech- und E-Commerce-Unternehmen, die Analysen benötigen, die mit ihren Produktionssystemen Schritt halten.
Abfrageleistung im Sub-Sekundenbereich :
ClickHouse erreicht eine Latenz im Sub-Sekundenbereich bei Abfragen, die Milliarden von Zeilen scannen, dank spaltenorientierter Speicherung, vektorisierter Ausführung und aggressiver Komprimierung. Es kann 10 Milliarden Zeilen in unter einer Sekunde aggregieren, während PostgreSQL Minuten benötigt und andere Warehouses Sekunden bis zu mehreren zehn Sekunden brauchen.
ClickHouse vs Redshift vs BigQuery :
ClickHouse bietet eine stabile, ressourcenbasierte Preisgestaltung mit hoher Nebenläufigkeit und effizienter Skalierung, ideal für interaktive Echtzeit-Analysen. Redshift eignet sich am besten für stapelorientiertes Data Warehousing mit vorhersehbaren Workloads und bestehender AWS-Infrastruktur. BigQuery zeichnet sich durch serverlose Analysen bei sporadischen Abfragen aus und ist ideal für Teams, die keinen operativen Aufwand wünschen.
ClickHouse SQL :
ClickHouse verwendet einen SQL-Dialekt, der zu 90 % mit der Standard-SQL-Entwicklungserfahrung kompatibel ist, es gibt jedoch wesentliche Unterschiede. Aggregatfunktionen verwenden MergeTree-Tabellen mit spezifischer Engine-Syntax. Die meisten SELECT-Abfragen lassen sich direkt übersetzen, komplexe JOINs und Unterabfragen erfordern jedoch möglicherweise eine Optimierung.
Zu den Migrationstipps gehören das Testen von Abfragen auf einem repräsentativen Host-Datensatz, die Verwendung von ClickHouse EXPLAIN zur Optimierung von Session-Ausführungsplänen und die Nutzung von materialisierten Views zur Vorberechnung komplexer Tool-Stack-Aggregationen.
Warum OVHcloud Managed ClickHouse?
OVHcloud Managed ClickHouse ist das einzige native Managed ClickHouse, das von einem europäischen Cloud-Anbieter angeboten wird, ergänzend zu unseren etablierten Managed Databases for PostgreSQL . Das bedeutet kein Daten-Routing über Drittanbieter, keine Abhängigkeit von ClickHouse Cloud und keine Datenflüsse zwischen verschiedenen Anbietern.
Managed ClickHouse von einem EU-Anbieter: OVHcloud ist der einzige Cloud-Anbieter in der europäischen Region, der eine native Managed ClickHouse-Engine anbietet. Im Gegensatz zu Wettbewerbern, bei denen Sie über Dienste von Drittanbietern routen müssten, betreibt OVHcloud ClickHouse direkt auf seiner eigenen Infrastruktur.
Automatisch zu OVHcloud Object Storage: Kalte Daten werden automatisch in den S3-kompatiblen* OVHcloud Object Storage migriert, wodurch die Kosten bei Petabyte-Skalierung linear bleiben. Aktuelle Daten (30–90 Tage) verbleiben für maximale Geschwindigkeit auf NVMe-SSDs, während ältere Daten zu einem Bruchteil der Kosten in den OVHcloud Object Storage verschoben werden. Entscheidend ist, dass keine Egress-Gebühren anfallen.
3-AZ-Bereitstellungen in Paris und Mailand : Produktionscluster laufen über drei Verfügbarkeitszonen in Paris oder Mailand mit 99,99 % SLA in 3 A-Z, inklusive technischem Support rund um die Uhr und Multi-Node-Replikation für hohe Verfügbarkeit. Der Gen3-Service (seit August 2025) bietet 5-fachen Speicher, 4-fache Bandbreite, 2-fache TPS und einen 1,5-mal schnelleren Start im Vergleich zur vorherigen Generation; all dies ist besser für die Skalierung.
DSGVO by design, kein Cloud Act-Risiko: OVHcloud ist ein französisches Unternehmen, das ausschließlich dem französischen bzw. EU-Recht unterliegt. Alle Analysedaten verbleiben in europäischen Rechenzentren, ohne Cloud Act-Risiko, das US-Anbieter betrifft. Dies ist besonders relevant für Verhaltensdaten, Finanztransaktionen und Daten im Geltungsbereich der DSGVO.
Darüber hinaus sind die Dienste von OVHcloud nach ISO/IEC 27001/27017/27018/27701 zertifiziert und HDS-konform, die SecNumCloud-Zertifizierung ist in Arbeit. Dazu gehören unser Managed Apache Kafka für CDC-Pipelines und unser OVHcloud Object Storage (S3-kompatibel)*.
Für europäische SaaS-, FinTech-, AdTech- und E-Commerce-Unternehmen, die EU-Kundendaten verarbeiten, eliminiert diese Souveränitätsgarantie das rechtliche Risiko, dass US-Behörden auf Daten zugreifen, die bei amerikanischen Cloud-Anbietern gespeichert sind.
Erste Schritte: Implementieren Sie ClickHouse und verbinden Sie es mit Ihrer Produktionsdatenbank.
Sind Sie bereit, Ihre Produktionsdatenbank von rechenintensiven Analyseabfragen zu entlasten? Die Bereitstellung von OVHcloud Managed ClickHouse dauert nur wenige Minuten über das Control Panel oder die API.
Wir stellen sicher, dass Ihre Daten in europäischen Rechenzentren verbleiben, um Datenschutz und vollständige Observability zu gewährleisten. Es fallen keine Egress-Gebühren an, und das Tiered Storage zu OVHcloud Object Storage S3-kompatibel* sorgt für vorhersehbare Kosten, während Sie von Terabytes auf Petabytes skalieren.
Starten Sie noch heute Ihren ClickHouse-Softwarecluster und erfahren Sie, warum über 2.000 Unternehmen, darunter Tesla, Bloomberg und Anthropic, bei Echtzeitanalysen auf ClickHouse vertrauen.
* S3 ist eine eingetragene Marke von Amazon Technologies, Inc. OVHcloud Dienste werden in keinster Weise von Amazon Technologies, Inc. gesponsert oder befürwortet und stehen auch nicht mit dem Unternehmen in Verbindung.