— ist ein spaltenbasiertes Datenbankmanagementsystem für die Online-Analyseverarbeitung (OLAP) mit offenem Quellcode, das von Yandex entwickelt wurde. Es wird von Unternehmen wie Yandex, CloudFlare, VK.com, Badoo und anderen weltweit genutzt, um wirklich große Datenmengen zu speichern (einfügen von Tausenden von Zeilen pro Sekunde oder Petabytes von Daten auf der Festplatte).
In einer herkömmlichen, 'zeilenbasierten' Datenbank, wie MySQL, Postgres, MS SQL Server, werden die Daten in folgender Reihenfolge gespeichert:
Dabei befinden sich die Werte, die zu einer Zeile gehören, physisch nahe beieinander. In spaltenbasierten Datenbanken werden die Werte aus verschiedenen Spalten separat gespeichert, während die Daten einer Spalte zusammengefasst 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 – Mailweiterleitungsdienst Ich begann 2018 mit Clickhouse für Berichte und war sehr beeindruckt von seiner Einfachheit, Skalierbarkeit, SQL-Unterstützung und Geschwindigkeit. Die Schnelligkeit dieser Datenbank grenzte an Magie.
Einfachheit
Clickhouse lässt sich in Ubuntu mit nur einem einzigen Befehl installieren. Wenn Sie SQL kennen, können Sie sofort beginnen, Clickhouse für Ihre Bedürfnisse zu nutzen. Das bedeutet jedoch nicht, dass Sie einfach 'show create table' in MySQL ausführen und den SQL-Code eins zu eins in Clickhouse kopieren können.
Im Vergleich zu MySQL gibt es in dieser Datenbank wichtige Unterschiede bei den Datentypen in den Tabellenschema-Definitionen. Daher benötigen Sie etwas Zeit, um die Tabellenschema-Definitionen zu ändern und sich mit den Tabelleneigenheiten vertraut zu machen.
Clickhouse funktioniert hervorragend ohne zusätzliche Software, aber wenn Sie Replikation nutzen möchten, müssen Sie ZooKeeper installieren. Die Leistungsanalyse von Abfragen zeigt hervorragende Ergebnisse – die Systemtabellen enthalten alle Informationen, und alle Daten können mit einfachem und vertrautem SQL abgerufen werden.
Leistung
- Vergleiche von Clickhouse mit Vertica und MySQL auf einer Konfiguration: zwei Intel® Xeon® CPU E5-2650 v2 @ 2,60 GHz; 128 GiB RAM; md RAID-5 mit 8 x 6TB SATA HDD, ext4.
- Vergleiche von Clickhouse mit dem Cloud-Datenlager Amazon RedShift.
- Auszüge aus dem Blog :
Die Datenbank ClickHouse hat ein sehr einfaches Design – alle Knoten im Cluster haben die gleiche Funktionalität und verwenden 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 eine ziemlich beeindruckende Leistung aufweist, die den in den Benchmark-Tests für analytische DBMS angegebenen Vorteilen entspricht. Wir haben uns entschieden, das Konzept hinter ClickHouse genauer zu betrachten. Das erste Hindernis für unsere Untersuchungen war das Fehlen von Werkzeugen und die geringe Anzahl der ClickHouse-Community, weshalb wir uns eingehend mit dem Design dieser DBMS beschäftigt haben, um zu verstehen, wie es funktioniert.
ClickHouse unterstützt den direkten Empfang von Daten von Kafka nicht, da es sich lediglich um eine Datenbank handelt. Daher haben wir einen eigenen Adapter-Service in Go entwickelt. Dieser las die kodierten Cap’n Proto-Nachrichten von Kafka, konvertierte sie in TSV und fügte sie über die HTTP-Schnittstelle in ClickHouse ein. Später haben wir diesen Service umgeschrieben, um die Go-Bibliothek zusammen mit der eigenen ClickHouse-Schnittstelle zu nutzen, um die Leistung zu steigern. Bei der Bewertung der Paketempfangsleistung haben wir etwas Wichtiges festgestellt: Die Leistung von ClickHouse hängt stark von der Paketgröße ab, also von der Anzahl der gleichzeitig eingefügten Zeilen. Um zu verstehen, warum dies der Fall ist, haben wir untersucht, wie ClickHouse Daten speichert.
Das Hauptspeichermodul, genauer gesagt, die Familie der Speichermodule für Tabellen, die ClickHouse zur Speicherung von Daten verwendet, ist MergeTree. Dieses Modul ähnelt konzeptionell dem LSM-Algorithmus, der in Google BigTable oder Apache Cassandra zum Einsatz kommt, vermeidet jedoch die Erstellung einer Zwischenspeichertabelle und schreibt die Daten direkt auf die Festplatte. Dies sorgt für eine hervorragende Schreibgeschwindigkeit, da jedes eingehende Paket lediglich nach dem "primären Schlüssel" oder primary key sortiert, komprimiert und auf die Festplatte geschrieben wird, um ein Segment zu bilden.
Das Fehlen einer Speicherkarten-Tabelle oder eines Konzepts für die "Frische" von Daten bedeutet, dass diese nur hinzugefügt werden können; eine Änderung oder Löschung unterstützt das System nicht. Derzeit ist der einzige Weg, Daten zu löschen, die nach Kalendermonaten zu entfernen, da Segmente niemals die Monatsgrenze überschreiten. Das ClickHouse-Team arbeitet intensiv daran, diese Funktion anpassbar zu gestalten. Auf der anderen Seite ermöglicht dies das konfliktfreie Schreiben und Zusammenführen von Segmenten, wodurch die Empfangsbandbreite linear mit der Anzahl paralleler Einfügungen skalierbar ist, bis eine Sättigung von I/O oder Kernen eintritt.
Dieses Umstand bedeutet jedoch auch, dass das System nicht für kleine Pakete geeignet ist, weshalb Kafka-Dienste und Inserter für das Puffern verwendet werden. Darüber hinaus führt ClickHouse im Hintergrund kontinuierlich die Zusammenführung von Segmenten durch, sodass viele kleine Informationsteile zusammengefasst und mehrfach gespeichert werden. Dadurch wird die Schreibintensität erhöht. Zu viele nicht zusammenhängende Teile führen jedoch zu aggressivem Throttling der Einfügungen, solange die Zusammenführung fortgesetzt wird. Wir haben festgestellt, dass der beste Kompromiss zwischen der Echtzeitdatenaufnahme und der Aufnahmeleistung darin besteht, die Tabelle mit einer begrenzten Anzahl von Einfügungen pro Sekunde zu füllen.
Der Schlüssel zur Leistungsfähigkeit von Tabellenauslesungen liegt in der Indizierung und der Anordnung der Daten auf der Festplatte. Egal wie schnell die Verarbeitung ist, wenn die Engine Terabytes an Daten scannen muss und nur einen Teil davon verwendet, kostet das Zeit. ClickHouse ist ein spaltenbasiertes Datenlager, daher enthält jedes Segment eine Datei für jede Spalte mit sortierten Werten für jede Zeile. Auf diese Weise können ganze Spalten, die nicht in der Anfrage enthalten sind, zunächst übersprungen werden, und dann können mehrere Zellen dank der vektorisierte Ausführung parallel verarbeitet werden. Um eine vollständige Durchsuchung zu vermeiden, hat jedes Segment eine kleine Indexdatei.
Da alle Spalten nach dem „Primärschlüssel“ sortiert sind, enthält die Indexdatei nur 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 Standardeinstellung „jede 8192. Zeile markieren“ festlegen, wodurch die „magerige“ Indizierung einer Tabelle mit 1 Billion Zeilen, die problemlos in den Speicher passt, nur 122.070 Zeichen in Anspruch nimmt.
Entwicklung des Systems
Die Entwicklung und Verbesserung von Clickhouse lässt sich auf nachvollziehen und zeigt, dass der Prozess des „Wachstums“ in beeindruckendem Tempo voranschreitet.
Beliebtheit
Es scheint, als würde die Popularität von Clickhouse exponentiell steigen, besonders in der russischsprachigen Gemeinschaft. Die letztjährige Konferenz High Load 2018 (Moskau, 8.-9. November 2018) zeigte, dass Größen wie vk.com und Badoo Clickhouse nutzen, um Daten (zum Beispiel Protokolle) von Zehntausenden von Servern gleichzeitig einzuspeisen. In einem 40-minütigen Video Bald werden wir das Transkript auf Habr zur besseren Nutzung der Materialien veröffentlichen.
Anwendungsbereiche
Nachdem ich einige Zeit mit Recherchen verbracht habe, glaube ich, dass es Bereiche gibt, in denen ClickHouse nützlich sein kann oder in der Lage ist, andere, traditionellere und populärere Lösungen wie MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot und Druid vollständig zu ersetzen. Die Einzelheiten zur Verwendung von ClickHouse zur Modernisierung oder vollständigen Ersetzung der oben genannten Datenbanken werden im Folgenden dargelegt.
Erweiterung der Möglichkeiten von MySQL und PostgreSQL
Kürzlich haben wir MySQL teilweise durch ClickHouse für unsere Newsletter-Plattform ersetzt. . Das Problem war, dass MySQL aufgrund eines unüberlegten Designs jede gesendete E-Mail und jeden Link in dieser E-Mail mit einem base64-Hash registrierte, wodurch eine riesige MySQL-Tabelle (email_stats) entstand. Nach dem Versand von nur 10 Millionen E-Mails an die Abonnenten belegte diese Tabelle 150 GB Speicherplatz, und MySQL begann bei einfachen Abfragen zu „stocken“. Um das Platzproblem zu beheben, haben wir erfolgreich die InnoDB-Tabelle komprimiert, was ihren Platz um das Vierfache reduzierte. Dennoch macht es keinen Sinn, mehr als 20-30 Millionen E-Mails in MySQL nur für die Geschichte zu speichern, da jede einfache Abfrage, die aus irgendeinem Grund einen vollständigen Scan durchführen muss, zu Swapping und einer hohen I/O-Belastung 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
Basierend auf eigener Erfahrung benötigt der ELK-Stack (ElasticSearch, Logstash und Kibana, in diesem speziellen Fall ElasticSearch) erheblich mehr Ressourcen zum Betrieb, als für die Speicherung von Protokollen erforderlich wäre. ElasticSearch ist eine hervorragende Engine, wenn Sie eine gute Volltextsuche in den Logs benötigen (und ich bezweifle, dass Sie das tatsächlich brauchen), aber es interessiert mich, warum es de facto der Standard für das Logging geworden ist. Seine Eingangsleistung in Kombination mit Logstash hat uns sogar bei relativ geringen Lasten Probleme bereitet und erforderte stetig mehr RAM und Speicherplatz. Im Vergleich zu ElasticSearch ist Clickhouse aus folgenden Gründen als Datenbank überlegen:
- Unterstützung des SQL-Dialekts;
- Bessere Kompressionsrate der gespeicherten Daten;
- Unterstützung für reguläre Ausdrücke (Regex) anstelle von Volltextsuchen;
- Verbesserte Abfrageplanung und insgesamt höhere Leistung.
Aktuell ist das größte Problem beim Vergleich von ClickHouse mit ELK die fehlenden Lösungen zum Versand von Logs sowie die unzureichende Dokumentation und Schulungsmaterialien zu diesem Thema. Jeder Benutzer kann jedoch ELK mithilfe des Digital Ocean Handbuchs einrichten, was für eine schnelle Implementierung solcher Technologien von entscheidender Bedeutung ist. Es gibt eine Datenbank-Engine, aber für ClickHouse ist Filebeat noch nicht verfügbar. Ja, es ist vorhanden, und ein System zur Verarbeitung von Logs , es gibt ein Werkzeug , um Log-Dateidaten in ClickHouse einzufügen, aber all dies erfordert mehr Zeit. Dennoch bleibt ClickHouse aufgrund seiner Einfachheit führend, sodass selbst Anfänger es unkompliziert installieren und innerhalb von nur 10 Minuten voll funktionsfähig nutzen können.
Ich bevorzuge minimalistische Lösungen und habe versucht, FluentBit, ein Werkzeug zum Versand von Logs mit einem sehr geringen Speicherbedarf, zusammen mit ClickHouse zu verwenden, dabei jedoch die Verwendung von Kafka zu vermeiden. Es müssen jedoch einige kleine Inkonsistenzen behoben werden, wie etwa , bevor dies ohne eine Proxy-Schicht, die die Daten von FluentBit in ClickHouse umwandelt, durchgeführt werden kann.
Alternativ zu Kibana kann ClickHouse als Backend verwendet werden . Soweit ich verstanden habe, können dabei Leistungsprobleme beim Rendern von riesigen Datenpunkten auftreten, insbesondere bei älteren Versionen von Grafana. Bei Qwintry haben wir das bisher nicht ausprobiert, aber die Beschwerden darüber tauchen ab und zu im Support-Kanal von ClickHouse auf Telegram auf.
Ersatz für Google Big Query und Amazon RedShift (Lösung für große Unternehmen)
Die ideale Nutzung von BigQuery besteht darin, 1 TB JSON-Daten hochzuladen und analytische Abfragen darauf auszuführen. BigQuery ist ein großartiges Produkt, dessen Skalierbarkeit schwer zu überschätzen ist. Es ist deutlich komplexere Software als ClickHouse, das auf einem internen Cluster läuft, aber aus Kundensicht hat es viele Gemeinsamkeiten mit ClickHouse. BigQuery kann schnell teuer werden, sobald Sie für jeden SELECT bezahlen, 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 durchführen. Je mehr SELECT-Abfragen Sie täglich ausführen, desto sinnvoller ist es, Big Query durch ClickHouse zu ersetzen. Diese Umstellung kann Ihnen Tausende von Dollar sparen, insbesondere wenn es um große Datenmengen in Terabyte geht. Dies gilt nicht für gespeicherte Daten, deren Verarbeitung in Big Query relativ kostengünstig ist.
Im Artikel des Mitbegründers von Altinity, Alexander Zaytsev werden die Vorteile einer solchen Migration der Datenbank erläutert.
Ersetzung von TimescaleDB
TimescaleDB ist eine Erweiterung von PostgreSQL, die die Arbeit mit Zeitreihendaten in einer herkömmlichen Datenbank optimiert., ).
Obwohl ClickHouse kein ernsthafter Konkurrent im Bereich der Zeitreihen ist, übertrifft es in den meisten Fällen bei der Verarbeitung analytischer Abfragen aufgrund seiner Spaltenstruktur und der vektorbasierten Ausführung die TimescaleDB erheblich. Die Leistung für den Empfang von Batch-Daten in ClickHouse ist zudem etwa dreimal schneller, und es benötigt 20-mal weniger Speicherplatz, was für die Verarbeitung großer Mengen historischer Daten von entscheidender Bedeutung ist:.
Im Gegensatz zu ClickHouse besteht die einzige Möglichkeit, in TimescaleDB etwas Speicherplatz zu sparen, in der Verwendung von ZFS oder ähnlichen Dateisystemen.
Die bevorstehenden Updates von ClickHouse werden wahrscheinlich Delta-Kompression einführen, die es noch besser für die Verarbeitung und Speicherung von Zeitreihendaten geeignet macht. TimescaleDB kann die bessere Wahl im Vergleich zu "reinen" ClickHouse in den folgenden Fällen sein:
- kleine Installationen mit sehr wenig RAM (<3 GB);
- eine große Anzahl kleiner INSERTs, die Sie nicht in große Blöcke puffern möchten;
- bessere Konsistenz, Einheitlichkeit und ACID-Anforderungen;
- Unterstützung für PostGIS;
- Integration mit bestehenden PostgreSQL-Tabellen, da Timescale DB essentially 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 hohen Latenzen. ClickHouse löst dieses Problem, indem es Terabytes an Daten verarbeitet und die Ergebnisse nahezu sofort liefert. Daher ist ClickHouse viel effektiver für schnelles, interaktives Analytics, was für Datenverarbeiter von Interesse sein sollte.
Wettbewerb mit Pinot und Druid
Die nächsten Konkurrenten von ClickHouse sind spaltenbasierte, linear skalierbare Open-Source-Produkte wie Pinot und Druid. Ein hervorragender Vergleich dieser Systeme wurde in dem Artikel veröffentlicht vom 1. Februar 2018.
Dieser Artikel bedarf einer Aktualisierung – 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 Datenbanken, aber die Komplexität der notwendigen Infrastruktur für den Betrieb von Druid und Pinot gefällt mir überhaupt nicht – es ist eine ganze Menge "beweglicher Teile", umgeben von Java auf allen Seiten.
Druid und Pinot sind Projekte im Apache-Inkubator, deren Entwicklung detailliert auf den GitHub-Seiten ihrer Projekte von Apache dargestellt wird. Pinot trat im Oktober 2018 in den Inkubator ein, während Druid acht Monate zuvor, im Februar, gegründet wurde.
Der Mangel an Informationen darüber, wie AFS funktioniert, wirft einige vielleicht unkluge Fragen auf. Mich interessiert, ob die Autoren von Pinot bemerkt haben, dass die Apache Foundation Druid freundlicher gegenübersteht, und ob dieses Verhältnis zu einem Konkurrenten Neidgefühle hervorgerufen hat. Wird sich die Entwicklung von Druid verlangsamen und die von Pinot beschleunigen, falls die Sponsoren, die ersteren unterstützen, plötzlich an letzterem interessiert sind?
Nachteile von ClickHouse
Unerfahrenheit: Es ist offensichtlich, dass dies immer noch eine aufregende Technologie ist, aber in anderen spaltenbasierten Datenbanken lässt sich in jedem Fall nichts Vergleichbares beobachten.
Kleine Inserts funktionieren bei hoher Geschwindigkeit schlecht: Inserts sollten in größere Stücke unterteilt werden, da die Leistung kleiner Inserts proportional zur Anzahl der Spalten in jeder Zeile abnimmt. So werden die Daten in ClickHouse auf der Festplatte gespeichert – jede Spalte entspricht einer Datei oder mehr, weshalb für das Einfügen einer Zeile mit 100 Spalten mindestens 100 Dateien geöffnet und beschrieben werden müssen. Deshalb benötigt man für das Puffern von Inserts einen Mittler (es sei denn, der Client selbst sorgt für das Puffern) – gewöhnlich ist das Kafka oder ein anderes Warteschlangenverwaltungssystem. Man kann auch die Buffer-Tabellen-Engine verwenden, um später große Datenmengen in MergeTree-Tabellen zu kopieren.
Tabellenverbindungen sind durch den Arbeitsspeicher des Servers begrenzt, aber sie sind zumindest vorhanden! Zum Beispiel haben Druid und Pinot überhaupt keine solchen Verbindungen, da es schwierig ist, diese in verteilten Systemen zu implementieren, die das Verschieben großer Datenmengen zwischen Knoten nicht unterstützen.
Fazit
In den kommenden Jahren planen wir, ClickHouse umfassend bei Qwintry zu integrieren, da dieses DBMS eine hervorragende Balance zwischen Leistung, geringen Overheads, Skalierbarkeit und Einfachheit bietet. Ich bin mir ziemlich sicher, dass es sich schnell verbreiten wird, sobald die ClickHouse-Community mehr Anwendungsmöglichkeiten für kleine und mittlere Installationen entwickelt.
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 Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
