10 Jahre ClickHouse Open Source
(clickhouse.com)- ClickHouse wurde am 15. Juni 2016 als Open Source veröffentlicht und ist in den 10 Jahren danach mit Beiträgen von mehr als 2.000 Personen zu einem führenden Projekt unter den Open-Source-Analyse-Datenbanken gewachsen
- Ziel ist nicht nur die Freigabe des Codes, sondern Level 3 Open Source: öffentlich sind auch Beitragsrichtlinien, Code Reviews, Roadmap, CI, Releases und Dokumentation
- Ausgangspunkt waren die Grenzen eines webbasierten Analysesystems auf MySQL-Basis; die Erfahrungen mit OLAPServer und Metrage führten zu spaltenorientierter Verarbeitung und zum Design von MergeTree
- ClickHouse ist keine Erweiterung auf einem bestehenden DBMS, sondern ein von Grund auf implementiertes DBMS, bei dem seit 2009 schrittweise Spaltendarstellung, Aggregatfunktionen, Table Engines, Kompression, SQL-Parser, Server/Client und ReplicatedMergeTree aufgebaut wurden
- Nach dem Einsatz in der internen Produktion ab 2014 zur Verarbeitung von täglich Hunderten Milliarden Datensätzen wurde ClickHouse nach einem öffentlichen Artikel 2015 und einem internen Freigabeprozess 2016 weltweit veröffentlicht
10 Jahre seit der Open-Source-Veröffentlichung
- ClickHouse wurde am 15. Juni 2016 als Open Source veröffentlicht
- Seitdem haben mehr als 2.000 Personen beigetragen, und es wurde zur „beliebtesten Open-Source-Analyse-Datenbank“
- Das Kernziel des Projekts ist es, nicht nur den Code offenzulegen, sondern auch den Entwicklungs- und Beitragsprozess so weit wie möglich öffentlich zu machen
Das von ClickHouse angestrebte Open-Source-Niveau
- Open Source gibt es auf mehreren Ebenen
- Level 0: Der Code wird zum Lesen veröffentlicht, aber darüber hinaus gibt es nichts. Beispiele sind archivartige oder museumsartige Veröffentlichungen wie Doom oder MS-DOS
- Level 1: Ein öffentliches Repository wird per Commits aktualisiert, nimmt aber nicht zwingend Beiträge an. Beispiele sind SQLite und Ladybird
- Level 2: Beiträge werden angenommen, aber der Entwicklungsprozess ist nicht transparent und öffentlich. Die meisten aktiven Open-Source-Projekte gehören hierzu
- Level 3: Verfügt über Beitragsrichtlinien, Aufgabenverfolgung, Code Reviews, eine Entwicklungs-Roadmap, Tests und CI, einen Release-Zyklus, Support für Nutzer und Dokumentation
- ClickHouse strebt Level 3 Open Source an
- Ein weiteres Ziel ist es, für Entwickler, die eine neue Datenbank bauen wollen, als Beispiel für Code und Entwicklungspraktiken zu dienen
- Der Code soll modular, orthogonal und dokumentiert sein
- Wenn komplexe Konzepte nötig sind, werden sie in Kommentaren von Grund auf erklärt, damit Leser nicht zusätzlich Lehrbücher, Wikipedia oder KI konsultieren müssen
Ein Ort für C++-Entwicklung und Performance-Experimente
- ClickHouse ist eines der populären Open-Source-Repositories in C++ und versteht sich auch als Ort, an dem man Grundlagen wie moderne Sprachfeatures wie C++23, Build-Systeme, Continuous Integration und Testing sowie Praktiken für Code Reviews lernen kann
- Auch Experimente mit Datenstrukturen und Performance-Optimierung sind ein wichtiger Anwendungsfall
- Experimentelle Pull Requests, die gar nicht auf einen Merge abzielen, werden auf demselben Niveau getestet wie Produktions-Releases
- Neue Memory Allocators, Kompressionsbibliotheken, Hash-Tabellen, Datenformate oder Sortieralgorithmen lassen sich in ClickHouse validieren
- Die Roadmap enthält auch experimentelle, ungewöhnliche und sogar alberne Punkte
- Alle Beitragenden werden im CHANGELOG und in der internen Datenbanktabelle system.contributors genannt
- Häufig werden Funktionen mit unvollständiger Erstimplementierung gemeinsam weiter fertiggestellt; selbst wenn der gesamte Code neu geschrieben werden muss, werden die Absicht und die Anwendungsfälle der ursprünglichen Autoren anerkannt
Probleme vor ClickHouse und frühe Prototypen
- Der erste Commit von ClickHouse wurde am 29. Mai 2009 erstellt und war eine Performance-Optimierung, um das Problem zu verringern, dass libc-Funktionen wie
localtime,mktimeundgmtimeso langsam waren, dass sie im Profiler auffielen - Ausgangspunkt waren Experimente zur Datenverarbeitung in einem Webanalyse-System
- Das System nahm, ähnlich wie Google Analytics, Pageview-Logs von Websites entgegen
- Verwendet wurden MySQL, Datenverarbeitung in C++ und für Bereiche, in denen MySQL nicht ausreichte, benutzerdefinierte C++-Datenstrukturen
- Die MySQL-Datenbank speicherte voraggregierte Kundenreports, während die benutzerdefinierten Datenstrukturen zur Berechnung von Nutzersitzungen und Nutzerhistorien dienten
- Die Datenmenge wuchs ständig weiter, neue Logs kamen in Echtzeit an, und wenn 5-Minuten-Logs nicht innerhalb von 5 Minuten verarbeitet wurden, summierte sich die Verzögerung immer weiter auf
- Es wurden auch verschiedene Datenbanken und Bibliotheken ausprobiert
- Untersucht wurden TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, Materialien zur Datenkompression und Dokumentation zu Event-Loop-Servern
- Die Anforderung, dass Nutzer beliebige Reports zusammenstellen können sollten, zeigte die Grenzen voraggregierter Reports und führte zur Prüfung spaltenorientierter Datenbanken
OLAPServer und Metrage
- Der spaltenorientierte Ansatz bestand darin, nicht aggregierte strukturierte Logs zu speichern und dann on the fly zu aggregieren, während der Kunde auf das Laden der Seite wartete
- Getestet wurden die MySQL-Erweiterungen Infobright und InfiniDB sowie eigenständige Analyse-Datenbanken wie Vertica, MonetDB und LucidDB, aber unter den Bedingungen von 100 Milliarden Datensätzen pro Tag und 500 geladenen Spalten funktionierten sie nicht
- Der erste eigene Prototyp war OLAPServer
- Implementiert im Dezember 2008 und ausgerollt im Januar 2009
- Speichert alle Spalten in einer einzelnen Binärdatei pro Tag und Website
- Verwendet Hashes statt Strings und unterstützt nur Integer-Typen
- Nutzt leichte Kompression und wurde einmal täglich mit mehreren Stunden Verzögerung aktualisiert
- Bot eine API, mit der sich Gruppierungsspalten, Aggregatfunktionen, Filter und Sortierung angeben ließen; Queries wurden in XML beschrieben
- Evgenii Gatov löste die Aufgabe, historische MySQL-Aggregatdaten zu „deaggregieren“ und so aufzufüllen, dass identische Ergebnisse herauskamen
- OLAPServer funktionierte auch für Endpunkte, die nicht eine einzelne Website, sondern die gesamten Internetdaten des Unternehmens analysierten, und reagierte schnell genug, dass interne Analysten ihn statt internem MapReduce nutzten
- Der zweite Prototyp war Metrage
- In MySQL hatten sich rund 50 TB Daten auf 50 Shards angesammelt, viele benutzerdefinierte Datenstrukturen waren als BLOBs gespeichert
- Für Aggregationen musste das Programm BLOBs lesen, benutzerdefinierten Code anwenden und sie dann wieder einfügen
- Die MySQL-Daten waren unkomprimiert, und weil Ankunftsreihenfolge und Reihenfolge der Query-Bereiche nicht zusammenpassten, war auch das Lesen langsam
- Metrage war eine benutzerdefinierte Datenstruktur für inkrementelle Aggregation mit Hintergrund-Merges; jeder Datensatz wurde als C++-Struct mit den Methoden
add,update,merge,serializeText/BinaryunddeserializeText/Binarydefiniert
- OLAPServer war eine nicht aggregierte spaltenorientierte Struktur, Metrage eine Echtzeit-Zeilenstruktur mit beliebigen CRDTs
- ClickHouse entstand aus der Verallgemeinerung der Kombination aus spaltenorientierter Aggregationsgeschwindigkeit und Merge-Tree-basierter Echtzeitaktualisierung sowie Datenlokalität, ergänzt um eine echte Abfragesprache und Datentypen
Ein von Grund auf gebautes DBMS
- ClickHouse ist ein seltener Fall eines von Grund auf implementierten DBMS und basiert nicht auf einer bestehenden Datenbank
- Die frühen Commits von 2009 bezogen sich auf Optimierungen anderer Datenstrukturen im selben Monorepo; sie blieben erhalten, weil beim Open-Source-Prozess die Historie bewahrt und das Repository abgetrennt wurde
- Der erste Schritt bei der Implementierung des neuen DBMS war die In-Memory-Darstellung von Spalten; dabei entstanden die bis heute vertrauten Klassen
IColumnundField- Das mag Apache Arrow ähneln, aber Apache Arrow existierte damals noch nicht
- Auch andere spaltenorientierte Formate wie RCFile, Trevni, ORC oder Parquet existierten damals noch nicht
- Danach wurden Aggregatfunktionen eingeführt, bis heute einer der wichtigsten Teile von ClickHouse
- Auch Table Engines wurden eingeführt
- Zunächst wurde dafür einige Tage lang der Name „primary key“ verwendet
- Sie ermöglichten das Lesen und Schreiben von Spalten auf Datenträgern
- Die erste Table Engine ähnelte dem bis heute existierenden TinyLog
- Für Kompression wurde zunächst QuickLZ verwendet, später nach der Lektüre von Yann Collets Blog durch LZ4 ersetzt
Query-Pipeline und SQL-Implementierung
- block streams waren Pipeline-Komponenten für die Datenverarbeitung, die Spalten-Chunks als Stream erzeugten, konsumierten und transformierten
- Heute wurden sie durch Processors ersetzt
- Sie bildeten die Grundlage für Ergebnisformatierung und die Implementierung von Tabellenabfragen
- Im selben Commit wurde
StorageSystemNumberszu Testzwecken hinzugefügt; es existiert bis heute als Tabellesystem.numbers - Die erste Query-Pipeline gab Zahlen im TSV-Format aus, und der erste relationale Operator war
LIMIT - Für den SQL-Parser wurde zunächst boost::spirit versucht, was scheiterte; danach wurde ein rekursiver Abstiegparser gebaut
- Es gab auch Ideen, die früh eingeführt, später entfernt oder erst viel später wieder aufgenommen wurden
- Zahlen-Spalten mit variabler Längencodierung wurden wegen zu geringer Geschwindigkeit entfernt; deutlich später wurden benutzerdefinierte Kompressions-Codecs eingeführt, die von Spalten unabhängig sind
- Der Spaltentyp
Variant, der beliebige Feldwerte halten sollte, wurde ebenfalls wegen schlechter Performance entfernt; ein besseres Variant wurde 2025 hinzugefügt - Ein Array-Typ fester Größe wurde mangels Bedarf entfernt; eine Wiedereinführung wird derzeit erneut geprüft
- Daran zeigt sich das Entwicklungsprinzip, dass das Entfernen unnötigen Codes wichtiger ist als das Hinzufügen neuen Codes
Produktions-Rollout und ReplicatedMergeTree
- Die erste reale Tabellenstruktur, die in ClickHouse getestet wurde, war die Tabelle
hits, die heute auch in ClickBench zu sehen ist - Beim Lesen und Schreiben dieser Tabelle zeigte sich, dass C++-iostreams langsam sind; deshalb wurden
WriteBufferundReadBuffereingeführt, die bis heute genutzt werden - Die ersten SQL-Funktionen waren arithmetische Operatoren; damit wurde der erste
SELECT-Query-Interpreter implementiert - Der ClickHouse-Server wurde am 9. März 2012,
clickhouse-clientam 25. März 2012 eingeführt - Zusammen mit den Table Engines
Log,TinyLog,Merge,DistributedundMemorywurde damit ein Produktions-Rollout möglich- Der erste Produktionseinsatz war die Speicherung von Log-Chunks für weitere Verarbeitung sowie globale Queries über Rohlogs
- Es wurde wie eine persistente Log-Queue mit SQL-Abfragen verwendet
- Danach kam MergeTree hinzu
- Es führte inkrementelles Sortieren im Hintergrund durch, auch wenn Daten zeitlich geordnet eintrafen
- Dadurch wurden schnelle Bereichsabfragen für einzelne Websites möglich
- Ein Produktions-Rollout als Ersatz für OLAPServer und Metrage wurde damit möglich
- 2012 stieß Michael Kolupaev als zweiter Mitarbeiter zum Team und arbeitete an der Implementierung von ReplicatedMergeTree mit
- Die Produktion wurde über mehrere regionale Rechenzentren hinweg bereitgestellt, und das Infrastrukturteam führte monatlich „drills“ durch, bei denen ein Rechenzentrum für eine Stunde abgeschaltet wurde
- Alle Produktionsdienste mussten über Replikation über mehrere Rechenzentren hinweg verfügen
- Anfangs wurden einfaches Double-Write und Backfill nach Ausfällen genutzt
- Für 100% Konsistenz und automatische Wiederherstellung war verteilte Konsensfindung nötig
- Dafür wurde ReplicatedMergeTree mit ZooKeeper als Metadatenebene implementiert
- ReplicatedMergeTree machte 2014 den Produktionseinsatz von ClickHouse für nutzergerichtete Queries möglich
Der Weg bis zur Open-Source-Veröffentlichung
- 2014 speicherte ClickHouse in Produktion täglich Hunderte Milliarden Datensätze und beantwortete Echtzeit-Queries von Kunden
- Interne Data Scientists des Unternehmens berechneten mit ClickHouse Internettrends, und sogar einfache Nutzungsdokumentation wurde veröffentlicht
- Auch andere Abteilungen wie Werbung, E-Commerce, Infrastruktur und Business Analytics probierten ClickHouse aus und migrierten einige Anwendungsfälle von internem MapReduce, MySQL und Postgres
- Ende 2014 war ClickHouse innerhalb eines Unternehmens breit im Einsatz; als Ausnahme setzte auch CERN es im Rahmen der Zusammenarbeit beim LHCb experiment ein
- Es bestätigte sich außerdem, dass Ingenieure in anderen Unternehmen Ähnliches wie OLAPServer oder Metrage bauten, weil bestehende Datenbanken ihre Anwendungsfälle nicht gut abdeckten
- 2015 bestätigte sich das Interesse weiter, als ein Artikel über ClickHouse und eine Übersetzung veröffentlicht wurden
- Vor der Veröffentlichung wurde zur Überzeugung des Managements eine Liste potenzieller Vorteile und Risiken vorbereitet
- Nach der Freigabe wurden Release-Plan, erstes Logo, erste Website, Blogpost und Debian-Repository vorbereitet, und am 15. Juni 2016 wurde ClickHouse weltweit veröffentlicht
- Heute ist ClickHouse eine populäre Analyse-Datenbank, die von großen Unternehmen weltweit eingesetzt wird
1 Kommentare
Hacker-News-Kommentare
Ich habe ClickHouse etwa 2017/2018 entdeckt und einen Proof of Concept gebaut, um Elasticsearch zu ersetzen. Innerhalb weniger Wochen wurden Speicherverbrauch und Abfragen pro Sekunde um das Fünffache besser.
Die Verantwortlichen lehnten es aber ab, weil es nicht bekannt genug war und wie „irgendeine von Russen gebaute Datenbank“ wirkte.
Persönlich bedaure ich es ziemlich, dass ich den Zug so früh habe kommen sehen und trotzdem nicht aufgesprungen bin.
Auch die Kompressionsrate war absurd gut, und beim Benchmark der Speicherkosten kam man auf ein Niveau in der Größenordnung von S3-Kosten.
Eine Speicher-Schicht, die mehrere Millionen Dollar pro Monat kostete, wäre auf einige Tausend Dollar pro Monat geschrumpft.
ClickHouse ist kein Allheilmittel, aber wenn man versteht, wie auf die Daten zugegriffen wird, und sie entsprechend anordnen kann, bekommt man enorme Effizienz.
Soweit ich verstehe, hilft ClickHouse eher nur bei grep-artiger Suche.
Für jemanden, der lange TimescaleDB genutzt hat, war ClickHouse wirklich erfrischend. psql ist großartig, und dass man sich auf ein einziges Datenbanksystem verlassen kann, ist auch schön, aber Wartung von Migrationen und Deployment-Phasen waren ziemlich schmerzhaft.
Bei TimescaleDB fühlt es sich zudem an, als ändere sich die Struktur mit jeder Version, und die Entwicklungsrichtung schwankt etwas, sodass es sich manchmal wie ein Produkt in Alpha-Qualität anfühlt.
Ich überlege noch, ob ich mit PeerDB einen großen ClickHouse-Mirror aufbauen oder lieber separat ohne zusätzliche verletzliche Schicht deployen soll.
Mich würde interessieren, ob du TimescaleDB grundsätzlich eher nicht empfiehlst. PostgreSQL ist aktuell der solideste Teil unseres Stacks, deshalb möchte ich mir den Schmerz von Software in Alpha-Qualität definitiv ersparen.
Auf der DuckDB-Seite gibt es auch Arbeiten an pg_duckdb, ebenso wie Dinge von Xata.
Zur Einordnung: Ich arbeite bei ParadeDB.
Die Metrik- und Autoscaling-Engine von Cloud 66 hat fünf Iterationen durchlaufen, bevor sie bei ClickHouse angekommen ist: Redis, Cassandra, Eigenbau mit Ruby+RabbitMQ, Eigenbau mit Go+RabbitMQ und dann ClickHouse.
Jedes Mal stießen wir an irgendeine Grenze oder auf einen Optimierungsaufwand, den wir nicht tragen konnten, aber ClickHouse läuft seit vier Jahren sehr stabil.
Erst nachdem wir Loki durch ClickHouse ersetzt hatten, fühlte sich unser Observability-Stack endlich „richtig“ an. Für Logs und allgemeine analytische Abfragen ist es wirklich stark.
Neben der Tatsache, dass es eine gute OLAP-Datenbank ist, waren die eingebauten Konnektoren zum Laden von Daten aus entfernten Quellen ein echter Gamechanger.
Man kann einen S3-Ordner mit Parquet-/JSON-Dateien regelmäßig automatisch importieren, und direkte Verbindungen zu Postgres sind ebenfalls möglich.
In einem Data Warehouse einer mittelgroßen Zeitung haben wir die Kombination aus Druid+Postgres+Trino durch einen einzelnen großen ClickHouse-Knoten ersetzt und nie zurückgeblickt.
Es ist viel schneller, praktischer und braucht deutlich weniger Wartung.
Ich mag ClickHouse wirklich sehr, und die Performance ist hervorragend. Ich musste hier und da ein paar Abfragen wegen der Performance anpassen, aber insgesamt war es besser als erwartet.
Anfangs habe ich eine Echtzeit-Pipeline zur Erfassung aufgebaut, um große inkrementelle Ladevorgänge zu bewältigen, weil das früher genutzte Redshift teuer und vergleichsweise langsam war.
Bisher hat ClickHouse so viele Daten und große Transformationen problemlos verarbeitet, dass wir diese Pipeline nicht brauchten.
Das einzige Problem war, dass in der Standardkonfiguration ein ziemlich schwergewichtiges Tracing aktiviert war, was auf relativ kleiner Hardware die Performance stark beeinträchtigte.
Danach haben wir skaliert, und inzwischen ist es der Kern unseres Daten-Stacks.
Für wirklich sehr große Größenordnungen würde ich vielleicht etwas anderes wählen, aber solange man bei einigen wenigen Knoten bleibt, ist die Komplexität beherrschbar und die Nutzung macht Spaß.
„Man kann experimentell Pull Requests öffnen, auch wenn sie nicht mit dem Ziel eines Merges erstellt wurden, und sie durchlaufen Prüfungen auf dem Niveau von Produktions-Releases. Neue Speicher-Allocatoren, Kompressionsbibliotheken, Hash-Tabellen, Datenformate oder Sortieralgorithmen gefunden? Bring sie zu ClickHouse, und es wird sie bis ins Innerste offenlegen.“ Das ist schon beeindruckend.
Es findet praktisch überall Bugs, auch im Linux-Kernel.
Es gibt einen sehr strengen Fuzzer, mehrere Fuzzer laufen auf verschiedenen Ebenen, und Tests werden mit absurd vielen Konfigurationskombinationen ausgeführt.
Die letzte Zahl, die ich vor etwa einem Jahr gehört habe, war, dass ein vollständiger CI-Lauf für einen einzelnen Commit ungefähr 400 Stunden braucht.
Das ist also im positiven Sinn ziemlich verrückt.
Interessant ist, dass der Blogpost SQLite und Ladybird auf das Spektrum setzt, den zentralen Open-Source-Konkurrenten DuckDB aber auslässt.
Ich stimme zu, dass Vertrauen Stufe drei ist.
Aber um im Zeitalter vibecodeter Datenbanken nachhaltig zu bleiben, muss man ein neues Geschäftsmodell erfinden.
Wenn man nicht indexierte Spalten abfragt, kann ClickHouse leicht zehnmal schneller sein als DuckDB bei Abfragen auf Parquet, und wenn der Primärschlüssel ins Spiel kommt, ist es praktisch kein Vergleich mehr.
Es gibt viele Texte, die beide vergleichen, aber realistisch gesehen befinden sich ClickHouse und DuckDB in völlig unterschiedlichen Bereichen.
DuckDB ist eine starke Analyse-Engine, während ClickHouse ein vollständiges Datenbankmanagementsystem mit Replikation, MergeTree-Engine und mehr ist.
Meistens hat man dieses Größenproblem nicht, aber wenn doch, macht es einen großen Unterschied.
Schade ist, dass die Seite ungern sagt, dass die „Datenverarbeitung für ein Webanalysesystem ähnlich wie Google Analytics“ tatsächlich bei Yandex eingesetzt wurde.
Vermutlich will man dieses Unternehmen nicht bewerben, aber warum das traurig sein soll, verstehe ich nicht ganz.
ClickHouse war in einigen Unternehmen, in denen ich früher gearbeitet habe, ein echter Gamechanger. Das erinnert mich an die Folge des Podcasts Rust in Production über die Einführung von Rust.
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1