ClickHouse, eine spaltenorientierte Datenbank, erfreut sich aufgrund ihrer hohen Geschwindigkeit und Skalierbarkeit großer Beliebtheit, vor allem bei analytischen Datenanwendungen. Doch eine oft gestellte Frage ist, wie viele Spalten eigentlich sinnvoll sind, und ab wann eine Tabelle „zu breit“ wird. In der Praxis gibt es Anwendungsfälle mit Hunderten oder sogar Tausenden von Metriken, die in einer einzigen Tabelle gespeichert werden sollen. Wie ClickHouse mit solchen Extremen umgeht und welche Auswirkungen das auf Performance, Speicherbedarf und Abfragegeschwindigkeit hat, ist Gegenstand intensiver Untersuchungen. Ein wichtiger Anwendungsfall für sehr breite Tabellen findet sich im Monitoring verschiedener Gerätekategorien, bei denen jede Kategorie eigene, teils sehr unterschiedliche Metriken mitbringt. Wenn alle diese Messwerte in einer gemeinsamen Tabelle abgelegt werden, entsteht schnell eine Vielzahl von Spalten – teils über tausend oder sogar zehntausend.
Es stellt sich somit die Frage, ob es sinnvoller ist, jede Metrik als eigene Spalte zu speichern oder ob alternative Ansätze wie Map-Datentypen oder Schlüssel-Wert-Arrays Vorteile bringen. ClickHouse zeichnet sich dadurch aus, dass das Hinzufügen neuer Spalten sehr effizient und ohne große Performanceeinbußen möglich ist. Viele Anwender nutzen dies, um häufig verwendete Metriken aus komplexen Datenstrukturen wie JSON zu materialisieren. Dadurch entstehen extrem breite Tabellen mit teils 10. 000 Spalten. Doch an dieser Stelle stößt man auf eine Reihe technischer Herausforderungen: die Erstellung, das Einfügen großer Datenmengen, die SQL-Parser-Limits und nicht zuletzt der enorme Speicherbedarf. Das Erstellen einer Tabelle mit zehntausend Spalten ist an sich wenig komplex, solange man auf Hilfsmittel zur automatisierten Generierung von SQL-Statements zurückgreift.
ClickHouse bietet dabei eine einfache Möglichkeit, durch Abfragen mit der Funktion numbers eine große Anzahl von Spalten und passenden Datentypen programmgesteuert zu erzeugen. Die daraus resultierenden SQL-Definitionen für die Tabelle können jedoch sehr umfangreich werden, was zunächst zu Limits beim Parsen führt. Der Einfügevorgang für eine Tabelle mit 10. 000 Spalten stellt noch größere Herausforderungen dar. Standardmäßig überschreitet das erzeugte INSERT-Statement die maximale Abfragegröße und die maximal erlaubten Elemente im Abstract Syntax Tree (AST) von ClickHouse. Deshalb müssen Parameter wie max_query_size und max_ast_elements deutlich erhöht werden. Im weiteren Verlauf zeigt sich, dass auch eine erhebliche Menge Arbeitsspeicher erforderlich ist, da ClickHouse für jede Spalte Pufferressourcen in Anspruch nimmt.
So führte der Test zunächst zu Speicherüberschreitungen bei kleineren Servern und erforderte das Hochskalieren auf eine Maschine mit mindestens 32 vCPUs und 128 GB RAM. Ein weiteres interessantes Experiment war die Nutzung der sogenannten Compact Parts bei MergeTree-Tabellen. Hier werden die Spalten nicht mehr in jeweils eigenen Dateien gespeichert, sondern zusammengefasst. Das Ziel ist, den Speicherbedarf zu reduzieren und Einfügevorgänge zu beschleunigen. Überraschenderweise zeigte sich, dass diese Kompaktbauweise zwar den Speicherbedarf bei Einfügungen senken kann, jedoch die Dauer der Einfügeoperationen verlängert und die Hintergrundprozesse zum Zusammenführen („Mergen“) der Daten stark verlangsamt. Die Merge-Phase ist somit eine ernstzunehmende Leistungsschranke bei der Nutzung sehr breiter Tabellen. Als Alternative zur extrem breiten Tabelle wurde ein Ansatz mit Map-Datentypen untersucht. Dabei werden alle Metriken als Schlüssel-Wert-Paare in einer Map gespeichert.
Dies reduziert zwar die Anzahl der Spalten auf ein überschaubares Maß, führt aber zu einem massiv erhöhten Speicher- und Rechenaufwand bei der Verarbeitung, vor allem beim Einfügen, da riesige Arrays mit zehntausend Elementen für jede Zeile verarbeitet werden müssen. Die Verwendung kleinerer Blockgrößen kann etwas Entlastung bringen, allerdings bleibt die Performance deutlich hinter der breiter Tabellen zurück. Querytests verdeutlichen weitere Stärken und Schwächen der verschiedenen Ansätze. Während die vollständige Scannabfrage auf extrem breiten Tabellen erwartungsgemäß ressourcenintensiv und langsam ist, profitiert man bei Abfragen, die nur wenige Spalten betreffen, von ClickHouses Spaltenorientierung durch sehr schnelle Antwortzeiten bei geringem Speicherverbrauch. Die Map-Tabellen hingegen sind bei Vollscans schneller, weil mehr Daten zeilenorientiert verarbeitet werden, zeigen jedoch Schwächen bei Abfragen, die einzelne Metriken über viele Geräte auswerten.
Eine kritische Beobachtung betrifft den Umgang mit sparsamen Tabellen. In der Realität erzeugen einzelne Geräte meist nur eine kleine Auswahl an Metriken. Deshalb sind Tabellen mit 10. 000 Spalten in vielen Fällen äußerst spärlich besetzt, mit den meisten Spalten leer oder null. In einem solchen Szenario können Map-Datentypen ihre Stärken ausspielen, da sie nur tatsächlich vorhandene Werte speichern und Nullwerte meiden. Ein zusätzliches Experiment mit sparsamen Map-Tabellen zeigte, dass sich die Datenmengen und Ladezeiten drastisch reduzieren lassen, was den Weg für effizientere Speicher- und Verarbeitungsmodelle ebnet. Überlegungen zur Architektur und Datenmodellierung bringen auch den Ansatz ins Spiel, statt einer großen Breitentabelle mehrere kleinere thematisch geordnete Tabellen zu verwenden. So könnten für jede Gerätekategorie oder Metrikgruppe eigene Tabellen mit jeweils wenigen Spalten definiert werden.
Dieses Modell vermeidet extreme Spaltenanzahlen und vereinfacht das Management einzelner Tabellen. Allerdings entsteht dadurch einerseits ein erhöhter Verwaltungsaufwand und andererseits höhere Merge-Kosten, da viel mehr Tabellen parallel gepflegt und bearbeitet werden müssen. Zudem bedarf eine solche Lösung intelligenter Query-Routing-Mechanismen auf Anwendungsseite. Die Studie zeigt, dass sowohl extrem breite Tabellen mit zehntausend Spalten als auch Map-basierte Tabellen praktikable Lösungen sein können, jeweils mit spezifischen Vor- und Nachteilen. Die extrem breiten Tabellen fordern mehr Ressourcen, erlauben jedoch eine herausragende Performance bei typischen analytischen Operationen, insbesondere wenn nur wenige Spalten abgefragt werden. Map-Tabellen sind effizient bei Speicher- und Ladeoperationen für sehr spärliche Daten, neigen aber zu Performanceeinbußen bei komplexen Mehrspaltenabfragen.
Die Grenzen von ClickHouse hinsichtlich der Spaltenanzahl zeigen, dass eine Anzahl von rund 1. 000 Spalten ohne größere Konfigurationsänderungen problemlos verarbeitet werden kann. Darüber hinaus wird ein signifikanter Mehraufwand in Bezug auf Speicher und Tuning erforderlich. Gleichzeitig bieten flexible Modellierungsoptionen und unterschiedliche Datentypen Anwendern die Möglichkeit, das optimale Schema für ihre individuellen Bedürfnisse zu gestalten und dabei die verfügbaren Systemressourcen effizient zu nutzen. Für Unternehmen und Entwickler bedeutet dies, dass das Verständnis der zugrundeliegenden Konzepte und Limes unerlässlich ist, um das volle Potenzial von ClickHouse auszuschöpfen. Ein fundiertes Testing, angepasst an die spezifischen Datenstrukturen und Anwendungsszenarien, ist der Schlüssel zur erfolgreichen Implementierung von breiten Tabellen und zur Vermeidung von langfristigen Performanceproblemen.
Abschließend erweist sich ClickHouse als äußerst flexibel und robust auch bei extremen Tabellenlayouts. Die Entscheidung zwischen breiten Tabellen, Map-Datentypen oder einer Segmentierung in mehrere Tabellen sollte immer im Kontext der Datenverteilung, Abfrageprofile und Infrastrukturressourcen getroffen werden. Wer diese Faktoren berücksichtigt, gewinnt mit ClickHouse eine hochperformante und skalierbare Plattform für Big-Data-Analysen und Monitoring-Lösungen.
