Ein Web-Analytics-Tool sammelt mit der Zeit vor allem eines: sehr viele Events.
Pageviews, Custom Events, Referrer, Geräte und viele weitere Daten müssen gespeichert und später möglichst schnell wieder ausgewertet werden. Als ich Lienks gebaut habe, ein einfaches, datenschutzfreundliches Web-Analytics-Tool, musste ich deshalb relativ früh entscheiden, wo diese Daten eigentlich landen sollen.
Was ist ClickHouse und warum nutze ich es?
ClickHouse ist eine Datenbank, die speziell dafür entwickelt wurde, große Mengen an Daten schnell auszuwerten, und genau das macht sie für ein Analytics-Tool wie Lienks interessant.
Anders als PostgreSQL speichert ClickHouse die Daten dabei spaltenorientiert statt zeilenorientiert.
Vereinfacht gesagt liegen dadurch zum Beispiel alle Zeitstempel, alle Länder oder alle Event-Namen jeweils zusammen, anstatt komplette Events als einzelne Zeilen zu speichern.
Wenn ich also nur wissen möchte, wie viele Pageviews aus Deutschland in den letzten 30 Tagen kamen, muss ClickHouse nur die dafür relevanten Spalten auswerten.
Bei ein paar tausend Events spielt dieser Unterschied natürlich noch keine große Rolle. Je größer die Datenmenge wird, desto interessanter wird dieser Ansatz aber, weil für viele Analytics-Abfragen nur ein kleiner Teil der gespeicherten Daten gelesen werden muss.
Genau das war für mich einer der Gründe, ClickHouse von Anfang an für die Analytics-Daten von Lienks zu verwenden. Nicht weil PostgreSQL aktuell zu langsam wäre, sondern weil ich davon ausgehe, dass die Menge an Events mit der Zeit wächst und auch die Auswertungen komplexer werden.
PostgreSQL und ClickHouse bei Lienks
Das heißt aber nicht, dass PostgreSQL bei Lienks keine Rolle spielt. Im Gegenteil: Beide Datenbanken laufen nebeneinander und haben unterschiedliche Aufgaben.
PostgreSQL nutze ich für die klassischen Anwendungsdaten. Dort liegen zum Beispiel Nutzer, Workspaces, Websites, Mitglieder, Billing und Nutzungslimits.
Die eigentlichen Analytics-Daten landen dagegen in ClickHouse. Dazu gehören Pageviews und Custom Events mit Informationen wie Zeitpunkt, Pfad, Referrer, Land, Browser oder Gerät.
Für mich macht diese Trennung auch konzeptionell Sinn. Wenn ich einen Nutzer oder eine Website aus PostgreSQL lade, suche ich meistens nach wenigen konkreten Datensätzen. Bei den Analytics-Daten ist es genau andersherum: Dort möchte ich oft sehr viele Events gleichzeitig auswerten und daraus zum Beispiel eine Zahl, eine Zeitreihe oder ein Ranking berechnen.
Das ist genau der Unterschied aus der Grafik oben: Für einen einzelnen Nutzer brauche ich die ganze Zeile, für eine Auswertung über Millionen Events nur ein paar Spalten.
Warum ClickHouse gut zu Web Analytics passt
Die Spaltenorientierung ist aber nicht der einzige Grund. Events haben ein paar Eigenschaften, die ClickHouse besonders entgegenkommen.
Erstens werden Events geschrieben und danach nicht mehr angefasst. Ein Pageview, der einmal gespeichert ist, ändert sich nie wieder. Bei Anwendungsdaten ist das anders: Dort ändert ein Nutzer seine E-Mail-Adresse oder ein Workspace bekommt einen neuen Namen. ClickHouse ist genau auf den ersten Fall ausgelegt, also darauf, sehr viele neue Zeilen schnell aufzunehmen, ohne dass bestehende ständig geändert werden.
Zweitens wiederholen sich die Werte stark. In der Länderspalte steht tausendfach „DE”, in der Gerätespalte immer wieder „mobile” oder „desktop”, und auch Pfade und Referrer kommen ständig vor. Weil ClickHouse alle Werte einer Spalte zusammen speichert, lassen sie sich sehr gut komprimieren. Die Daten brauchen dadurch weniger Platz, und bei einer Abfrage muss weniger gelesen werden.
Drittens ist fast jede Frage im Dashboard eine Auswertung über einen Zeitraum. Wie viele Besucher gab es in den letzten 7 Tagen? Welche Seiten wurden diesen Monat am häufigsten aufgerufen? Über welche Referrer kamen die meisten Besucher? Dafür muss die Datenbank viele Events zählen, gruppieren und sortieren, und genau darin ist ClickHouse schnell.
Das ist kein Zufall: ClickHouse wurde ursprünglich bei Yandex für deren eigenen Web-Analytics-Dienst entwickelt. Web Analytics ist also der Fall, für den die Datenbank gebaut wurde. Ich muss sie nicht verbiegen, damit sie zu meinen Daten passt.
Brauche ich ClickHouse für den Start?
Die ehrliche Antwort ist: Nein, für die aktuelle Größe von Lienks würde wahrscheinlich auch PostgreSQL vollkommen ausreichen.
PostgreSQL kommt mit ein paar Millionen Zeilen gut zurecht, und mit den richtigen Indizes wären die Abfragen im Dashboard auch dort schnell genug.
Dazu kommt, dass ClickHouse nicht umsonst ist. Ich betreibe jetzt zwei Datenbanken statt einer, mit zwei Containern und zwei Sätzen an Migrationen. Wird eine Website gelöscht, muss ich an zwei Stellen aufräumen. Und wenn ich Daten aus beiden Welten zusammen brauche, etwa die Anzahl der Events pro Workspace, kann ich keinen einfachen Join schreiben, sondern muss die Ergebnisse im Code zusammenführen.
Warum habe ich es trotzdem gemacht? Ich habe mir am Anfang die Frage gestellt, was langfristig mehr Sinn ergibt. PostgreSQL hätte lange gereicht. Sollte Lienks aber wirklich viele Nutzer bekommen, geht es schnell um Hunderte Millionen oder Milliarden von Events, und dafür ist ClickHouse aus meiner Sicht die bessere Lösung. Dann wollte ich lieber von Anfang an das nehmen, was auf Dauer passt, statt die Daten später im laufenden Betrieb umziehen zu müssen.
Für mich war es also weniger eine Entscheidung für heute als eine Wette auf später. Der Mehraufwand ist real, aber überschaubar, und ich zahle ihn lieber jetzt als mitten im Wachstum.
Würde ich ClickHouse auch für andere Projekte nutzen?
Trotz meiner guten Erfahrungen mit ClickHouse würde ich es nicht einfach in jedes neue Projekt einbauen.
Die meisten Anwendungen bestehen aus Daten, die sich ständig ändern: Nutzer, Bestellungen, Einstellungen. Genau dafür ist ClickHouse nicht gemacht. Einzelne Datensätze zu ändern oder zu löschen ist dort umständlich, und Transaktionen, wie man sie aus PostgreSQL kennt, gibt es nicht. Für solche Daten bleibt PostgreSQL meine erste Wahl, auch bei Lienks.
Anders sieht es aus, wenn ein Projekt sehr viele gleichartige Einträge sammelt, die nur geschrieben und später ausgewertet werden. Das können Events sein wie bei Lienks, aber auch Logs oder Messwerte. Cloudflare wertet mit ClickHouse seinen Web-Traffic aus, und auch das Analytics-Tool PostHog baut darauf auf. Sobald ich weiß, dass solche Daten der Kern des Produkts sind und schnell wachsen können, würde ich ClickHouse wieder früh einplanen.
Meine Faustregel ist deshalb: PostgreSQL für alles, was die Anwendung verwaltet, und ClickHouse erst dann dazu, wenn es Daten gibt, die wie Events aussehen. Bei Lienks war das von Anfang an der Fall.