Verwendung von ClickHouse in VK oder Warum haben wir KittenHouse geschrieben?

    Anfang des Jahres haben wir beschlossen, zu lernen, wie man VK-Debug-Protokolle effizienter speichert und liest als zuvor. Debug-Protokolle sind beispielsweise Videokonvertierungsprotokolle (hauptsächlich die Ausgabe des Befehls ffmpeg und eine Liste von Schritten zum Vorverarbeiten von Dateien), die manchmal nur 2-3 Monate nach der Verarbeitung der Problemdatei benötigt werden.

    Zu dieser Zeit hatten wir zwei Möglichkeiten, Protokolle zu speichern und zu verarbeiten - unsere eigene Protokoll-Engine und das rsyslog, die wir parallel verwendet haben. Wir begannen, andere Optionen in Betracht zu ziehen und erkannten, dass ClickHouse von Yandex für uns durchaus geeignet ist - wir beschlossen, es zu implementieren.

    In diesem Artikel werde ich darüber sprechen, wie wir mit ClickHouse VKontakte angefangen haben, mit welchem ​​Rechen wir getreten sind und was KittenHouse und LightHouse sind. Beide Produkte sind am Ende des Artikels in Open-Source-Links verfügbar.

    Die Aufgabe, Protokolle zu sammeln


    Systemanforderungen:

    1. Speicherung von Hunderten von Terabytes an Protokollen.
    2. Lagerung über Monate oder (selten) über Jahre.
    3. Hohe Schreibgeschwindigkeit
    4. Hohe Lesegeschwindigkeit (seltenes Lesen).
    5. Index-Unterstützung
    6. Unterstützung für lange Leitungen (> 4 Kb).
    7. Einfache Bedienung
    8. Kompakte Lagerung.
    9. Möglichkeit zum Einfügen mit Zehntausenden von Servern (UDP ist ein Plus).

    Mögliche Lösungen


    Lassen Sie uns kurz die von uns in Betracht gezogenen Optionen und ihre Nachteile auflisten:

    Protokolliert die Engine


    Unser samopisny Microservice für Protokolle.
    - Kann nur die letzten N Zeilen angeben, die sich im RAM befinden.
    - Nicht sehr kompakter Speicher (keine transparente Komprimierung).

    Hadoop


    - Nicht alle Formate haben Indizes.
    - Die Lesegeschwindigkeit kann (je nach Format) höher sein.
    - Schwierigkeitseinstellung.
    - Es besteht keine Möglichkeit von zehntausenden Servern eingefügt zu werden (Kafka oder Analoge werden benötigt).

    Rsyslog + -Dateien


    - Keine Indizes.
    - Langsame Lesegeschwindigkeit (normales Grep / Zgrep).
    - Architektonisch werden die Leitungen nicht über 4 Kb unterstützt, noch weniger über UDP (1,5 Kb).
    ± Kompakte Lagerung durch Logrotate auf der Krone

    Wir haben rsyslog als Backup für die Langzeitspeicherung verwendet, aber die langen Leitungen wurden abgeschnitten, sodass es kaum als ideal bezeichnet werden kann.

    LSD + Dateien


    - Keine Indizes.
    - Langsame Lesegeschwindigkeit (normales Grep / Zgrep).
    - Nicht wirklich für das Einfügen von Zehntausenden von Servern konzipiert.
    ± Kompakte Speicherung wird durch Logoteilung auf Krone erzielt.
    Der Unterschied zu rsyslog besteht in unserem Fall darin, dass LSD lange Leitungen unterstützt. Beim Einfügen von Zehntausenden von Servern sind jedoch erhebliche Verbesserungen des internen Protokolls erforderlich, obwohl dies möglich ist.

    Elasticsearch


    - Probleme mit der Bedienung.
    - Instabile Aufnahme.
    - Kein UDP.
    - schlechte Kompression
    ELK-Stack ist bereits fast ein Industriestandard für die Speicherung von Protokollen. Unserer Erfahrung nach ist alles gut mit der Lesegeschwindigkeit, aber beim Schreiben von Indizes gibt es beispielsweise Probleme beim Schreiben.

    ElasticSearch ist in erster Linie für die Volltextsuche und für relativ häufige Leseanfragen gedacht. Wichtiger ist für uns eine stabile Aufzeichnung und die Fähigkeit, unsere Daten mehr oder weniger schnell und zufällig zu lesen. Der Index bei ElasticSearch wird für die Volltextsuche geschärft, und der Speicherplatz ist im Vergleich zum GZIP des ursprünglichen Inhalts recht groß.

    Clickhouse


    - Kein UDP.

    Im Großen und Ganzen war das einzige, was uns bei ClickHouse nicht passte, die mangelnde Kommunikation über UDP. In der Tat hatte nur rsyslog eine dieser Optionen, aber rsyslog unterstützte keine langen Leitungen.

    Entsprechend den übrigen Kriterien hat sich ClickHouse an uns gewandt, und wir haben uns dazu entschieden, es zu verwenden und Transportprobleme zu lösen.

    Warum brauchst du KittenHouse?


    Wie Sie wahrscheinlich wissen, arbeitet VKontakte mit PHP / KPHP, mit "Engines" (Microservices) für C / C ++ und etwas mit Go. PHP hat kein "Status" -Konzept zwischen Anforderungen, außer vielleicht Shared Memory und offene Verbindungen.

    Da es Zehntausende von Servern gibt, von denen wir Protokolle an ClickHouse senden möchten, wäre es teuer, Verbindungen von jedem PHP-Worker offen zu halten (jeder Server kann 100+ Worker haben). Wir brauchen also eine Art Proxy zwischen ClickHouse und PHP. Wir haben diesen Proxy KittenHouse genannt.

    KittenHouse, v1


    Zunächst haben wir uns entschlossen, ein möglichst einfaches Schema auszuprobieren, um zu verstehen, ob unser Ansatz funktioniert oder nicht. Wenn Ihnen Kafka bei der Lösung dieses Problems in den Sinn kommt, dann sind Sie nicht alleine. Wir wollten jedoch keine zusätzlichen Zwischenserver verwenden. In diesem Fall war es einfach, sich gegen die Leistung dieser Server und nicht gegen ClickHouse selbst zu wehren. Darüber hinaus haben wir Protokolle gesammelt und eine vorhersehbare und geringe Verzögerung beim Einfügen von Daten benötigt. Das Schema



    sieht wie folgt aus: Auf jedem Server wird unser lokaler Proxy (kittenhouse) eingerichtet, und jede Instanz hält strikt eine HTTP-Verbindung mit dem gewünschten ClickHouse-Server. Das Einfügen erfolgt in Puffertabellen, da das Einfügen in MergeTree oft nicht empfohlen wird.

    Eigenschaften KittenHouse, v1


    Die erste Version von KittenHouse war ziemlich geschult, aber für Tests war das genug:

    • Kommunikation über unser RPC (TL Scheme).
    • Pflegen Sie 1 TCP / IP-Verbindung pro Server.
    • Standardmäßig Pufferung im Speicher mit einer begrenzten Puffergröße (der Rest wird verworfen).
    • Die Fähigkeit, auf die Festplatte zu schreiben, besteht in diesem Fall eine Zustellgarantie (mindestens einmal).
    • Das Einfügungsintervall ist einmal alle 2 Sekunden.

    Erste Probleme


    Das erste Problem trat auf, als der ClickHouse-Server mehrere Stunden ausgeschaltet und wieder eingeschaltet wurde. Im Folgenden sehen Sie den



    Lastdurchschnitt auf dem Server, nachdem er „ gestiegen “ ist: Dies wird ganz einfach erklärt: ClickHouse verfügt über ein Netzwerk-Threading-Modell - pro Verbindung. Wenn Sie also versuchen, INSERT aus tausend Knoten gleichzeitig zu erstellen, besteht ein starker Wettbewerb um CPU-Ressourcen und Server antwortete kaum. Alle Daten wurden jedoch irgendwann eingefügt und nichts fiel.

    Um dieses Problem zu lösen, haben wir nginx vor ClickHouse gestellt und im Allgemeinen hat es geholfen.

    Weiterentwicklung


    Während des Betriebs sind wir auf einige Probleme gestoßen, meist nicht bei ClickHouse, sondern bei unserer Verwendung. Hier ist ein weiterer Rechen, auf den wir getreten sind:

    Eine große Anzahl von "Chunks" in Puffertabellen führt zu häufigen Pufferabbrüchen in MergeTree


    In unserem Fall gab es 16 Puffer und alle 2 Sekunden ein Rücksetzintervall sowie Tabellen mit 20 Teilen, was bis zu 160 Einsätze pro Sekunde ergab. Dies wirkte sich periodisch sehr negativ auf die Einfügungsleistung aus - viele Hintergrundzusammenführungen erschienen und die Festplattenauslastung erreichte 80% und mehr.

    Lösung: Das Standardintervall zum Zurücksetzen des Puffers wurde erhöht, die Anzahl der Teile wurde auf 2 reduziert.

    Nginx ergibt 502, wenn Upstream-Verbindungen enden


    Dies ist an sich kein Problem, aber in Kombination mit dem häufigen Leeren des Puffers ergab dies einen ziemlich hohen Hintergrund von 502 Fehlern, wenn versucht wurde, in eine der Tabellen eingefügt zu werden, und wenn versucht wurde, SELECT auszuführen.

    Lösung: Sie haben ihren Reverse-Proxy mit der fasthttp- Bibliothek geschrieben , die die Einfügung in Tabellen gruppiert und die Verbindungen sehr wirtschaftlich verbraucht. Es unterscheidet auch zwischen SELECT und INSERT und verfügt über separate Verbindungspools zum Einfügen und Lesen.



    Bei intensivem Einfügen ist der Speicher erschöpft


    Die fasthttp-Bibliothek hat ihre Vor- und Nachteile. Einer der Nachteile besteht darin, dass die Anforderung und die Antwort vollständig im Speicher zwischengespeichert werden, bevor sie dem Anforderungshandler die Kontrolle geben. In unserem Fall führte dies dazu, dass, wenn die Einfügung in ClickHouse keine Zeit hatte, die Puffer zu wachsen begannen und schließlich der gesamte Speicher auf dem Server zu Ende ging, was dazu führte, dass der Reverse-Proxy über OOM getötet wurde. Kollegen zeichneten einen Demotivator:



    Lösung: Das Patchen von fasthttp zur Unterstützung des Bodystreaming einer POST-Anforderung war keine einfache Aufgabe. Daher entschieden wir uns für die Verwendung von Hijack () - Verbindungen und ein Upgrade der Verbindung zu Ihrem Protokoll, wenn eine Anforderung mit der KITTEN-HTTP-Methode geliefert wurde. Da der Server als Antwort auf MEOW antworten muss, wenn er dieses Protokoll versteht, wird das gesamte Schema als KITTEN / MEOW-Protokoll bezeichnet.

    Wir lesen nur von 50 zufälligen Verbindungen zur gleichen Zeit. Daher warten die übrigen Clients dank TCP / IP „warten“, und wir belegen keinen Speicher für Puffer, bis die Warteschlange die entsprechenden Clients erreicht hat. Dadurch wurde der Speicherbedarf um mindestens das 20-fache reduziert, und wir hatten keine derartigen Probleme mehr.

    ALTER-Tabellen können bei langen Abfragen sehr lange dauern.


    ClickHouse verfügt über ein nicht blockierendes ALTER - in dem Sinne, dass die Ausführung von SELECT-Abfragen und INSERT-Abfragen nicht beeinträchtigt wird. ALTER kann jedoch nicht beginnen, bevor die Abfragen an diese Tabelle abgeschlossen und vor ALTER gesendet wurden.

    Wenn Sie auf dem Server einen Hintergrund von "langen" Abfragen für einige Tabellen haben, kann es vorkommen, dass ALTER für diese Tabelle keine Zeit zum Ausführen in einem Standardzeitlimit von 60 Sekunden hat. Dies bedeutet jedoch nicht, dass ALTER nicht bestanden wird. Es wird ausgeführt, sobald die Ausführung der SELECT-Abfragen abgeschlossen ist.

    Dies bedeutet, dass Sie nicht wissen, zu welchem ​​Zeitpunkt ALTER tatsächlich aufgetreten ist, und Sie können die Puffertabellen nicht automatisch neu erstellen, sodass ihr Schema immer dasselbe ist. Dies kann zu Problemen beim Einfügen führen.





    Lösung:Daher möchten wir auf die Verwendung von Puffertabellen vollständig verzichten. Im Allgemeinen haben Puffertabellen einen Gültigkeitsbereich, wir verwenden sie immer noch und haben keine großen Probleme. Jetzt ist es endlich soweit, dass es einfacher ist, die Funktionalität von Puffertabellen auf der Reverse-Proxy-Seite zu implementieren, als sich mit ihren Nachteilen abzufinden. Das ungefähre Schema sieht wie folgt aus (die gepunktete Linie zeigt die asynchrone ACK in INSERT).



    Daten lesen


    Nehmen wir an, wir verstehen die Einlage. Wie lesen Sie diese Protokolle von ClickHouse? Leider haben wir keine praktischen und benutzerfreundlichen Tools zum Lesen von Rohdaten (ohne Grafiken und andere Elemente) in ClickHouse gefunden. Deshalb haben wir unsere Lösung LightHouse geschrieben. Seine Fähigkeiten sind eher bescheiden:

    • Schnellansicht des Inhalts der Tabellen.
    • Filtern, sortieren.
    • SQL-Abfrage bearbeiten
    • Tabellenstruktur anzeigen.
    • Zeigt die ungefähre Anzahl von Zeilen und Speicherplatz an.

    LightHouse ist jedoch schnell und kann tun, was wir brauchen. Hier einige Screenshots:

    Tabellenstruktur anzeigen



    Inhaltsfilterung



    Ergebnisse


    ClickHouse ist praktisch die einzige Open-Source-Datenbank, die sich bei VKontakte verwurzelt hat. Wir sind mit der Geschwindigkeit seiner Arbeit zufrieden und sind bereit, die im Folgenden diskutierten Mängel zu ertragen.

    Schwierigkeiten bei der Arbeit


    Im Allgemeinen ist ClickHouse eine sehr stabile Datenbank und sehr schnell. Wie bei jedem Produkt, vor allem bei so jungen Produkten, gibt es jedoch Merkmale in der Arbeit, die berücksichtigt werden müssen:

    • Nicht alle Versionen sind gleich stabil: Aktualisieren Sie die Produktion nicht auf eine neue Version. Warten Sie besser auf mehrere Bugfix-Versionen.
    • Für eine optimale Leistung ist es äußerst ratsam, RAID und einige andere Dinge gemäß den Anweisungen zu konfigurieren. Dies wurde kürzlich unter Hochlast gemeldet .
    • Die Replikation hat keine integrierten Geschwindigkeitsbegrenzungen und kann zu einer erheblichen Beeinträchtigung der Serverleistung führen, wenn sie nicht auf sich selbst beschränkt ist (dies wird jedoch voraussichtlich behoben).
    • In Linux gibt es ein unangenehmes Merkmal des virtuellen Speichermechanismus: Wenn Sie aktiv auf die Festplatte schreiben und die Daten keine Zeit zum Zurücksetzen haben, "geht der Server irgendwann vollständig auf sich selbst", beginnt der Seitencache aktiv auf die Festplatte zurückzusetzen und blockiert den ClickHouse-Prozess fast vollständig. Dies geschieht manchmal bei großen Zusammenführungen, und dies muss überwacht werden, z. B. das periodische Leeren der Puffer selbst oder das Synchronisieren.

    Open Source


    KittenHouse und LightHouse sind jetzt in unserem Github-Repository als Open Source verfügbar:


    Danke!

    Yuri Nasretdinov, Entwickler im Bereich Backend-Infrastruktur von VKontakte

    Jetzt auch beliebt: