ist ein Open-Source-Säulendatenbankverwaltungssystem für die analytische Online-Abfrageverarbeitung (OLAP), das von Yandex entwickelt wurde. Es wird von Yandex, CloudFlare, VK.com, Badoo und anderen Diensten auf der ganzen Welt verwendet, um wirklich große Datenmengen zu speichern (Einfügung von Tausenden von Zeilen pro Sekunde oder Petabytes an auf der Festplatte gespeicherten Daten).
In einem normalen „String“-DBMS, Beispiele hierfür sind MySQL, Postgres, MS SQL Server, werden Daten in dieser Reihenfolge gespeichert:
In diesem Fall werden die zu einer Zeile gehörenden Werte physikalisch nebeneinander gespeichert. In spaltenbasierten DBMS werden Werte aus verschiedenen Spalten separat gespeichert und die Daten einer Spalte werden zusammen gespeichert:
Beispiele für spaltenorientierte DBMS 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+.
Das Unternehmen ist eine Postweiterleitung Ich habe 2018 begonnen, Clickhouse für die Berichterstellung zu verwenden und war von seiner Einfachheit, Skalierbarkeit, SQL-Unterstützung und Geschwindigkeit sehr beeindruckt. Die Geschwindigkeit dieses DBMS grenzte an Magie.
Erleichtern
Clickhouse wird mit einem einzigen Befehl auf Ubuntu installiert. Wenn Sie sich mit SQL auskennen, können Sie Clickhouse sofort für Ihre Bedürfnisse nutzen. Dies bedeutet jedoch nicht, dass Sie in MySQL „Tabelle erstellen“ anzeigen und SQL in Clickhouse kopieren und einfügen können.
Im Vergleich zu MySQL gibt es in diesem DBMS wichtige Datentypunterschiede in den Tabellenschemadefinitionen, sodass Sie noch etwas Zeit benötigen, um die Tabellenschemadefinitionen zu ändern und sich mit den Tabellen-Engines vertraut zu machen.
Clickhouse funktioniert ohne zusätzliche Software hervorragend. Wenn Sie jedoch die Replikation verwenden möchten, müssen Sie ZooKeeper installieren. Die Analyse der Abfrageleistung zeigt hervorragende Ergebnisse – die Systemtabellen enthalten alle Informationen und alle Daten können mit altem und langweiligem SQL abgerufen werden.
Leistung
- Vergleiche von Clickhouse mit Vertica und MySQL auf dem Konfigurationsserver: zwei Sockel Intel® Xeon® CPU E5-2650 v2 bei 2.60 GHz; 128 GiB RAM; MD RAID-5 auf 8 6 TB SATA-Festplatten, ext4.
- Vergleich von Clickhouse mit Amazon RedShift Cloud-Speicher.
- Blog-Auszüge :
Die ClickHouse-Datenbank hat ein sehr einfaches Design – alle Knoten im Cluster verfügen über die gleiche Funktionalität und verwenden ausschließlich ZooKeeper zur Koordination. Wir haben einen kleinen Cluster aus mehreren Knoten aufgebaut und Tests durchgeführt, bei denen wir festgestellt haben, dass das System eine recht beeindruckende Leistung aufweist, die den behaupteten Vorteilen in analytischen DBMS-Benchmarks entspricht. Wir haben uns entschieden, das Konzept hinter ClickHouse genauer unter die Lupe zu nehmen. Das erste Hindernis für die Forschung war der Mangel an Tools und die kleine Community von ClickHouse. Deshalb haben wir uns intensiv mit dem Design dieses DBMS befasst, um zu verstehen, wie es funktioniert.
ClickHouse unterstützt den direkten Empfang von Daten von Kafka nicht, da es sich nur um eine Datenbank handelt. Deshalb haben wir unseren eigenen Adapterdienst in Go geschrieben. Es las Cap'n Proto-codierte Nachrichten von Kafka, konvertierte sie in TSV und fügte sie über die HTTP-Schnittstelle stapelweise in ClickHouse ein. Später haben wir diesen Dienst umgeschrieben, um die Go-Bibliothek in Verbindung mit unserer eigenen ClickHouse-Schnittstelle zu verwenden und so die Leistung zu verbessern. Bei der Bewertung der Leistung beim Empfang von Paketen haben wir etwas Wichtiges entdeckt: Es stellte sich heraus, dass diese Leistung bei ClickHouse stark von der Größe des Pakets abhängt, also von der Anzahl der gleichzeitig eingefügten Zeilen. Um zu verstehen, warum dies geschieht, haben wir untersucht, wie ClickHouse Daten speichert.
Die Haupt-Engine bzw. eine Familie von Tabellen-Engines, die ClickHouse zum Speichern von Daten 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. Dies sorgt für einen hervorragenden Schreibdurchsatz, da jedes eingefügte Paket nur nach dem „Primärschlüssel“-Primärschlüssel sortiert, komprimiert und auf die Festplatte geschrieben wird, um ein Segment zu bilden.
Das Fehlen einer Speichertabelle oder eines Konzepts der „Aktualität“ der Daten bedeutet auch, dass diese nur hinzugefügt werden können, das System jedoch keine Änderung oder Löschung unterstützt. Derzeit besteht die einzige Möglichkeit zum Löschen von Daten darin, sie pro Kalendermonat zu löschen, da Segmente niemals eine Monatsgrenze überschreiten. Das ClickHouse-Team arbeitet aktiv daran, diese Funktion anpassbar zu machen. Andererseits ist das Schreiben und Zusammenführen von Segmenten konfliktfrei, sodass der Empfangsdurchsatz linear mit der Anzahl paralleler Einfügungen skaliert, bis E/A oder Kerne ausgelastet sind.
Allerdings bedeutet dieser Umstand auch, dass das System nicht für kleine Pakete geeignet ist, sodass zur Pufferung Kafka-Dienste und -Inserter verwendet werden. Darüber hinaus führt ClickHouse im Hintergrund kontinuierlich Segmente zusammen, sodass viele kleine Informationen kombiniert und mehrmals aufgezeichnet werden, wodurch die Intensität der Aufzeichnung erhöht wird. Zu viele unabhängige Teile führen jedoch zu einer aggressiven Drosselung der Einfügungen, solange die Zusammenführung andauert. Wir haben festgestellt, dass der beste Kompromiss zwischen Echtzeit-Datenaufnahme und Aufnahmeleistung darin besteht, eine begrenzte Anzahl von Einfügungen pro Sekunde in die Tabelle zu akzeptieren.
Der Schlüssel zur Tabellenleseleistung ist die Indizierung und der Speicherort der Daten auf der Festplatte. Egal wie schnell die Verarbeitung ist: Wenn die Engine Terabytes an Daten von der Festplatte scannen und nur einen Bruchteil davon nutzen muss, wird es einige Zeit dauern. ClickHouse ist ein Spaltenspeicher, daher enthält jedes Segment eine Datei für jede Spalte (Spalte) mit sortierten Werten für jede Zeile. So können zunächst ganze Spalten, die in der Abfrage nicht vorhanden sind, übersprungen werden und anschließend mehrere Zellen parallel mit vektorisierter Ausführung verarbeitet werden. Um einen vollständigen Scan zu vermeiden, verfügt jedes Segment über eine kleine Indexdatei.
Da alle Spalten nach dem „Primärschlüssel“ sortiert sind, enthält die Indexdatei nur die Labels (erfasste Zeilen) jeder N-ten Zeile, um diese auch bei sehr großen Tabellen im Speicher behalten zu können. Beispielsweise können Sie die Standardeinstellungen auf „jede 8192. Zeile markieren“ und dann auf „magere“ Indizierung einer Tabelle mit 1 Billion festlegen. Zeilen, die problemlos in den Speicher passen, würden nur 122 Zeichen beanspruchen.
Systementwicklung
Die Entwicklung und Verbesserung von Clickhouse lässt sich verfolgen und stellen Sie sicher, dass der Prozess des „Erwachsenwerdens“ in einem beeindruckenden Tempo abläuft.
Popularität
Es scheint, dass die Popularität von Clickhouse exponentiell zunimmt, insbesondere in der russischsprachigen Community. Die High Load 2018-Konferenz im letzten Jahr (Moskau, 8.–9. November 2018) zeigte, dass Monster wie vk.com und Badoo Clickhouse verwenden, das Daten (z. B. Protokolle) von Zehntausenden Servern gleichzeitig einfügt. In einem 40-minütigen Video . In Kürze werden wir das Transkript auf Habr veröffentlichen, um die Arbeit mit dem Material zu erleichtern.
Anwendungen
Nachdem ich einige Zeit mit der Recherche verbracht habe, denke ich, dass es Bereiche gibt, in denen ClickHouse nützlich sein oder andere traditionellere und beliebtere Lösungen wie MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot usw. vollständig ersetzen kann Druide. Im Folgenden finden Sie Einzelheiten zur Verwendung von ClickHouse zum Aktualisieren oder vollständigen Ersetzen des oben genannten DBMS.
Erweiterung von MySQL und PostgreSQL
Zuletzt haben wir MySQL teilweise durch ClickHouse für die Newsletter-Plattform ersetzt . Das Problem bestand darin, dass MySQL aufgrund eines schlecht durchdachten Designs jede gesendete E-Mail und jeden Link in dieser E-Mail mit einem Base64-Hash protokollierte und so eine riesige MySQL-Tabelle (email_stats) erstellte. Nachdem nur 10 Millionen E-Mails an die Abonnenten des Dienstes gesendet wurden, belegte diese Tabelle 150 GB Dateispeicher und MySQL begann bei einfachen Abfragen „dumm“ zu werden. Um das Dateiplatzproblem zu beheben, haben wir die InnoDB-Tabellenkomprimierung erfolgreich eingesetzt, wodurch sie um den Faktor 4 reduziert wurde. Es macht jedoch immer noch keinen Sinn, mehr als 20 bis 30 Millionen E-Mails nur zum Zwecke des Leseverlaufs in MySQL zu speichern, da jede einfache Abfrage, die aus irgendeinem Grund einen vollständigen Scan durchführen muss, zu Swap und hohem I/O-Vorgang führt Overhead, über den wir regelmäßig Zabbix-Warnungen erhielten.
Clickhouse verwendet zwei Komprimierungsalgorithmen, die die Datenmenge um ca. reduzieren , aber in diesem speziellen Fall waren die Daten besonders „komprimierbar“.
ELK-Ersatz
Meiner eigenen Erfahrung nach erfordert der ELK-Stack (ElasticSearch, Logstash und Kibana, in diesem speziellen Fall ElasticSearch) viel mehr Ressourcen zum Ausführen, als zum Speichern von Protokollen erforderlich sind. ElasticSearch ist eine großartige Engine, wenn Sie eine gute Volltext-Protokollsuche wünschen (was Sie meiner Meinung nach nicht wirklich brauchen), aber ich frage mich, warum sie de facto zur Standard-Protokollierungs-Engine geworden ist. Die Aufnahmeleistung in Kombination mit Logstash bereitete uns selbst bei relativ geringen Arbeitslasten Probleme und erforderte die Hinzufügung von immer mehr RAM und Festplattenspeicher. Als Datenbank ist Clickhouse aus folgenden Gründen besser als ElasticSearch:
- Unterstützung für SQL-Dialekte;
- Der beste Komprimierungsgrad der gespeicherten Daten;
- Unterstützung für Regex-Suche anstelle der Volltextsuche;
- Verbesserte Abfrageplanung und bessere Gesamtleistung.
Das derzeit größte Problem beim Vergleich von ClickHouse mit ELK ist das Fehlen von Lösungen zum Hochladen von Protokollen sowie das Fehlen von Dokumentationen und Tutorials zu diesem Thema. Gleichzeitig kann jeder Benutzer ELK mithilfe des Digital Ocean-Handbuchs einrichten, was für die schnelle Implementierung solcher Technologien sehr wichtig ist. Hier gibt es eine Datenbank-Engine, aber noch keinen Filebeat für ClickHouse. Ja da ist und ein System zum Arbeiten mit Protokollen , es gibt ein Werkzeug Protokolldateidaten in ClickHouse einzugeben, aber das alles nimmt mehr Zeit in Anspruch. Aufgrund seiner Einfachheit ist ClickHouse jedoch immer noch führend, sodass auch Anfänger es problemlos installieren und in nur 10 Minuten mit der voll funktionsfähigen Nutzung beginnen können.
Da ich minimalistische Lösungen bevorzuge, habe ich versucht, FluentBit, ein Tool zum Hochladen von Protokollen mit sehr geringem Arbeitsspeicher, mit ClickHouse zu verwenden, während ich versucht habe, die Verwendung von Kafka zu vermeiden. Allerdings müssen kleinere Inkompatibilitäten behoben werden, wie z bevor dies ohne die Proxy-Schicht möglich ist, die Daten von FluentBit in ClickHouse konvertiert.
Alternativ zu Kibana können Sie ClickHouse als Backend verwenden . Soweit ich weiß, kann dies beim Rendern einer großen Anzahl von Datenpunkten zu Leistungsproblemen führen, insbesondere bei älteren Versionen von Grafana. In Qwintry haben wir dies noch nicht ausprobiert, aber von Zeit zu Zeit tauchen auf dem ClickHouse-Supportkanal in Telegram Beschwerden darüber auf.
Ablösung von 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 zu laden und darauf analytische Abfragen auszuführen. Big Query ist ein großartiges Produkt, dessen Skalierbarkeit kaum zu überschätzen ist. Dies ist eine viel komplexere Software als ClickHouse, die auf einem internen Cluster läuft, aber aus Sicht des Kunden hat sie viele Gemeinsamkeiten mit ClickHouse. BigQuery kann schnell „im Preis steigen“, sobald Sie für jedes SELECT bezahlen, es handelt sich also um eine echte SaaS-Lösung mit allen Vor- und Nachteilen.
ClickHouse ist die beste Wahl, wenn Sie viele rechenintensive Abfragen ausführen. Je mehr SELECT-Abfragen Sie täglich ausführen, desto sinnvoller ist es, Big Query durch ClickHouse zu ersetzen, da Sie mit einem solchen Ersatz Tausende von Dollar sparen, wenn es um die Verarbeitung vieler Terabytes an Daten geht. Dies gilt nicht für gespeicherte Daten, deren Verarbeitung in Big Query recht günstig ist.
In einem Artikel von Alexander Zaitsev, Mitbegründer von Altinity beschreibt die Vorteile einer solchen DBMS-Migration.
TimescaleDB-Ersatz
TimescaleDB ist eine PostgreSQL-Erweiterung, die die Arbeit mit Zeitreihen in einer regulären Datenbank optimiert (, ).
Obwohl ClickHouse kein ernsthafter Konkurrent in der Zeitreihen-Nische ist, ist es in Bezug auf die Spaltenstruktur und die Ausführung von Vektorabfragen in den meisten Fällen bei der Verarbeitung analytischer Abfragen viel schneller als TimescaleDB. Gleichzeitig ist die Leistung beim Empfang von ClickHouse-Paketdaten etwa dreimal höher, außerdem wird 3-mal weniger Speicherplatz benötigt, was für die Verarbeitung großer Mengen historischer Daten sehr wichtig ist: .
Im Gegensatz zu ClickHouse besteht die einzige Möglichkeit, in TimescaleDB etwas Speicherplatz zu sparen, darin, ZFS oder ähnliche Dateisysteme zu verwenden.
Kommende Updates für ClickHouse werden voraussichtlich die Delta-Komprimierung einführen, wodurch es sich noch besser für die Verarbeitung und Speicherung von Zeitreihendaten eignet. In den folgenden Fällen ist TimescaleDB möglicherweise die bessere Wahl als bloßes ClickHouse:
- kleine Installationen mit sehr wenig RAM (<3 GB);
- eine große Anzahl kleiner INSERTs, die Sie nicht in große Fragmente puffern möchten;
- bessere Konsistenz, Einheitlichkeit und ACID-Anforderungen;
- PostGIS-Unterstützung;
- Zusammenführung mit vorhandenen PostgreSQL-Tabellen, da Timescale DB im Wesentlichen PostgreSQL ist.
Konkurrenz zu Hadoop- und MapReduce-Systemen
Hadoop und andere MapReduce-Produkte können viele komplexe Berechnungen durchführen, neigen jedoch dazu, mit enormer Latenz zu laufen. ClickHouse behebt dieses Problem, indem es Terabytes an Daten verarbeitet und fast sofort Ergebnisse liefert. Somit ist ClickHouse viel effizienter für die Durchführung schneller, interaktiver Analyseforschung, was für Datenwissenschaftler interessant sein dürfte.
Konkurrenz zu Pinot und Druid
Die engsten Konkurrenten von ClickHouse sind die säulenförmigen, linear skalierbaren Open-Source-Produkte Pinot und Druid. Eine hervorragende Arbeit zum Vergleich dieser Systeme ist in dem Artikel veröffentlicht 1 Februar 2018
Dieser Artikel muss aktualisiert werden – er besagt, dass ClickHouse die UPDATE- und DELETE-Operationen nicht unterstützt, was in Bezug auf die neuesten Versionen nicht ganz zutrifft.
Wir haben nicht viel Erfahrung mit diesen DBMS, aber mir gefällt die Komplexität der zugrunde liegenden Infrastruktur nicht, die zum Ausführen von Druid und Pinot erforderlich ist – es handelt sich um eine ganze Reihe „beweglicher Teile“, die von allen Seiten von Java umgeben sind.
Druid und Pinot sind Apache-Inkubatorprojekte, die von Apache auf seinen GitHub-Projektseiten ausführlich behandelt werden. Pinot erschien im Oktober 2018 im Brutkasten und Druid wurde 8 Monate zuvor geboren – im Februar.
Der Mangel an Informationen über die Funktionsweise von AFS wirft für mich einige und vielleicht dumme Fragen auf. Ich frage mich, ob den Autoren von Pinot aufgefallen ist, dass die Apache Foundation eher gegenüber Druiden eingestellt ist, und hat eine solche Haltung gegenüber einem Konkurrenten ein Gefühl des Neids hervorgerufen? Wird sich die Entwicklung von Druid verlangsamen und die Entwicklung von Pinot beschleunigen, wenn die Sponsoren, die Ersteres unterstützen, sich plötzlich für Letzteres interessieren?
Nachteile von ClickHouse
Unreife: Offensichtlich ist dies immer noch eine langweilige Technologie, aber auf jeden Fall gibt es in anderen spaltenbasierten DBMS nichts Vergleichbares.
Kleine Einfügungen funktionieren bei hoher Geschwindigkeit nicht gut: Einfügungen müssen in große Blöcke aufgeteilt werden, da die Leistung kleiner Einfügungen proportional zur Anzahl der Spalten in jeder Zeile abnimmt. So speichert ClickHouse Daten auf der Festplatte – jede Spalte bedeutet 1 Datei oder mehr. Um also 1 Zeile mit 100 Spalten einzufügen, müssen Sie mindestens 100 Dateien öffnen und schreiben. Aus diesem Grund erfordert die Einfügungspufferung einen Vermittler (es sei denn, der Client selbst stellt die Pufferung bereit) – normalerweise Kafka oder eine Art Warteschlangensystem. Sie können die Buffer-Tabellen-Engine auch verwenden, um später große Datenmengen in MergeTree-Tabellen zu kopieren.
Tabellenverknüpfungen sind durch den Server-RAM begrenzt, aber zumindest sind sie vorhanden! Druid und Pinot verfügen beispielsweise überhaupt nicht über solche Verbindungen, da es schwierig ist, sie direkt in verteilten Systemen zu implementieren, die das Verschieben großer Datenmengen zwischen Knoten nicht unterstützen.
Befund
In den kommenden Jahren planen wir, ClickHouse in Qwintry umfassend zu nutzen, da dieses DBMS eine hervorragende Balance aus Leistung, geringem Overhead, Skalierbarkeit und Einfachheit bietet. Ich bin mir ziemlich sicher, dass es sich schnell verbreiten wird, sobald die ClickHouse-Community mehr Möglichkeiten findet, es in kleinen und mittleren Installationen zu verwenden.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com