Echtzeit-Petabyte-Analysen ohne Auswirkungen auf die Datenbank
Transaktionen und Analysen voneinander trennen
Das Ergebnis: Eine Dashboard-Abfrage, die eigentlich 200 Millisekunden dauern sollte, benötigt plötzlich 40 Sekunden, weil die Analyse 500 Mio. Zeilen durchsucht und dabei CPU und I/O stark beansprucht. Nutzer müssen zu lange auf Ergebnisse warten, und die Einhaltung der vereinbarten Service Level Agreements (SLAs) ist gefährdet. Dieses Problem lässt sich nicht allein durch Datenbank-Tuning beheben. Es erfordert eine Änderung der Architektur: Umfangreiche Abfragen dürfen nicht mehr auf der Produktionsdatenbank ausgeführt werden.
Konzentrieren Sie PostgreSQL auf transaktionale Lese- und Schreibvorgänge, während OVHcloud Managed ClickHouse die analytischen Abfragen übernimmt. Für die Echtzeitanalyse von Petabytes an Daten bietet Object Storage mit S3-kompatibler Schnittstelle eine skalierbare Speicherebene, die den schnellen Primärspeicher ergänzt. So skalieren Sie Ihre Analyseumgebung unabhängig von Ihrer Produktionsdatenbank.
Performance und Kontrolle bei großen Datenmengen
![[object Object]](https://assets.ovhcloud.com/1fipjkCd6Fynpkj2pu4pL37bz_sYmY1YjFkODJlY2IyOGI5/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_79aa0c4f.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiX5E4qzpXh67Ljo5AmdpyC4_sOTg4ZGYwMzQ5ZmJhOTY0/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_2d4e9ac8.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fipChngFS3mvuo2AkLC4LAjh_sZGYyMTFhOGIzZGFjOWVm/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_1f60228d.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fid6rzboLjodqmFX8pbmmpr8_sZDc4MTgzZjQ2OTg2NTIw/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_0703c5fb.svg){kind=small}
Warum die Skalierung der Produktionsdatenbank für analytische Workloads nicht ausreicht
Belastung transaktionaler Datenbanken
Transaktionsdatenbanken eignen sich hervorragend für kurze Suchabfragen, Einfügungen und Aktualisierungen. Die Echtzeit-Petabyte-Analyse an Daten stellt jedoch ganz andere Anforderungen: umfangreiche Scans, komplexe Joins und wiederholte Aggregationen konkurrieren mit dem produktiven Datenverkehr um CPU, Arbeitsspeicher und Speicherbandbreite. Eine Datenbankinstanz in der Public Cloud ist für Transaktionen ausgelegt, nicht für analytische Workloads. Sobald Fachbereiche Echtzeit-Dashboards, Betrugserkennung oder Abfragen zur Kundensegmentierung auf Basis von Terabytes historischer Daten benötigen, kann die Performance drastisch einbrechen.
Grenzen von Read Replicas
Read Replicas in Public Cloud Databases sind eine häufige erste Maßnahme, um analytische Abfragen von Produktionsdatenbanken zu verlangen. Sie entlasten den primären Datenbankknoten von Lesezugriffen, lösen jedoch nicht das grundlegende Architekturproblem. Ein Read Replica kann die Ressourcenkonkurrenz auf der primären Datenbank reduzieren. Bei einer Abfrage wie SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' über 500 Millionen Zeilen muss jedoch auch das Replikat nahezu alle Datensätze lesen und anschließend einen Großteil davon verwerfen. Diese Analyseabfragen konkurrieren weiterhin mit produktiven Transaktionen um CPU, Arbeitsspeicher und I/O. Die Antwortzeiten der Anwendung steigen, SLAs sind gefährdet und Echtzeitanwendungsfälle wie Betrugserkennung oder Anomalieüberwachung werden erschwert.
Nachhaltige Trennung von Workloads
Ein robuster Architekturansatz trennt transaktionale und analytische Workloads. Apache Kafka überträgt bestätigte Ereignisse an eine dedizierte Plattform, die für Analysen im Petabyte-Maßstab ausgelegt ist. Die Produktionsdatenbanken verarbeiten weiterhin Transaktionen, während die Analyseumgebung unabhängig für große Datenmengen, Streaming-Analysen, künstliche Intelligenz und Business Intelligence skaliert werden kann.
Jedem Workload die passende Engine zuweisen
Die Daten werden zeilenorientiert gespeichert. Das ist ideal, um beispielsweise einen einzelnen Kundendatensatz abzurufen oder den Status einer Bestellung innerhalb von Millisekunden zu aktualisieren.
OLAP-Systeme sind dagegen auf die Analyse großer Datenmengen und komplexe Aggregationen über Milliarden oder Billionen on Zeilen ausgelegt. Sie verwenden eine spaltenorientierte Speicherung, bei der jede Spalte unabhängig gespeichert wird. Bei einer Abfrage wie SUM(revenue) WHERE date > '2025-01-01' liest die Datenbank deshalb nur die Spalten revenue und date und überspringt alle übrigen Spalten. ClickHouse ergänzt dieses Prinzip durch vektorisierte Ausführung. ClickHouse verarbeitet ganze Wertearrays auf einmal statt einzelne Zeilen nacheinander. Dadurch wird der CPU-Overhead deutlich reduziert und der Cache effizienter genutzt.
Keine noch so umfangreiche Indexierung, Abfrageoptimierung oder Hardwareaufrüstung macht eine zeilenorientierte Datenbank für spaltenorientierte Scans wirklich effizient. Die zugrunde liegenden Architekturen unterscheiden sich grundlegend.
Auswahl eines Lademuster für jede Datenquelle
Streaming
Übertragen Sie Ereignisse kontinuierlich, wenn operative Dashboards und Warnmeldungen auf Erkenntnisse mit geringer Latenz angewiesen sind.
Batch-Verarbeitung
Verwenden Sie Batch-ETL mit Airflow, um historische Datenimporte, regelmäßige Exporte und umfangreiche Datenübertragungen aus Quellsystemen zu planen.
Change Data Capture (CDC)
Übertragen Sie bestätigte Datenbankänderungen, während der zusätzliche Aufwand für das transaktionale Quellsystem begrenzt bleibt.
Direkte Datenaufnahme
Lassen Sie Anwendungen analytische Ereignisse direkt schreiben, wenn Ihre Teams das Ereignisschema selbst verantworten und verwalten.
OLTP und OLAP voneinander trennen
Bei einer Abfrage wie SUM(revenue) über fünf Milliarden Zeilen liest ClickHouse nur die Spalte revenue und überspringt alle übrigen Spalten. Dadurch lässt sich der I/O-Aufwand um 90 % oder mehr reduzieren. Zudem ermöglicht die Ähnlichkeit der Werte innerhalb einer Spalte eine besonders effiziente Komprimierung.
Die vektorisierte Ausführung sorgt für einen zusätzlichen Leistungsschub. Herkömmliche Datenbanken verarbeiten Daten Zeile für Zeile. ClickHouse verarbeitet ganze Wertearrays auf einmal: Ein Datenblock aus der Spalte revenue wird in den CPU-Cache geladen, und die Operationen werden in einer einzigen Anweisung auf den gesamten Vektor angewendet. Dies reduziert den CPU-Overhead erheblich.
Die Kombination aus spaltenorientierter Speicherung und vektorisierter Ausführung kann sehr schnelle Abfragen über Milliarden von Zeilen ermöglichen – abhängig von Datenmodell, Abfrage, Datenvolumen und verfügbarer Rechenleistung. Die spaltenorientierte Speicherung minimiert die Festplattenzugriffe, während die vektorisierte Ausführung den CPU-Aufwand reduziert. ClickHouse kann zehn Milliarden Zeilen in weniger als einer Sekunde aggregieren, während eine PostgreSQL-Instanz dafür mehrere Minuten benötigt.
![[object Object]](https://assets.ovhcloud.com/1fiz3Ewd3ACopFnjLbkLvoSdp_sYjBlNTU5YjQyYWVjNjdl/76542f62-8c49-48e5-92ec-910825c8d69c_ima_e302634e.png)
Auf Aktualität, Geschwindigkeit, Ausfallsicherheit und Governance auslegen
Batch-ETL
Batch-ETL ist der einfachste Ausgangspunkt.
Extrahieren Sie Daten nach einem festen Zeitplan – beispielsweise stündlich oder täglich – aus Ihrer Produktionsdatenbank, transformieren Sie sie mit dbt und laden Sie sie in ClickHouse. Airflow orchestriert die Datenpipeline; für einfache Skripte können auch Cron-Jobs verwendet werden.
Dieser Ansatz eignet sich, wenn keine minutengenaue Aktualität erforderlich ist. Stündlich aktualisierte Dashboards reichen für viele Geschäftsszenarien aus. Außerdem lassen sich Batch-Prozesse einfacher debuggen und überwachen.
Der Nachteil ist die zusätzliche Latenz:. Zwischen zwei Verarbeitungsläufen sind die Daten nicht auf dem neuesten Stand. Eine Echtzeit-Betrugserkennung oder eine unmittelbar reagierende Personalisierung ist damit nicht möglich. Batch-ETL ist sinnvoll, wenn Sie gerade mit ClickHouse beginnen, noch keine Erfahrung mit Streaming haben oder Datenverzögerungen von etwa einer Stunde akzeptieren können.
CDC in Echtzeit
Change Data Capture (CDC) überträgt Einfügungen, Aktualisierungen und Löschungen aus der Produktionsdatenbank nahezu in Echtzeit nach ClickHouse. Debezium liest das Transaktionsprotokoll der Datenbank – bei PostgreSQL das WAL und bei MySQL das Binlog – und veröffentlicht die Änderungen in Apache Kafka. ClickHouse liest die Ereignisse aus Kafka und fügt sie unmittelbar ein.
CDC-Tools erreichen Latenzen von weniger als einer Sekunde bis zu wenigen Sekunden. Damit werden echte Echtzeitanalysen möglich: Betrugserkennung, die Transaktionen während ihrer Ausführung erkennt und blockiert; Anomalieüberwachung, die innerhalb von Sekunden Alarm schlägt; sowie Personalisierung, die unmittelbar auf das Nutzerverhalten reagiert.
Gestaffelte Speicherung für lineare Kosten im Petabyte-Maßstab
Petabytes an Daten ausschließlich auf SSDs zu speichern, ist äußerst kostspielig. Eine gestaffelte Speicherarchitektur verschiebt ältere Daten in günstigeren Object Storage, während aktuelle Daten auf schnellen lokalen Laufwerken verbleiben.
OVHcloud Managed ClickHouse unterstützt eine solche Architektur in Verbindung mit OVHcloud Object Storage mit S3-kompatibler Schnittstelle. Aktuelle Daten aus den letzten 30 bis 90 Tagen verbleiben auf NVMe-SSDs.
Ältere Daten werden automatisch in einen OVHcloud-Object-Storage-Bucket verschoben. Das reduziert die Speicherkosten erheblich. Schnelle Abfragen bleiben möglich, weil ClickHouse nur die tatsächlich benötigten Spalten liest. Die Kosten lassen sich so beim Wachstum besser kalkulieren: Ein zusätzliches Terabyte verursacht bei 100 TB dasselbe zusätzliche Speichervolumen wie bei 10 TB, sofern die gleichen Speicherklassen und Konditionen gelten.
Voraggregation bei der Datenaufnahme
Auch bei spaltenorientierter Speicherung ist es aufwendig, Rohdaten bei jeder Abfrage erneut vollständig zu durchsuchen.
Materialisierte Views berechnen Aggregationen deshalb bereits bei der Datenaufnahme vor.
In ClickHouse ist eine materialisierte View keine passive Momentaufnahme, sondern eine aktive Datenpipeline (snapshot). Beim Einfügen von Daten führt ClickHouse die Abfrage der View automatisch aus und schreibt die Ergebnisse in eine separate Tabelle.
Werden beispielsweise 100.000 Ereignisse pro Sekunde aufgenommen und in einer View nach Minute und Segment aggregiert, berechnet ClickHouse diese Aggregationen in Echtzeit.
Warum ClickHouse die richtige Engine für Echtzeitanalysen ist
Dank spaltenorientierter Speicherung, vektorisierter Ausführung und effizienter Komprimierung erreicht ClickHouse bei Abfragen über Milliarden von Zeilen Antwortzeiten von weniger als einer Sekunde. Es kann zehn Milliarden Zeilen in weniger als einer Sekunde aggregieren, während PostgreSQL dafür mehrere Minuten und andere Data-Warehouse-Lösungen mehrere Sekunden bis einige zehn Sekunden benötigen.
ClickHouse bietet eine planbare, ressourcenbasierte Preisgestaltung, hohe Parallelität und eine effiziente Skalierung. Damit eignet es sich besonders für interaktive Echtzeitanalysen. Amazon Redshift ist vor allem für Batch-orientierte Data-Warehouse-Workloads mit vorhersehbaren Anforderungen und bestehender AWS-Infrastruktur geeignet. BigQuery spielt seine Stärken bei serverlosen Analysen mit unregelmäßigen Abfragen aus, insbesondere wenn Teams möglichst wenig operativen Verwaltungsaufwand wünschen.
ClickHouse verwendet einen SQL-Dialekt, der zu etwa 90 % mit dem üblichen SQL-Entwicklungsmodell kompatibel ist. Dennoch gibt es wichtige Unterschiede. Aggregationsfunktionen verwenden MergeTree-Tabellen mit einer spezifischen Engine-Syntax. Die meisten SELECT-Abfragen lassen sich direkt übertragen, während komplexe JOINs und Unterabfragen möglicherweise optimiert werden müssen.
Entdecken Sie OVHcloud Managed ClickHouse oder lassen Sie sich von unseren Spezialisten bei der Dimensionierung einer Architektur unterstützen, die zu Ihrem Datenvolumen, Ihren Aktualitätsanforderungen, Ihrer Aufbewahrungsdauer und der erwarteten Anzahl paralleler Abfragen passt.