Umstieg auf ClickHouse: 3 Jahre später

Vor drei Jahren sprachen Viktor Tarnawski und Alexej Milovidov von Yandex auf der Bühne HighLoad++ und berichteten, wie gut ClickHouse ist und dass es nicht langsam ist. Auf der benachbarten Bühne war Alexander Saitsev c mit einem Vortrag über den Umstieg auf ClickHouse eine andere analytische DBMS und kam zu dem Schluss, dass ClickHouse, natürlich gut, aber nicht sehr benutzerfreundlich. Als 2016 die Firma LifeStreet, in der Alexander damals arbeitete, ein Multi-Petabyte-Analysesystem auf ClickHouseumstellte, war das eine spannende „Straße aus Ziegeln“, voller unbekannter Gefahren - ClickHouse das erinnerte an ein Minenfeld.

Drei Jahre später ClickHouse ist es viel besser geworden - in dieser Zeit hat Alexander das Unternehmen Altinity gegründet, das nicht nur beim Umstieg auf ClickHouse Zehnten Projekten hilft, sondern das Produkt selbst zusammen mit Kollegen von Yandex weiterentwickelt. Derzeit ClickHouse ist es immer noch kein unbeschwerter Gang, aber auch kein Minenfeld mehr.

Alexander beschäftigt sich seit 2003 mit verteilten Systemen, entwickelte große Projekte auf MySQL, Oracle und Vertica.Auf dem vergangenen HighLoad++ 2019 erzählte Alexander, einer der Pioniere der Nutzung ClickHouse, was diese DBMS heute darstellt. Wir erfahren von den Hauptmerkmalen ClickHouse: worin es sich von anderen Systemen unterscheidet und in welchen Fällen es effektiver ist, es zu nutzen. An Beispielen betrachten wir frische und bewährte Praktiken zum Aufbau von Systemen auf ClickHouse.

Rückblick: was vor 3 Jahren war

Vor drei Jahren haben wir ein Unternehmen LifeStreet auf ClickHouse von einer anderen analytischen Datenbank umgestellt, und die Migration der Analyse des Werbenetzwerks sah so aus:

• Juni 2016. In OpenSource erscheinte ClickHouse startete unser Projekt;
• August. Proof Of Concept: ein großes Werbenetzwerk, Infrastruktur und 200-300 Terabyte an Daten;
• Oktober. Die ersten Produktionsdaten;
• Dezember. Vollständige Produktlast - 10-50 Milliarden Ereignisse pro Tag.
• Juni 2017. Erfolgreicher Umstieg der Nutzer auf ClickHouse, 2,5 Petabyte an Daten auf einem Cluster aus 60 Servern.

Im Prozess der Migration wuchs das Verständnis, dass ClickHouse es ein gutes System ist, mit dem man gerne arbeitet, aber es ist ein internes Projekt der Firma Yandex. Daher gibt es Nuancen: Yandex wird zunächst mit eigenen internen Kunden beschäftigt sein und erst danach mit der Community und den Bedürfnissen externer Benutzer, und ClickHouse kam damals in vielen funktionalen Bereichen nicht an Enterprise-Level heran. Daher gründeten wir im März 2017 das Unternehmen Altinity, um dies zu tun. ClickHouse noch schneller und komfortabler nicht nur für Yandex, sondern auch für andere Nutzer. Und jetzt sind wir:

• Wir schulen und helfen, Lösungen auf ClickHouse so aufzubauen, dass die Auftraggeber keine Fehler machen und die Lösung letztlich funktioniert;
• Wir bieten 24/7 Support ClickHouse-Installationen;
• Wir entwickeln eigene ökosystematische Projekte;
• Wir committen aktiv in den ClickHouse, indem wir auf Anfragen von Nutzern reagieren, die bestimmte Funktionen sehen möchten.

Und natürlich helfen wir beim Umzug auf ClickHouse c MySQL, Vertica., Oracle, Greenplum, Redshift und andere Systeme. Wir haben an den unterschiedlichsten Umzügen teilgenommen, und alle waren erfolgreich.

Warum überhaupt auf ClickHouse

Es bremst nicht! Das ist der Hauptgrund. ClickHouse — eine sehr schnelle Datenbank für verschiedene Szenarien:

Zufällige Zitate von Menschen, die lange mit ClickHouse.

Skalierbarkeit. Mit einer anderen DB kann man eine anständige Leistung auf einer Maschine erreichen, aber ClickHouse man kann nicht nur vertikal, sondern auch horizontal skalieren, indem man einfach Server hinzufügt. Alles funktioniert nicht so reibungslos, wie man es sich wünscht, aber es funktioniert. Man kann das System mit dem Wachstum des Unternehmens erweitern. Es ist wichtig, dass wir nicht auf eine Lösung festgelegt sind und stets Potenzial zur Weiterentwicklung besteht.

Portabilität. Es gibt keine Bindung an etwas Bestimmtes. Zum Beispiel ist der Umzug von Amazon Redshift schwierig. Aber ClickHouse man kann es auf seinem Laptop installieren, auf einem Server bereitstellen oder in die Cloud deployen, ohne Kubernetes — es gibt keine Einschränkungen bei der Nutzung der Infrastruktur. Das ist praktisch für alle, und es ist ein großer Vorteil, den viele andere ähnliche Datenbanken nicht bieten können.

Flexibilität. ClickHouse stoppt nicht bei einer Sache, zum Beispiel bei Yandex.Metrica, sondern entwickelt sich weiter und wird in immer mehr verschiedenen Projekten und Branchen eingesetzt. Man kann es erweitern, indem man neue Möglichkeiten für neue Aufgaben hinzufügt. Zum Beispiel gilt es als mieten, Logs in einer DB zu speichern — deshalb wurden dafür Elasticsearcherfunden. Aber dank der Flexibilität ClickHousekann man auch Logs darin speichern, und oft ist das sogar besser als in Elasticsearch — bei ClickHouse ist dafür 10 Mal weniger Hardware erforderlich.

Kostenlos Open Source. Man muss für nichts bezahlen. Man muss sich nicht darum kümmern, die Erlaubnis zu bekommen, das System auf seinem Laptop oder Server zu installieren. Es gibt keine versteckten Gebühren. Dabei kann keine andere Open Source Datenbanktechnologie in Bezug auf Geschwindigkeit mit ClickHouse. MySQL, MariaDB, Greenplum — sie sind alle wesentlich langsamer.

Gemeinschaft, Antrieb und Spaß. Wir ClickHouse eine großartige Gemeinschaft: Meetups, Chats und Alexey Milovidov, der uns alle mit seiner Energie und seinem Optimismus auflädt.

Umzug zu ClickHouse

Um auf ClickHouse etwas anderes zu migrieren, benötigt man nur drei Dinge:

• Die Einschränkungen verstehen ClickHouse und wofür es nicht geeignet ist.
• Die Vorteile nutzen der Technologie und ihre stärksten Seiten.
• Experimentieren. Auch wenn man versteht, wie es funktioniert ClickHouse, ist es nicht immer möglich vorherzusagen, wann es schneller, wann langsamer, wann besser und wann schlechter ist. Also probiert es aus.

Das Problem des Umzugs

Es gibt nur ein "Aber": Wenn man auf ClickHouse von etwas anderem umsteigt, läuft normalerweise etwas schief. Wir sind an bestimmte Praktiken und Dinge gewöhnt, die in unserer bevorzugten Datenbank funktionieren. Zum Beispiel denkt jeder, der mit SQL-Datenbanken arbeitet, dass ein bestimmter Funktionssatz obligatorisch ist:

• Transaktionen;
• Constraints;
• Konsistenz;
• Indizes;
• UPDATE/DELETE;
• NULLs;
• Millisekunden;
• automatische Typumwandlungen;
• mehrfache Joins;
• willkürliche Partitionen;
• Clusterverwaltungstools.

Der Satz ist obligatorisch, aber vor drei Jahren gab es in ClickHouse keine dieser Funktionen! Jetzt ist von den nicht umgesetzten weniger als die Hälfte übrig: Transaktionen, Constraints, Konsistenz, Millisekunden und Typumwandlung.

Und das Wichtigste — in ClickHouse funktionieren einige Standards und Ansätze nicht oder nicht so, wie wir es gewohnt sind. Alles, was in ClickHouseentsteht, entspricht dem "ClickHouse way", d. h. die Funktionen unterscheiden sich von anderen Datenbanken. Zum Beispiel:

• Indizes wählen nicht aus, sondern überspringen.
• UPDATE/DELETE sind nicht synchron, sondern asynchron.
• Es gibt mehrere Joins, aber keinen Abfrageplaner. Wie werden sie also ausgeführt, ist für Menschen aus der Datenbankwelt überhaupt nicht klar.

ClickHouse-Szenarien

Im Jahr 1960 schrieb der amerikanische Mathematiker ungarischer Herkunft Wigner E. P. einen Artikel mit dem Titel "The unreasonable effectiveness of mathematics in the natural sciences" über die erstaunliche Wirksamkeit der Mathematik in den Naturwissenschaften. Mathematik ist eine abstrakte Wissenschaft, und die physikalischen Gesetze, die in mathematischer Form ausgedrückt sind, sind nicht trivial, und Wigner E. P. er hob hervor, dass das sehr seltsam ist.

Aus meiner Sicht ist ClickHouse so eine Seltsamkeit. Wenn man Wigner umformuliert, kann man sagen: Die erstaunliche Unbegreiflichkeit der Effizienz ClickHouse in den unterschiedlichsten analytischen Anwendungen!

Nehmen wir zum Beispiel Real-Time Data Warehouse, in das Daten nahezu kontinuierlich geladen werden. Wir möchten von ihm Anfragen mit einer Verzögerung von einer Sekunde erhalten. Bitte — verwenden wir ClickHouse, weil er für dieses Szenario entwickelt wurde. ClickHouse genau so wird er nicht nur im Web, sondern auch in Marketing- und Finanzanalysen verwendet, AdTech, sowie in der Betrugserkennung. Im Echtzeit-Datenlager wird ein komplexes strukturiertes Schema vom Typ "Stern" oder "Schneeflocke" verwendet, viele Tabellen mit JOIN (manchmal mehrere), und die Daten werden normalerweise in bestimmten Systemen gespeichert und verändert.

Nehmen wir ein anderes Szenario — Zeitserie: Überwachung von Geräten, Netzwerken, Nutzungstatistiken, Internet der Dinge. Hier stoßen wir auf zeitlich geordnete, ziemlich einfache Ereignisse. ClickHouse wurde dafür ursprünglich nicht entwickelt, hat sich aber gut bewährt, daher verwenden große Unternehmen ClickHouse als Speicher für Überwachungsinformationen. Um zu überprüfen, ob ClickHouse für Zeitserien geeignet ist, haben wir einen Benchmark basierend auf dem Ansatz und den Ergebnissen durchgeführt. InfluxDB und TimescaleDB — spezialisierte Zeitserien Datenbanken. Es stellte sich heraus, dass ClickHouse, selbst ohne Optimierung für solche Aufgaben, auf fremdem Terrain Vorteile hat:

Im Zeitserien wird normalerweise eine schmale Tabelle verwendet — einige kleine Spalten. Von der Überwachung können sehr viele Daten kommen — Millionen von Datensätzen pro Sekunde — und sie werden normalerweise in kleinen Portionen übermittelt (Echtzeit Streaming). Daher wird ein anderes Einfügeszenario benötigt, und die Anfragen haben ihre eigene spezifische Natur.

Protokollmanagement. Das Sammeln von Protokollen in einer DB ist normalerweise schlecht, aber in ClickHouse kann dies mit einigen Kommentaren gemacht werden, wie oben beschrieben. Viele Unternehmen nutzen ClickHouse genau dafür. In diesem Fall wird eine flache breite Tabelle verwendet, in der wir die Protokolle vollständig speichern (zum Beispiel in Form von JSON), oder wir schneiden sie in Teile. Die Daten werden normalerweise in großen Batches (Dateien) geladen, und wir suchen nach einem bestimmten Feld.

Für jede dieser Funktionen werden normalerweise spezialisierte DBs verwendet. ClickHouse eine kann all dies so gut machen, dass sie in der Leistung übertrifft. Lassen Sie uns nun im Detail betrachten Zeitserien ein Szenario und wie man es richtig "zubereitet" ClickHouse für dieses Szenario.

Zeitserie

Derzeit ist dies das Hauptszenario, für das ClickHouse als Standardlösung gilt. Zeitserie — dies ist eine Reihe von zeitlich geordneten Ereignissen, die Veränderungen eines Prozesses über die Zeit darstellen. Zum Beispiel könnte dies die Herzfrequenz über einen Tag oder die Anzahl der Prozesse im System sein. Alles, was zeitliche Ticks mit bestimmten Messungen bereitstellt, ist Zeitserien:

Die meisten dieser Art von Ereignissen kommen aus der Überwachung. Dies kann nicht nur die Überwachung des Webs, sondern auch realer Geräte umfassen: Autos, industrielle Systeme, IoT, Produktionen oder autonomer Taxis, die bereits jetzt von Yandex in den Kofferraum legen ClickHouse-Server.

Beispielsweise gibt es Unternehmen, die Daten von Schiffen sammeln. Alle paar Sekunden senden Sensoren eines Containerschiffes Hunderte verschiedener Messungen. Ingenieure analysieren diese, erstellen Modelle und versuchen zu verstehen, wie effektiv das Schiff genutzt wird, denn das Containerschiff darf keine Sekunde stillstehen. Jede Stillstandzeit ist ein Verlust von Geld, daher ist es wichtig, die Route so zu planen, dass die Stopps minimal sind.

Derzeit gibt es ein Wachstum spezieller Datenbanken, die messen Zeitserien. Auf der Website DB-Engines werden verschiedene Datenbanken auf irgendeine Weise gerankt, und sie können nach Typen angesehen werden:

Der am schnellsten wachsende Typ ist Zeitreihen. Auch Graphdatenbanken wachsen, aber Zeitreihen wachsen in den letzten Jahren schneller. Typische Vertreter dieser Datenbankfamilie sind InfluxDB, Prometheus, KDB, TimescaleDB (aufgebaut auf PostgreSQL), Lösungen von Amazon. ClickHouse kann hier ebenfalls verwendet werden, und es wird verwendet. Ich gebe einige öffentliche Beispiele.

Einer der Pioniere ist die Firma CloudFlare (CDN-Provider). Sie überwachen ihre CDN über ClickHouse (DNS-Anfragen, HTTP-Anfragen) mit einer riesigen Last — 6 Millionen Ereignisse pro Sekunde. Alles läuft über Kafka, wird an ClickHouse, das die Möglichkeit bietet, in Echtzeit Dashboards für Ereignisse im System zu sehen.

Comcast — einer der Branchenführer in der Telekommunikation in den USA: Internet, digitales Fernsehen, Telefonie. Sie haben ein ähnliches Managementsystem erstellt CDN im Rahmen der Open Source des Projekts Apache Traffic Control zum Arbeiten mit ihren riesigen Datenmengen. ClickHouse wird als Backend für Analysen verwendet.

Percona haben ClickHouse in ihr PMM, um die Überwachung verschiedener MySQL.

Spezifische Anforderungen

Bei Zeitreihen-Datenbanken gibt es spezifische Anforderungen.

• Schnelles Einfügen von vielen Agenten. Wir müssen sehr schnell Daten von vielen Strömen einfügen. ClickHouse macht das gut, weil es keine blockierenden Einfügungen hat. Jede Einfügung — dies ist eine neue Datei auf der Festplatte, und kleine Einfügungen können auf die eine oder andere Weise gepuffert werden. In ClickHouse es ist besser, Daten in großen Paketen einzufügen, anstatt zeilenweise.
• Flexible Struktur. In Zeitserien wir wissen normalerweise nicht, wie die Datenstruktur genau aussieht. Man kann ein Überwachungssystem für eine bestimmte Anwendung aufbauen, aber dann ist es schwer, es für eine andere Anwendung zu verwenden. Dafür ist eine flexiblere Struktur erforderlich. ClickHouse, was dies ermöglicht, auch wenn es sich um eine streng typisierte Datenbank handelt.
• Effiziente Speicherung und das „Vergessen“ von Daten. Normalerweise in Zeitserien gigantischen Datenmengen, sodass sie so effizient wie möglich gespeichert werden müssen. Zum Beispiel ist eine InfluxDB gute Kompression – das ist sein Hauptmerkmal. Aber neben der Speicherung muss man auch in der Lage sein, alte Daten zu „vergessen“ und eine Art von Downsampling – automatisierte Aggregatzählung.
• Schnelle Abfragen aggregierter Daten. Manchmal ist es interessant, die letzten 5 Minuten mit einer Genauigkeit von Millisekunden zu betrachten, aber bei monatlichen Daten kann es sein, dass eine Minuten- oder Sekundenauflösung nicht erforderlich ist – allgemeine Statistiken sind ausreichend. Eine solche Unterstützung ist unerlässlich, da sonst eine Abfrage über 3 Monate sehr lange dauern kann, selbst in ClickHouse.
• Abfragen wie „letzter Punkt, zum». Das sind typische für Zeitserien Abfragen: Wir betrachten die letzte Messung oder den Zustand des Systems zu einem bestimmten Zeitpunkt t. Für Datenbanken sind dies nicht sehr angenehme Abfragen, aber sie müssen ebenfalls ausgeführt werden können.
• „Verklebung“ von Zeitreihen. Zeitserie – dies ist eine Zeitreihe. Wenn es zwei Zeitreihen gibt, müssen sie häufig kombiniert und korreliert werden. Das ist nicht in allen Datenbanken bequem, insbesondere bei unregelmäßigen Zeitreihen: hier – andere Zeitstempel, dort – andere. Man kann Mittelwerte berechnen, aber plötzlich gibt es trotzdem eine Lücke, weshalb es unklar ist.

Schauen wir uns an, wie diese Anforderungen in ClickHouse.

Diagramm

Im ClickHouse ein Schema erstellt werden kann, Zeitserien kann auf verschiedene Arten durchgeführt werden, je nach dem Grad der Regelmäßigkeit der Daten. Man kann ein System für regelmäßige Daten aufbauen, wenn wir alle Metriken im Voraus kennen. Zum Beispiel hat CloudFlare mit der Überwachung CDN – ist ein gut optimiertes System. Man kann ein allgemeineres System aufbauen, das die gesamte Infrastruktur und verschiedene Dienste überwacht. Bei unregelmäßigen Daten wissen wir nicht im Voraus, was wir überwachen – und das ist wahrscheinlich der allgemeinste Fall.

Regelmäßige Daten. Spalten. Das Schema ist einfach – Spalten mit den benötigten Typen:

ERSTELLE TABELLE cpu (
  created_date Datum STANDARD heute(),  
  created_at DatumZeit STANDARD jetzt(),  
  time Zeichenfolge,  
  tags_id UInt32,  
  /* Verbindung zu dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Dies ist eine normale Tabelle, die eine Aktivität zur Systemlast überwacht (Benutzer, System, idle, nice). Einfach und praktisch, aber nicht flexibel. Wenn wir ein flexibleres Schema möchten, können wir Arrays verwenden.

Unregelmäßige Daten. Arrays:

ERSTELLE TABELLE cpu_alc (
  created_date Datum,  
  created_at DatumZeit,  
  time Zeichenfolge,  
  tags_id UInt32,  
  metrics Verschachtelt(
    name NiedrigKardinalität(Zeichenfolge),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Struktur Verschachtelt — das sind zwei Arrays: metrics.name und metrics.value. Hier können beliebige Überwachungsdaten wie ein Array von Namen und ein Array von Werten bei jedem Ereignis gespeichert werden. Zur weiteren Optimierung kann man anstelle einer solchen Struktur mehrere erstellen. Zum Beispiel eine für float-Wert, eine andere für int-Wert, weil int man effizienter speichern möchte.

Aber mit dieser Struktur umzugehen, ist komplizierter. Man muss eine spezielle Konstruktion verwenden, um zuerst die Werte des Index und dann des Arrays zu extrahieren:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Aber das funktioniert trotzdem ziemlich schnell. Eine andere Methode zur Speicherung unregelmäßiger Daten ist zeilenbasiert.

Unregelmäßige Daten. Zeilen. In dieser traditionellen Methode ohne Arrays werden sofort Namen und Werte gespeichert. Wenn von einem Gerät sofort 5.000 Messungen kommen, werden 5.000 Zeilen in der DB generiert:

ERSTELLE TABELLE cpu_rlc (
  created_date Datum,  
  created_at DatumZeit,  
  time Zeichenfolge,  
  tags_id UInt32,  
  metric_name NiedrigKardinalität(Zeichenfolge),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

ClickHouse wofür es spezielle Erweiterungen gibt ClickHouse SQL. Zum Beispiel, maxIf — eine spezielle Funktion, die das Maximum der Metrik bei Erfüllung einer bestimmten Bedingung berechnet. Man kann in einer Anfrage mehrere solcher Ausdrücke schreiben und sofort Werte für mehrere Metriken berechnen.

Vergleichen wir drei Ansätze:

Details

Hier habe ich die „Datengröße auf der Festplatte“ für einen bestimmten Testdatensatz hinzugefügt. In Bezug auf die Spalten haben wir die kleinste Datengröße: maximale Kompression, maximale Abfragegeschwindigkeit, aber wir zahlen den Preis, dass wir alles auf einmal festhalten müssen.

Im Fall von Arrays ist es etwas schlechter. Die Daten lassen sich dennoch gut komprimieren, und es ist möglich, ein unregelmäßiges Schema zu speichern. Aber ClickHouse — in einer spaltenbasierten Datenbank, und wenn wir anfangen, alles in einem Array zu speichern, verwandelt sich das in eine zeilenbasierte, und wir zahlen für Flexibilität mit Effizienz. Für jede Operation muss das gesamte Array in den Speicher geladen werden, danach müssen wir das erforderliche Element darin finden – und wenn das Array wächst, verschlechtert sich die Geschwindigkeit.

In einem der Unternehmen, das einen solchen Ansatz verwendet (zum Beispiel, Uber), werden die Arrays in Stücke von 128 Elementen aufgeteilt. Daten von mehreren Tausend Metriken in einem Volumen von 200 TB Daten/Tag werden nicht in einem einzigen Array gespeichert, sondern in 10 oder 30 Arrays mit spezieller Logik zur Speicherung.

Der einfachste Ansatz ist der mit Strings. Aber die Daten lassen sich schlecht komprimieren, die Tabellengröße ist groß, und wenn Abfragen über mehrere Metriken laufen, arbeitet ClickHouse suboptimal.

Hybrides Schema

Angenommen, wir haben uns für ein Schema mit einem Array entschieden. Aber wenn wir wissen, dass die meisten unserer Dashboards nur die Metriken user und system anzeigen, können wir zusätzlich aus dem Array auf Tabellenebene diese Metriken in Spalten materialisieren:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Beim Einfügen ClickHouse wird es automatisch gezählt. So kann man Angenehmes mit Nützlichem verbinden: das Schema ist flexibel und allgemein, aber die am häufigsten verwendeten Spalten haben wir herausgezogen. Ich möchte erwähnen, dass dies nicht erforderlich war, um das Einfügen und ETL, das weiterhin Arrays in die Tabelle einfügt. Wir haben einfach gemacht ALTER TABLE, ein paar Spalten hinzugefügt und so entstand ein hybrides und schnelleres Schema, das sofort genutzt werden kann.

Codecs und Kompression

Für Zeitserien ist wichtig, wie gut Sie die Daten verpacken, denn das Informationsarray kann sehr groß sein. In ClickHouse Es gibt eine Reihe von Mitteln zur Erzielung eines Kompressionseffekts von 1:10, 1:20 und manchmal sogar mehr. Das bedeutet, dass unkomprimierte Daten mit einem Volumen von 1 TB auf der Festplatte nur 50-100 GB einnehmen. Eine kleinere Größe ist vorteilhaft, da die Daten schneller gelesen und verarbeitet werden können.

Um ein hohes Maß an Kompression zu erreichen, ClickHouse unterstützt die folgenden Codecs:

Beispiel Tabelle:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Hier definieren wir den Codec DoubleDelta in einem Fall, im anderen — Gorilla, und fügen unbedingt noch hinzu LZ4 Kompression. Infolgedessen verringert sich die Datengröße auf der Festplatte erheblich:

Hier wird angezeigt, wie viel Platz die gleichen Daten einnehmen, wobei verschiedene Codecs und Kompressionen verwendet werden:

• in einer GZIP-komprimierten Datei auf der Festplatte;
• in ClickHouse ohne Codecs, aber mit ZSTD-Kompression;
• in ClickHouse mit Codecs und den Kompressionen LZ4 und ZSTD.

Es ist zu erkennen, dass Tabellen mit Codecs erheblich weniger Platz beanspruchen.

Größe spielt eine Rolle

Nicht weniger wichtig ist die Wahl des richtigen Datentyps:

In allen oben genannten Beispielen habe ich Float64. Aber wenn wir Float32, wählen würden, wäre das sogar noch besser. Das wurde eindrucksvoll von den Kollegen von Percona in dem oben verlinkten Artikel gezeigt. Es ist wichtig, den möglichst kompakten Typ zu verwenden, der für die Aufgabe geeignet ist: nicht so sehr für die Größe auf der Festplatte, sondern für die Geschwindigkeit der Abfragen. ClickHouse darauf reagiert sehr empfindlich.

Wenn Sie verwenden können int32 anstatt int64, erwarten Sie fast eine Verdopplung der Leistung. Die Daten benötigen weniger Speicherplatz, und die gesamte "Arithmetik" funktioniert deutlich schneller. ClickHouse innerhalb ist es ein sehr streng typisiertes System, das alle Möglichkeiten optimal nutzt, die moderne Systeme bieten.

Aggregation und Materialisierte Ansichten

Aggregation und materialisierte Ansichten ermöglichen es, Aggregationen für verschiedene Anwendungsfälle zu erstellen:

Zum Beispiel können Sie nicht aggregierte Rohdaten haben, und Sie können verschiedene materialisierte Ansichten mit automatischer Aggregation über eine spezielle Engine darauf anwenden. SummingMergeTree (SMT). SMT ist eine spezielle aggregierende Datenstruktur, die Aggregationen automatisch berechnet. Rohdaten werden in die Datenbank eingefügt, sie werden automatisch aggregiert, und Dashboards können sofort darauf verwendet werden.

TTL – „vergessen“ wir alte Daten

Wie „vergessen“ wir Daten, die nicht mehr benötigt werden? ClickHouse kann das. Bei der Erstellung von Tabellen können Sie angeben, TTL zum Beispiel, dass wir Minutendaten einen Tag lang speichern, Tagesdaten 30 Tage lang, und wöchentliche oder monatliche Daten niemals berühren:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multi-Tier – wir trennen Daten auf Festplatten

Indem wir diese Idee weiterverfolgen, können Daten an ClickHouse verschiedenen Orten gespeichert werden. Angenommen, wir möchten heiße Daten der letzten Woche auf einer sehr schnellen lokalen SSD, während wir historischere Daten an einem anderen Ort ablegen. In ClickHouse ist das jetzt möglich:

Sie können eine Speicherrichtlinie (storage policy) so konfigurieren, dass ClickHouse Daten automatisch nach Erreichung bestimmter Bedingungen in einem anderen Speicherort verschoben werden.

Aber das ist noch nicht alles. Auf der Ebene einer bestimmten Tabelle können Sie Regeln definieren, wann genau die Daten zeitlich in die kalte Speicherung übergehen. Zum Beispiel liegen die Daten 7 Tage lang auf einer sehr schnellen Festplatte, und alles, was älter ist, wird auf eine langsame übertragen. Das ist vorteilhaft, da es ermöglicht, das System mit maximaler Leistung zu betreiben und gleichzeitig die Kosten zu kontrollieren, ohne Mittel für kalte Daten auszugeben:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Einzigartige Möglichkeiten ClickHouse

Fast alles in ClickHouse hat solche „Besonderheiten“, aber sie werden durch das Exklusive — das, was in anderen DBs nicht vorhanden ist — neutralisiert. Zum Beispiel sind hier einige der einzigartigen Funktionen ClickHouse:

• Arrays. In ClickHouse eine sehr gute Unterstützung für Arrays sowie die Möglichkeit, komplexe Berechnungen darauf durchzuführen.
• Aggregierende Datenstrukturen. Das ist eines der „Killer-Features“ ClickHouse. Obwohl die Leute von Yandex sagen, dass wir keine Daten aggregieren wollen, aggregiert jeder in ClickHouse, weil es schnell und bequem ist.
• Materialisierte Ansichten. Zusammen mit aggregierten Datenstrukturen ermöglichen materialisierte Ansichten eine bequeme Echtzeit Aggregation.
• ClickHouse SQL. Diese Erweiterung der Sprache SQL verfügt über einige zusätzliche und exklusive Funktionen, die es nur in ClickHousegibt. Früher war es einerseits eine Erweiterung, andererseits ein Nachteil. Jetzt haben wir fast alle Nachteile im Vergleich zu SQL 92 eliminiert, es ist jetzt nur noch eine Erweiterung.
• Lambda-Ausdrücke. Gibt es die noch in einer anderen Datenbank?
• ML-Unterstützung.Das gibt es in verschiedenen DBs, einige sind besser, einige schlechter.
• Open Source. Wir können gemeinsam erweitern. ClickHouse Derzeit gibt es ClickHouse ungefähr 500 Mitwirkende, und diese Zahl wächst ständig.

Komplexe Abfragen

Im ClickHouse es gibt viele verschiedene Wege, dasselbe zu tun. Zum Beispiel kann man die letzte Zeile aus einer Tabelle auf drei verschiedene Arten zurückgeben für CPU (es gibt sogar noch eine vierte, aber die ist noch exotischer).

Die erste zeigt, wie man in ClickHouse Abfragen bequem überprüft, dass ein Tuple in einer Unterabfrage enthalten ist. Das war etwas, das mir persönlich in anderen DBs sehr gefehlt hat. Wenn ich etwas mit einer Unterabfrage vergleichen möchte, kann ich in anderen DBs nur Skalare vergleichen, und für mehrere Spalten muss man schreiben JOIN. In ClickHouse man kann Tuple verwenden:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Die zweite Methode macht dasselbe, verwendet jedoch die aggregierte Funktion argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

Im ClickHouse es gibt mehrere Dutzend aggregierter Funktionen, und wenn man Kombinatoren verwendet, ergibt das nach den Kombinatorikgesetzen etwa tausend. ArgMax ist eine der Funktionen, die den maximalen Wert berechnet: die Abfrage gibt den Wert zurück usage_user, bei dem der maximale Wert erreicht wird. created_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF JOIN – das „Zusammenfügen“ von Reihen mit unterschiedlichem Zeitstempel. Das ist eine einzigartige Funktion für Datenbanken, die es nur in kdb+gibt. Wenn es zwei Zeitreihen mit unterschiedlichen Zeitpunkten gibt, ASOF JOIN erlaubt es, sie zu verschieben und in einer Abfrage zusammenzuführen. Für jeden Wert in einer Zeitreihe wird der nächstgelegene Wert in der anderen gefunden, und sie werden in einer Zeile zurückgegeben:

Analytische Funktionen

Im Standard SQL-2003 kann man es so schreiben:

WÄHLEN Sie Herkunft,
       Zeitstempel,
       Zeitstempel -LAG(Satz, 1) OVER (PARTITION BY Herkunft ORDER BY Zeitstempel) ALS Dauer,
       Zeitstempel -MIN(Zeitstempel) OVER (PARTITION BY Herkunft ORDER BY Zeitstempel) ALS Startseq_Dauer,
       ROW_NUMBER() OVER (PARTITION BY Herkunft ORDER BY Zeitstempel) ALS Folge,
       COUNT() OVER (PARTITION BY Herkunft ORDER BY Zeitstempel) ALS nb
  VON mytable
SORTIEREN NACH Herkunft, Zeitstempel;

Im ClickHouse So geht das nicht – er unterstützt den Standard nicht. SQL-2003 Und wird wahrscheinlich niemals damit beginnen. Stattdessen wird in ClickHouse folgendermaßen geschrieben:

Ich habe versprochen, Lambdas – hier sind sie!

Dies ist das Äquivalent einer analytischen Abfrage im Standard SQL-2003: er berechnet die Differenz zwischen zwei Zeitstempel, Dauer, die laufende Nummer – alles, was wir normalerweise für analytische Funktionen betrachten. In ClickHouse betrachten wir sie durch Arrays: Zuerst fassen wir die Daten in einem Array zusammen, danach machen wir im Array alles, was wir wollen, und dann entfalten wir sie wieder. Das ist nicht sehr bequem, erfordert mindestens eine Liebe zur funktionalen Programmierung, aber es ist sehr flexibel.

Spezialfunktionen

Außerdem gibt es in ClickHouse viele spezialisierte Funktionen. Zum Beispiel, wie kann man bestimmen, wie viele Sitzungen gleichzeitig ablaufen? Eine typische Aufgabe für das Monitoring – die maximale Belastung durch eine Abfrage zu bestimmen. In ClickHouse gibt es eine spezielle Funktion für diesen Zweck:

Im Allgemeinen gibt es für viele Zwecke in ClickHouse spezielle Funktionen:

• runningDifference, runningAccumulate, neighbor;
• sumMap(key, value);
• timeSeriesGroupSum(uid, Zeitstempel, Wert);
• timeSeriesGroupRateSum(uid, Zeitstempel, Wert);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

Das ist keine vollständige Liste von Funktionen, insgesamt gibt es 500-600. Hinweis: Alle Funktionen in ClickHouse sind in der Systemtabelle enthalten (nicht alle sind dokumentiert, aber alle sind interessant):

select * from system.functions ORDER BY name

ClickHouse bewahrt viele Informationen über sich selbst, einschließlich Log-Tabellen, query_log, Trace-Log, Protokoll der Operationen mit Datenblöcken (part_log), Protokoll der Metriken und ein Systemlog, das er normalerweise auf die Festplatte schreibt. Das Metrik-Log ist Zeitserien in ClickHouse in der Tat: ClickHouseDie DB kann im Grunde genommen als Zeitserien Datenbank agieren, wobei sie sich somit selbst ‘verbraucht’.

Das ist auch eine einzigartige Sache – da wir die Arbeit für Zeitserien, warum können wir nicht alles, was wir benötigen, in uns speichern? Wir brauchen kein Prometheus, wir speichern alles in uns. Wir haben Grafana und überwachen uns selbst. Wenn jedoch ClickHouse ausfällt, werden wir nicht sehen, – warum, – deshalb wird es normalerweise nicht so gemacht.

Ein großer Cluster oder viele kleine ClickHouse

Was ist besser – ein großer Cluster oder viele kleine ClickHouse? Der traditionelle Ansatz für DWH — das ist ein großer Cluster, in dem für jede Anwendung eigene Schemata выделяются. Wir sind zum Datenbankadministrator gekommen — geben Sie uns das Schema, und wir haben es erhalten:

Im ClickHouse man kann es anders machen. Man kann jeder Anwendung ihr eigenes ClickHouse:

Wir brauchen keinen großen, monströsen DWH und unkooperativen Administrator mehr. Wir können jeder Anwendung ihr eigenes ClickHouse, und der Entwickler kann es selbst machen, da ClickHouse es sehr einfach zu installieren ist und keine komplizierte Verwaltung erfordert:

Aber wenn wir viel haben ClickHouse, und es oft installiert werden muss, möchte man diesen Prozess automatisieren. Dazu kann man zum Beispiel Kubernetes und ClickHouse-Operator verwenden. In Kubernetes ClickHouse kann man „auf einen Klick“ installieren: Ich kann auf einen Knopf drücken, das Manifest starten, und die Datenbank ist bereit. Man kann sofort ein Schema erstellen, anfangen, Metriken hochzuladen, und nach 5 Minuten habe ich bereits ein Dashboard Grafana. So einfach ist das!

Was kommt dabei heraus?

Also, ClickHouse das ist:

• Schnell. Das ist allgemein bekannt.
• Einfach. Etwas umstritten, aber ich denke, dass es im Lernen schwer ist, im Kampf leicht. Wenn man versteht, wie ClickHouse es funktioniert, ist alles danach sehr einfach.
• Universell. Es eignet sich für verschiedene Szenarien: DWH, Zeitserien, Log-Speicherung. Aber das ist keine OLTP Datenbank, also versuchen Sie nicht, dort kurze Einfügungen und Lesevorgänge zu machen.
• Interessant. Wahrscheinlich hat derjenige, der mit ClickHousearbeitet, viele interessante Momente sowohl im positiven als auch im negativen Sinne erlebt. Zum Beispiel, ein neues Release ist erschienen, und alles hat aufgehört zu funktionieren. Oder wenn Sie zwei Tage lang an einer Aufgabe gearbeitet haben, aber nach einer Frage im Telegram-Chat wurde die Aufgabe in zwei Minuten gelöst. Oder wie beim Vortrag von Alexey Milovidov auf der Konferenz, als ein Screenshot von ClickHouse den Stream kaputtgemacht hat HighLoad++. Solche Dinge passieren ständig und machen unser Leben mit ClickHouse bunt und interessant!

Die Präsentation kann angesehen werden hier.

Das lang erwartete Treffen der Entwickler hochbelasteter Systeme findet am HighLoad++ am 9. und 10. November in Skolkovo statt. Endlich wird es eine Offline-Konferenz sein (auch wenn alle Sicherheitsmaßnahmen eingehalten werden), da die Energie von HighLoad++ nicht in eine Online-Veranstaltung gepackt werden kann.

Für die Konferenz finden wir und zeigen Ihnen Anwendungsfälle zu den maximalen Möglichkeiten der Technologien: HighLoad++ war, ist und wird der einzige Ort sein, an dem man an zwei Tagen erfahren kann, wie Facebook, Yandex, VKontakte, Google und Amazon aufgebaut sind.

Seit 2007 führen wir unsere Treffen ohne Unterbrechung durch, und in diesem Jahr finden wir uns zum 14. Mal zusammen. In dieser Zeit ist die Konferenz um das 10-fache gewachsen, im letzten Jahr versammelten sich beim wichtigsten Branchenevent 3339 Teilnehmer, 165 Referenten und Redner sowie gleichzeitig 16 Tracks.
Im letzten Jahr standen Ihnen 20 Busse, 5280 Liter Tee und Kaffee, 1650 Liter Fruchtsäfte und 10200 Flaschen Wasser zur Verfügung. Außerdem gab es 2640 Kilogramm Essen, 16000 Teller und 25000 Becher. Übrigens haben wir mit dem Geld, das wir durch recyceltes Papier eingenommen haben, 100 Setzlinge von Eichen gepflanzt 🙂

Tickets können gekauft werden hier, um Neuigkeiten zur Konferenz zu erhalten — hier, und um zu sprechen — in allen sozialen Netzwerken: Telegram, Facebook, Vkontakte und Twitter.

Quelle: habr.com