— ist ein spaltenbasiertes Datenbankverwaltungssystem für die Online-Verarbeitung analytischer Abfragen (OLAP) mit offenem Quellcode, entwickelt von Yandex. Es wird von Yandex, CloudFlare, VK.com, Badoo und anderen Diensten weltweit verwendet, um wirklich große Datenmengen zu speichern (Einfügen von Tausenden von Zeilen pro Sekunde oder Petabyte von Daten, die auf der Festplatte gespeichert sind).
In einer herkömmlichen „zeilenbasierten“ Datenbank, wie beispielsweise MySQL, Postgres, MS SQL Server, werden die Daten in folgender Reihenfolge gespeichert:
Dabei werden die Werte, die zu einer Zeile gehören, physisch nah beieinander gespeichert. In spaltenbasierten Datenbanken werden die Werte aus verschiedenen Spalten separat gespeichert, während die Daten einer Spalte zusammen gespeichert werden:
Beispiele für spaltenbasierte Datenbanken sind Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Unternehmen – Mail-Forwarder begann 2018 mit der Nutzung von Clickhouse zur Erstellung von Berichten und war von der Einfachheit, Skalierbarkeit, SQL-Unterstützung und Geschwindigkeit sehr beeindruckt. Die Schnelligkeit dieses DBMS grenzte an Magie.
Einfachheit
Clickhouse wird in Ubuntu mit einem einzigen Befehl installiert. Wenn Sie SQL kennen, können Sie sofort beginnen, Clickhouse für Ihre Bedürfnisse zu verwenden. Das bedeutet jedoch nicht, dass Sie „show create table“ in MySQL ausführen und SQL einfach in Clickhouse kopieren können.
Im Vergleich zu MySQL gibt es in dieser Datenbank wichtige Unterschiede bei den Datentypen in den Tabellenschemata, daher benötigen Sie etwas Zeit, um die Definitionen der Tabellenschemata anzupassen und die Tabellentechnologien zu studieren.
Clickhouse funktioniert hervorragend ohne zusätzliche Software, aber wenn Sie Replikation verwenden möchten, müssen Sie ZooKeeper installieren. Performance-Analysen der Abfragen zeigen hervorragende Ergebnisse – die systemeigenen Tabellen enthalten alle Informationen, und alle Daten können mit altem und langweiligem SQL abgerufen werden.
Leistung
- Vergleiche von Clickhouse mit Vertica und MySQL auf einem Server mit folgender Konfiguration: zwei Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 auf 8 6TB SATA HDD, ext4.
- Vergleiche von Clickhouse mit dem Cloud-Datenlager Amazon RedShift.
- Ausschnitte aus dem Blog :
Die ClickHouse-Datenbank hat ein sehr einfaches Design – alle Knoten im Cluster haben die gleiche Funktionalität und nutzen nur ZooKeeper zur Koordination. Wir haben ein kleines Cluster aus mehreren Knoten aufgebaut und Tests durchgeführt, bei denen wir festgestellt haben, dass das System über eine recht beeindruckende Leistung verfügt, die den in den Benchmarks für analytische Datenbanken angegebenen Vorteilen entspricht. Wir haben beschlossen, das zugrunde liegende Konzept von ClickHouse näher zu betrachten. Die erste Hürde für unsere Forschung war das Fehlen von Werkzeugen und die geringe Zahl an Mitgliedern der ClickHouse-Community, daher haben wir uns tief in das Design dieser Datenbank vertieft, um zu verstehen, wie sie funktioniert.
ClickHouse unterstützt nicht den direkten Empfang von Daten von Kafka, da es sich einfach um eine Datenbank handelt. Deshalb haben wir einen eigenen Adapter-Dienst in der Sprache Go geschrieben. Dieser las die codierten Cap’n Proto-Nachrichten von Kafka, konvertierte sie in TSV und fügte sie in ClickHouse paketweise über die HTTP-Schnittstelle ein. Später haben wir diesen Dienst neu geschrieben, um die Go-Bibliothek gemeinsam mit der eigenen Schnittstelle von ClickHouse zu nutzen, um die Leistung zu steigern. Bei der Bewertung der Paketempfangsleistung haben wir eine wichtige Erkenntnis gewonnen – es stellte sich heraus, dass die Leistung von ClickHouse stark von der Paketgröße abhängt, also der Anzahl der gleichzeitig eingefügten Zeilen. Um zu verstehen, warum das so ist, haben wir untersucht, wie ClickHouse Daten speichert.
Die Hauptengine, genauer gesagt die Familie von Engines für Tabellen, die ClickHouse zur Datenspeicherung verwendet, ist MergeTree. Diese Engine ähnelt konzeptionell dem LSM-Algorithmus, der in Google BigTable oder Apache Cassandra verwendet wird, vermeidet jedoch den Aufbau einer Zwischenspeichertabelle und schreibt Daten direkt auf die Festplatte. Das verleiht ihr eine hervorragende Schreibdurchsatzrate, da jedes eingefügte Paket nur nach dem „Primärschlüssel“ (primary key) sortiert, komprimiert und auf die Festplatte geschrieben wird, um ein Segment zu bilden.
Das Fehlen einer Speichertabelle oder jeglichen Begriffs von "Frische" der Daten bedeutet auch, dass sie nur hinzugefügt werden können; die Änderung oder Löschung wird vom System nicht unterstützt. Derzeit ist die einzige Möglichkeit, Daten zu löschen, die Löschung nach Kalendermonaten, da die Segmente die Monatsgrenze nie überschreiten. Das ClickHouse-Team arbeitet aktiv daran, diese Funktion anpassbar zu machen. Auf der anderen Seite ermöglicht dies ein konfliktfreies Schreiben und Mergen von Segmenten, sodass die Kapazität für Eingaben linear mit der Anzahl der parallelen Einfügungen skalierbar ist, bis I/O oder Kerne gesättigt sind.
Dieses Umstand bedeutet jedoch auch, dass das System nicht für kleine Pakete geeignet ist, weshalb Buffering-Dienste wie Kafka und Inserter verwendet werden. Darüber hinaus führt ClickHouse im Hintergrund kontinuierlich Merges von Segmenten durch, sodass viele kleine Informationsstücke zusammengeführt und häufiger geschrieben werden, wodurch die Schreibintensität erhöht wird. Zu viele unzusammenhängende Teile führen jedoch zu aggressivem Drosseln von Einfügungen, solange das Merging andauert. Wir haben festgestellt, dass der beste Kompromiss zwischen Echtzeit-Dateneingabe und Empfangsleistung die Anpassung an eine begrenzte Anzahl von Einfügungen pro Sekunde ist.
Der Schlüssel zur Lesegeschwindigkeit von Tabellen ist die Indizierung und die Anordnung der Daten auf der Festplatte. Unabhängig davon, wie schnell die Verarbeitung ist, wenn die Engine Terabytes von Daten von der Festplatte scannen muss und nur einen Teil davon verwendet, benötigt dies Zeit. ClickHouse ist ein spaltenbasiertes Lager, sodass jedes Segment eine Datei für jede Spalte mit sortierten Werten für jede Zeile enthält. Somit können ganze Spalten, die nicht in der Anfrage sind, zunächst übersprungen werden, während mehrere Zellen parallel mit vektorisiertem Ausführen verarbeitet werden können. Um eine vollständige Durchsuchung zu vermeiden, hat jedes Segment eine kleine Indexdatei.
Angesichts der Tatsache, dass alle Spalten nach dem „Primärschlüssel“ sortiert sind, enthält die Indexdatei nur die Markierungen (erfasste Zeilen) jeder N-ten Zeile, um sie auch für sehr große Tabellen im Speicher halten zu können. Beispielsweise kann man die Standardoptionen auf „jede 8192. Zeile markieren“ einstellen, was dazu führt, dass die „mageren“ Indizierung der Tabelle mit 1 Billion Zeilen, die problemlos in den Speicher passt, nur 122070 Zeichen in Anspruch nimmt.
Entwicklung des Systems
Die Weiterentwicklung und Verbesserung von Clickhouse lässt sich auf nachverfolgen und man kann sicher sein, dass der „Reifungsprozess“ in beeindruckendem Tempo voranschreitet.
Beliebtheit
Es scheint, dass die Beliebtheit von Clickhouse exponentiell wächst, insbesondere in der russischsprachigen Gemeinschaft. Die letztjährige Konferenz High Load 2018 (Moskau, 8-9. November 2018) zeigte, dass solche Schwergewichte wie vk.com und Badoo Clickhouse nutzen, um Daten (z. B. Protokolle) von zehntausenden Servern gleichzeitig einzufügen. In einem 40-minütigen Video . Demnächst werden wir die Transkription auf Habr zum besseren Arbeiten mit dem Material veröffentlichen.
Anwendungsbereiche
Nachdem ich einige Zeit mit Recherchen verbracht habe, denke ich, dass es Bereiche gibt, in denen ClickHouse nützlich sein kann oder sogar in der Lage ist, andere, traditionellere und beliebtere Lösungen wie MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot und Druid vollständig zu ersetzen. Im Folgenden sind die Details zur Nutzung von ClickHouse zur Modernisierung oder vollständigen Ablösung der oben genannten DBMS aufgeführt.
Erweiterung der Möglichkeiten von MySQL und PostgreSQL
Vor Kurzem haben wir MySQL teilweise durch ClickHouse für die Plattform für Informationsbulletins ersetzt . Das Problem lag darin, dass MySQL aufgrund eines durchdachten Designs jede gesendete E-Mail und jeden Link in dieser E-Mail mit einem base64-Hash registrierte, was eine riesige MySQL-Tabelle (email_stats) erzeugte. Nach dem Versand von nur 10 Millionen E-Mails an die Abonnenten des Dienstes nahm diese Tabelle 150 GB Speicherplatz ein, und MySQL begann, bei einfachen Abfragen „zu träge“ zu werden. Um das Problem des Speicherplatzes zu beheben, haben wir erfolgreich die InnoDB-Tabellenkompression eingesetzt, die die Größe um das Vierfache reduzierte. Aber es macht keinen Sinn, mehr als 20-30 Millionen E-Mails in MySQL nur für die Historie zu speichern, da jede einfache Abfrage, die aus irgendeinem Grund eine vollständige Durchsuchung durchführen muss, zu Swapping und einer hohen Belastung des I/O führt, worüber wir regelmäßig Zabbix-Warnungen erhielten.
Clickhouse verwendet zwei Kompressionsalgorithmen, die das Datenvolumen um etwa , aber in diesem speziellen Fall waren die Daten besonders „komprimierbar“.
Ersetzung von ELK
Aus eigener Erfahrung erfordert der ELK-Stack (ElasticSearch, Logstash und Kibana, in diesem speziellen Fall ElasticSearch) wesentlich mehr Ressourcen zum Betrieb, als für die Speicherung von Protokollen erforderlich ist. ElasticSearch ist eine hervorragende Engine, wenn Sie eine gute Volltextsuche in Protokollen benötigen (und ich denke nicht, dass Sie dies wirklich brauchen), aber ich frage mich, warum es de facto zur Standard-Engine für das Logging geworden ist. Seine Empfangsleistung in Kombination mit Logstash bereitete uns auch bei recht niedrigen Lasten Probleme und erforderte immer mehr RAM und Speicherplatz. Als Datenbank ist Clickhouse aus folgenden Gründen besser als ElasticSearch:
- Unterstützung des SQL-Dialekts;
- Bessere Komprimierungsrate der gespeicherten Daten;
- Unterstützung der Suche nach regulären Ausdrücken (Regex) anstelle der Volltextsuche;
- Verbessertes Abfrage-Management und höhere Gesamtleistung.
Derzeit ist das größte Problem bei der Gegenüberstellung von ClickHouse und ELK das Fehlen von Lösungen zum Laden von Protokollen sowie der Mangel an Dokumentation und Tutorials zu diesem Thema. Dabei kann jeder Benutzer ELK mit dem Digital Ocean-Leitfaden einrichten, was für eine schnelle Einführung solcher Technologien sehr wichtig ist. Hier gibt es eine Datenbank-Engine, aber bisher noch kein Filebeat für ClickHouse. Ja, dieser ist vorhanden. und ein System zur Arbeit mit Protokollen , gibt es ein Werkzeug zum Importieren von Logdateidaten in ClickHouse, aber das erfordert alles mehr Zeit. Dennoch bleibt ClickHouse aufgrund seiner Einfachheit führend, sodass selbst Anfänger es problemlos innerhalb von nur 10 Minuten installieren und zu einer voll funktionsfähigen Nutzung übergehen können.
Bevorzugend minimalistische Lösungen, habe ich versucht, FluentBit, ein Werkzeug zum Laden von Protokollen mit sehr geringer Speicherauslastung, zusammen mit ClickHouse zu verwenden und dabei zu vermeiden, Kafka einzusetzen. Es müssen jedoch einige kleine Inkompatibilitäten beseitigt werden, wie , bevor dies ohne eine Proxy-Schicht möglich ist, die Daten von FluentBit nach ClickHouse umwandelt.
Als Alternative zu Kibana kann ClickHouse als Backend verwendet werden . Soweit ich verstanden habe, können dabei Leistungsprobleme beim Rendern einer riesigen Anzahl von Datenpunkten auftreten, insbesondere mit älteren Versionen von Grafana. Bei Qwintry haben wir das bisher nicht ausprobiert, aber Beschwerden über solche Probleme tauchen von Zeit zu Zeit im Supportkanal von ClickHouse auf Telegram auf.
Ersatz für Google Big Query und Amazon RedShift (Lösung für große Unternehmen)
Der ideale Anwendungsfall für BigQuery besteht darin, 1 TB JSON-Daten hochzuladen und analytische Abfragen darauf auszuführen. BigQuery ist ein hervorragendes Produkt, dessen Skalierbarkeit schwer zu überschätzen ist. Es ist eine viel komplexere Software als ClickHouse, die auf einem internen Cluster läuft, hat aber aus Sicht des Kunden viele Gemeinsamkeiten mit ClickHouse. BigQuery kann schnell "teuer werden", sobald man dafür bezahlt, dass man jeden SELECT ausführt, sodass es sich um eine echte SaaS-Lösung mit all ihren Vor- und Nachteilen handelt.
ClickHouse ist die beste Wahl, wenn Sie viele rechenintensive Abfragen ausführen. Je mehr SELECT-Abfragen Sie jeden Tag durchführen — desto mehr Sinn macht es, BigQuery durch ClickHouse zu ersetzen, da ein solcher Wechsel Ihnen Tausende von Dollar sparen kann, wenn es um viele Terabytes verarbeiteter Daten geht. Dies gilt nicht für gespeicherte Daten, deren Verarbeitung in BigQuery relativ kostengünstig ist.
In dem Artikel von Altinity Mitgründer Alexander Zaizev werden die Vorteile eines solchen DBMS-Migration beschrieben.
Ersatz für TimescaleDB
TimescaleDB ist eine Erweiterung von PostgreSQL, die die Arbeit mit Zeitreihen in einer herkömmlichen Datenbank optimiert., ).
Obwohl ClickHouse kein ernsthafter Konkurrent im Bereich der Zeitreihen ist, ist es in der regelbasierten Verarbeitung und Durchführung von Abfragen in den meisten Fällen deutlich schneller als TimescaleDB. Zudem hat ClickHouse eine etwa dreimal höhere Leistung bei der Verarbeitung von Batch-Daten und benötigt gleichzeitig 20-mal weniger Speicherplatz, was besonders wichtig für die Verarbeitung großer Mengen historischer Daten ist..
Im Gegensatz zu ClickHouse ist der einzige Weg, um in TimescaleDB ein wenig Speicherplatz zu sparen, die Verwendung von ZFS oder ähnlichen Dateisystemen.
Künftige Updates von ClickHouse werden wahrscheinlich Delta-Kompression einführen, die es noch geeigneter für die Verarbeitung und Speicherung von Zeitreihendaten machen wird. TimescaleDB könnte in folgenden Fällen die bessere Wahl im Vergleich zu 'nacktem' ClickHouse sein:
- kleine Installationen mit sehr wenig Arbeitsspeicher (<3 GB);
- eine große Anzahl kleiner INSERTs, die Sie nicht zu großen Fragmenten puffern möchten;
- bessere Konsistenz, Einheitlichkeit und ACID-Anforderungen;
- Unterstützung für PostGIS;
- Integration mit bestehenden PostgreSQL-Tabellen, da TimescaleDB im Wesentlichen PostgreSQL ist.
Wettbewerb mit Hadoop- und MapReduce-Systemen
Hadoop und andere MapReduce-Produkte können viele komplexe Berechnungen durchführen, arbeiten jedoch in der Regel mit enormen Verzögerungen. ClickHouse löst dieses Problem, indem es Terabytes von Daten verarbeitet und nahezu sofort Ergebnisse liefert. Daher ist ClickHouse viel effektiver für die Durchführung schneller, interaktiver Analysen, was für Datenanalyse-Spezialisten von Interesse sein sollte.
Wettbewerb mit Pinot und Druid
Die nächsten Konkurrenten von ClickHouse sind die spaltenbasierten, linear skalierbaren Open-Source-Produkte Pinot und Druid. Ein hervorragender Vergleich dieser Systeme wurde in einem Artikel veröffentlicht. vom 1. Februar 2018.
Dieser Artikel benötigt ein Update – er besagt, dass ClickHouse keine UPDATE- und DELETE-Operationen unterstützt, was in Bezug auf die neuesten Versionen nicht ganz zutrifft.
Wir haben nicht genügend Erfahrung mit diesen DBMS, aber ich finde die Komplexität der Infrastruktur, die für den Betrieb von Druid und Pinot erforderlich ist, überhaupt nicht gut – es handelt sich um eine ganze Menge "beweglicher Teile", die von Java umgeben sind.
Druid und Pinot sind Inkubatorprojekte von Apache, deren Entwicklungsverlauf von Apache auf den Seiten seiner GitHub-Projekte ausführlich beschrieben wird. Pinot trat im Oktober 2018 in den Inkubator ein, während Druid 8 Monate früher, im Februar, ins Leben gerufen wurde.
Das Fehlen von Informationen darüber, wie AFS funktioniert, wirft einige, möglicherweise naive Fragen auf. Interessiert es die Autoren von Pinot, dass die Apache Foundation tendenziell mehr zu Druid neigt, und hat diese Einstellung gegenüber dem Konkurrenten Neid ausgelöst? Wird die Entwicklung von Druid langsamer, während die Entwicklung von Pinot beschleunigt wird, falls die Sponsoren von Druid plötzlich Interesse an Pinot zeigen?
Nachteile von ClickHouse
Unreife: Es ist offensichtlich, dass dies immer noch eine unausgereifte Technologie ist, aber in jedem Fall gibt es nichts Vergleichbares in anderen spaltenbasierten DBMS.
Kleine Einfügungen funktionieren bei hoher Geschwindigkeit schlecht: Einfügungen sollten in großen Stücke unterteilt werden, da die Leistung kleiner Einfügungen proportional zur Anzahl der Spalten in jeder Zeile abnimmt. So werden die Daten in ClickHouse auf der Festplatte gespeichert – jede Spalte entspricht 1 Datei oder mehr, sodass für das Einfügen von 1 Zeile mit 100 Spalten mindestens 100 Dateien geöffnet und geschrieben werden müssen. Deshalb ist ein Vermittler für das Puffern von Einfügungen erforderlich (es sei denn, der Client selbst sorgt für das Puffern) – normalerweise ist dies Kafka oder ein anderes Warteschlangenmanagementsystem. Es kann auch die Engine Buffer table verwendet werden, um später große Datenmengen in MergeTree-Tabellen zu kopieren.
Tabellenverbindungen sind durch den Arbeitsspeicher des Servers begrenzt, aber zumindest gibt es sie dort! Zum Beispiel haben Druid und Pinot überhaupt keine solchen Verbindungen, da sie in verteilten Systemen schwer zu implementieren sind, die das Verschieben großer Datenmengen zwischen Knoten nicht unterstützen.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
In den kommenden Jahren planen wir, ClickHouse umfassend in Qwintry zu nutzen, da diese Datenbank-Management-System eine hervorragende Balance zwischen Leistung, niedrigem Overhead, Skalierbarkeit und Benutzerfreundlichkeit bietet. Ich bin mir fast sicher, dass sie sich schnell verbreiten wird, sobald die ClickHouse-Community mehr Anwendungsmöglichkeiten für kleine und mittelgroße Installationen findet.
Ein wenig Werbung 🙂
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, , ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).
Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie
Quelle: habr.com
