ClickHouse
Spaltenorientierte Datenbank, die Analysen über Milliarden Zeilen in Sekunden beantwortet
Absurd schnell für die eine Aufgabe, die es macht, und schlecht für alles andere, und so sollte ein gutes Werkzeug sein.
Stärken
- Funnel- und Session-Abfragen über Roh-Events kommen in Sekunden zurück
- Spricht SQL, die Lernkurve ist der Dialekt, nicht die Sprache
- Selbst hosten im Container dauert zehn Minuten
- Die Kompression bringt ein Jahr Events auf eine kleine Platte
Schwächen
- Updates und Deletes sind ein Nachgedanke; es will Daten, die nur angehängt werden
- Joins sind langsamer und seltsamer als in einer Zeilendatenbank
- Der SQL-Dialekt hat genug Überraschungen, dass kopierte Postgres-Abfragen scheitern
Am besten fürEntwickler mit einer Event-Tabelle, die Postgres entwachsen ist, und die schnelle Aggregate ohne Datenteam wollen.
ClickHouse ist eine spaltenorientierte Datenbank für Analysen. Du schüttest Events hinein, gern Millionen am Tag, stellst Fragen, die alle davon berühren, und es antwortet, während eine Zeilendatenbank noch die Platte liest. Es ist Open Source, und es gibt eine gehostete Cloud-Version.
So nutze ich es
Ich halte es für ein Tracking-Experiment. Rohe Seitenaufrufe, Klicks und Formular-Events von ein paar Seiten landen in einer breiten Tabelle, und die Fragen sind die klassischen: Wie viele Sessions haben den Checkout erreicht, wo sind sie abgesprungen, was hat eine Kohorte in den ersten zehn Minuten getan. In Postgres waren diese Abfragen eine Kaffeepause. Hier sind sie ein Wimpernschlag, auf einer einzelnen kleinen Instanz im Container, mit Daten, die so gut komprimiert sind, dass ein Jahr dort hineinpasst, wo vorher ein Monat war.
Überrascht hat mich, wie wenig Tuning es brauchte. Ein vernünftiger Sortierschlüssel auf der Tabelle, der Rest hat sich selbst erledigt. Was mich nervt, ist alles außerhalb des Sweet Spots. Es will nicht, dass du Zeilen änderst oder löschst; du kannst, aber es ist langsam und sperrig, also müssen die Daten von Anfang an als reines Anhängen gedacht sein. Joins zwischen großen Tabellen sind langsamer als erwartet und müssen auf die ClickHouse-Art geschrieben werden. Und der SQL-Dialekt hat genug kleine Unterschiede, dass eine aus einem Postgres-Projekt kopierte Abfrage jedes Mal an einem Funktionsnamen oder einem Datums-Cast scheitert.
Ich betreibe es selbst gehostet, weil das Experiment klein ist. Die Cloud-Version rechnet nach Rechenleistung und Speicher ab, mit einem Testguthaben, das großzügig genug ist, um herauszufinden, ob du sie brauchst.
Für wen es ist
Entwickler, deren Event-Tabelle Postgres zum Würgen bringt und die mit SQL vertraut sind. Hat deine größte Tabelle ein paar Millionen Zeilen, brauchst du das noch nicht. Lass es als primäre Anwendungsdatenbank; für Transaktionen hat es die falsche Form, und wer es versucht, betreibt am Ende sowieso zwei Datenbanken.


