CloudQuery, eine Entwickler-fokussierte Cloud-Governance-Plattform, stellte sich vor einiger Zeit einer bedeutenden technischen Herausforderung: die Auswahl einer Datenbank, die den Anforderungen eines skalierbaren, effizienten und nutzerfreundlichen Backend-Systems gerecht wird. Ziel war es, cloudübergreifende Konfigurationsdaten in riesigen Mengen schnell zu verarbeiten und gleichzeitig flexible, ad-hoc SQL-Abfragen zu ermöglichen. Nach eingehenden Tests unterschiedlichster Systeme fiel die Wahl auf ClickHouse - eine Spaltenorientierte, analytische Datenbank, die für ihre hohe Performance und Skalierbarkeit bekannt ist. Doch wie verlief die Implementierung wirklich? Welche Lehren konnte das CloudQuery-Team aus sechs Monaten mit ClickHouse ziehen? Welche Stolpersteine gab es und wie wurden diese gemeistert? Die Ausgangssituation stellte hohe Anforderungen an das Datenbanksystem. Es galt, riesige Mengen von Cloud-Asset-Daten aus verschiedenen Quellen wie AWS und Azure in Echtzeit und in großen Chargen zu verarbeiten.
Dabei wurden monatlich Milliarden von Datensätzen und mehrere Terabyte an neuen Daten erwartet. Eine hohe Durchsatzrate beim Einfügen sowie schnelle Abfragegeschwindigkeiten waren unabdingbar. Ein weiterer entscheidender Faktor war die Konsistenz der Daten im Betrieb: Nutzer sollten niemals veraltete oder uneinheitliche Daten sehen, denn CloudQuery dient als Grundlage für Sicherheitsprüfungen, Compliance-Audits und Kostenanalysen großer Unternehmen. ClickHouse überzeugte insbesondere durch seine Fähigkeit, kontinuierlich Millionen von Zeilen pro Sekunde einzuspeisen und gleichzeitig schnelle Antworten auf komplexe, unvorhersehbare Abfragen zu liefern. Vergleichsstudien zeigten, dass ClickHouse bei ähnlichen Workloads bis zu zehnmal schnellere Antwortzeiten erreichte als etablierte Cloud-Datenbanken wie BigQuery oder Snowflake.
Dabei spielte auch die Kostenersparnis eine Rolle: Während relationale Systeme wie Postgres mit wachsender Datenmenge oft teuer und wartungsintensiv werden, konnte CloudQuery durch ClickHouse Einsparungen von über 30 Prozent verzeichnen, ohne auf Leistung zu verzichten. Trotz dieser Vorteile zeigte sich im Laufe der Monate schnell, dass ClickHouse kein Selbstläufer ist. Das Team stand vor verschiedenen Herausforderungen, die teilweise mit der spezifischen Architektur oder Funktionsweise von ClickHouse zusammenhingen. Einige dieser Herausforderungen wurden systematisch gelöst, andere erforderten Kompromisse oder kreative Umgehungslösungen. Eine der größten Hürden waren die JOIN-Operationen zwischen sehr großen Datentabellen.
Während relationale Datenbanken JOINs recht flexibel und performant handhaben, führte ClickHouse bei großen Joins häufig zu massiven Verlangsamungen oder auch zum Abbruch von Abfragen wegen überschrittener Speichergrenzen. Hier zeigte sich, wie wichtig es ist, JOINs in ClickHouse mit höchster Sorgfalt zu planen. Das Team lernte, dass die Reihenfolge der Tabellen beim JOIN eine enorme Auswirkung auf die Performance hat. Die kleinere Tabelle sollte immer rechts im JOIN stehen. Außerdem wurde empfohlen, komplexe JOIN-Ketten zu vermeiden und die Zahl der JOINs auf drei bis vier pro Abfrage zu begrenzen.
Darüber hinaus bot die Nutzung von ClickHouse-Dictionaries einen großen Vorteil für häufige Lookup-JOINs. Diese Dictionaries fungieren als In-Memory Key-Value Stores und ermöglichen extrem schnelle Zuordnungen von statischen oder langsam wechselnden Dimensionstabellen. Anstatt komplexe JOINs zu verwenden, konnte CloudQuery viele Referenzdaten über Dictionaries abfragen, was Speicherbedarf und Abfragezeiten drastisch reduzierte. Allerdings bedeutete der Einsatz von Dictionaries zusätzlichen Konfigurationsaufwand, insbesondere im Bereich der Authentifizierung und Aktualisierung der Dictionary-Inhalte, was in der Praxis zu einer nicht unerheblichen Betriebskomplexität führte. Neben den JOIN-Herausforderungen spielte die Wahl und Optimierung des Sortier- bzw.
Schlüsselattributs (Sort Key) im ClickHouse-Datenmodell eine zentrale Rolle. Dieses Key-Arrangement bestimmt die physische Anordnung der Daten auf der Festplatte und damit, wie effektiv Abfragen Daten filtern und scannen können. Ursprünglich wurde häufig nach Zeitstempeln sortiert, was zwar intuitiv bei zeitbasierten Daten erschien, allerdings nicht den typischen Abfragemustern von CloudQuery entsprach. Eine Neuausrichtung der Sortierreihenfolge auf Felder wie Sync-Gruppen-ID, Cloud-Typ und Ressourcentyp führte zu dramatischen Performanceverbesserungen mit einem vielfach reduzierten Datenvolumen, das bei Abfragen durchsucht werden musste. Ein weiterer wichtiger Aspekt war der Umgang mit Materialized Views (Materialisierte Sichten).
Obwohl diese in ClickHouse theoretisch automatische Echtzeit-Aggregationen erlauben, zeigten sich praktische Schwächen. Materialized Views laufen asynchron zu den zugrundeliegenden Einfügevorgängen, was zu einem Mangel an Transparenz bei Fehlern und Unsicherheit bei der Aktualität der Daten führte. Zudem besitzen sie keine integrierte Möglichkeit zur Aktualisierung historischer Daten. Für CloudQuery, das gewissenhafte Konsistenz- und Migrationsanforderungen hat, war dies ein großes Problem. Stattdessen entschied sich das Team für den Einsatz sogenannter Snapshot-Tabellen, die explizit zu festgelegten Zeitpunkten geklont und aktualisiert werden.
Diese Vorgehensweise ermöglichte volle Kontrolle und Vorhersehbarkeit über Datenkonsistenz und Schemaänderungen. Eine unerwartete positive Erfahrung ergab sich aus dem erweiterten Einsatz von ClickHouse jenseits reiner OLAP-Analysen. CloudQuery nutzte das System erfolgreich auch für die Speicherung und Analyse von Logs und Telemetriedaten. Die Effizienz von ClickHouse bei der Kompression und Abfrage von semi-strukturierten Daten erwies sich als hervorragend, wodurch es möglich wurde, Log- und Observability-Daten unmittelbar im bestehenden Datencluster abzufragen. Das rationalisierte die Systemarchitektur und schaffte Kostenvorteile, da durch die Zusammenführung verschiedener Analyse- und Beobachtungsdaten eine Fragmentierung der Datenplattform vermieden wurde.
Zudem sorgte ClickHouse für schnelle Antwortzeiten selbst bei komplexen Tracing-Daten, was den Nutzen für Debugging und Performance-Monitoring steigerte. Erfahrungen aus dem Betrieb zeigten auch, wie wichtig eine durchdachte Architektur der Datenpipeline ist. Anfangs fehlte ein Buffer oder eine Queue vor den Inserts, was dazu führte, dass Nutzer für kurze Zeit inkonsistente Daten wahrnahmen, da synchronisierte Daten teilweise parallel geschrieben wurden. ClickHouse unterstützt keine Multi-Statement-Transaktionen, weshalb CloudQuery eine eigene Konsistenz-Schicht implementierte, die Sync-Vorgänge atomar erscheinen lässt. Ein früherer Einsatz von Pufferschichten hätte viele Probleme vermeiden können.
Auch die Erkenntnis, dass der Sort Key frühzeitig und mit Bedacht gewählt werden muss, stellte sich als zentral heraus. Da sich der Sortiermechanismus in ClickHouse nicht einfach ändern lässt, ist die Vorplanung entscheidend, um spätere Ausfallzeiten und aufwendige Neuaufbauten zu vermeiden. Der Vergleich zwischen Managed ClickHouse Cloud und einer Selbsthosted-Installation offenbarte weitere wichtige Lektionen. Während Managed-Services die schnelle Bereitstellung und einfache Verwaltung ermöglichen, verursachte der Wechsel zu einer selbst gehosteten Installation unerwartete Kompatibilitätsprobleme bei der Migration von Daten und Konfigurationen. Unterschiede in SQL-Verhalten und Konfigurationsparametern verlangten sorgfältige Anpassungen.
CloudQuery verfolgt seither einen Doppelstrategie-Ansatz, um je nach Anforderung die jeweils beste Wahl zu treffen. Zukunftsausblick und Wünsche des CloudQuery-Teams fokussieren sich auf verbesserte JSON-Unterstützung und vollumfängliche Full-Text-Suche. Trotz guter Basis ist die native Handhabung von JSON sowie die effiziente, benutzerfreundliche Volltextsuche noch nicht ideal integriert. Verbesserungen in diesen Bereichen würden ein wichtiger Schritt sein, um ClickHouse als universelle Datenplattform noch attraktiver zu machen. Fazit: Sechs Monate mit ClickHouse haben CloudQuery viel Geschwindigkeit, Skalierbarkeit und Kostenersparnis gebracht, sie waren aber auch von den typischen Fallstricken großer datenintensiver Systeme geprägt.
