{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Wir werden die Arbeit von Zabbix mit der TimescaleDB-Datenbank als Backend betrachten. Wir zeigen, wie man sie von Grund auf startet und wie man von PostgreSQL migriert. Au\u00dferdem werden wir vergleichende Leistungstests der beiden Konfigurationen anstellen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Sibirien 2019. Raum \u201eTomsk\u201c. 24. Juni, 16:00. Thesen und <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">Pr\u00e4sentation<\/a><\/noindex>. Die n\u00e4chste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Details und Tickets <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">unter diesem Link<\/a><\/noindex>.<\/p>\n<p><b>Andrei Gu\u0161\u010din (im Folgenden \u2013 AG):<\/b> \u2013 Ich bin Ingenieur im technischen Support von ZABBIX (im Folgenden \u2013 \u201eZabbix\u201c), Trainer. Ich arbeite seit \u00fcber 6 Jahren im technischen Support und hatte direkten Kontakt mit der Leistung. Heute werde ich \u00fcber die Leistung sprechen, die TimescaleDB im Vergleich zu herk\u00f6mmlichem PostgreSQL 10 bieten kann. Auch ein gewisser einf\u00fchrender Teil \u2013 dar\u00fcber, wie es \u00fcberhaupt funktioniert.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Die gr\u00f6\u00dften Herausforderungen in der Leistung: von der Datensammlung bis zur Datenbereinigung<\/h3>\n<p>\nBeginnen wir damit, dass es bestimmte Leistungsherausforderungen gibt, denen jedes \u00dcberwachungssystem gegen\u00fcbersteht. Die erste Herausforderung der Leistung besteht darin, Daten schnell zu sammeln und zu verarbeiten.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEin gutes \u00dcberwachungssystem sollte schnell und rechtzeitig alle Daten erfassen, sie gem\u00e4\u00df den Triggerausdr\u00fccken verarbeiten, das hei\u00dft nach bestimmten Kriterien (in verschiedenen Systemen ist dies unterschiedlich) und in der Datenbank speichern, um diese Daten sp\u00e4ter zu verwenden.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie zweite Herausforderung der Leistung besteht darin, die Historie zu speichern. Die Daten in der Datenbank zu speichern und schnellen sowie bequemen Zugriff auf diese Metriken zu haben, die \u00fcber einen bestimmten Zeitraum gesammelt wurden. Am wichtigsten ist, dass diese Daten leicht abrufbar sind und f\u00fcr Berichte, Grafiken, Trigger, Schwellenwerte f\u00fcr Benachrichtigungen usw. verwendet werden k\u00f6nnen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie dritte Herausforderung der Leistung besteht darin, die Historie zu bereinigen, das hei\u00dft, wenn der Tag kommt, an dem Sie bestimmte detaillierte Metriken, die \u00fcber 5 Jahre gesammelt wurden (sogar Monate oder zwei Monate), nicht mehr speichern m\u00fcssen. Einige Knoten im Netzwerk wurden gel\u00f6scht oder einige Hosts sind nicht mehr erforderlich, da die Metriken veraltet sind und nicht mehr gesammelt werden. All dies muss gereinigt werden, damit Ihre Datenbank nicht auf eine gro\u00dfe Gr\u00f6\u00dfe anw\u00e4chst. Und im Allgemeinen ist die Bereinigung der Historie oft eine ernsthafte Pr\u00fcfung f\u00fcr den Speicher \u2013 sie wirkt sich oft erheblich auf die Leistung aus.<\/p>\n<h3>Wie l\u00f6sen wir die Probleme mit dem Caching?<\/h3>\n<p>\nIch werde jetzt konkret \u00fcber \u00abZabbix\u00bb sprechen. In \u00abZabbix\u00bb werden die ersten und zweiten Aufrufe durch Caching gel\u00f6st.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDatensammlung und -verarbeitung \u2013 wir verwenden den Arbeitsspeicher, um all diese Daten zu speichern. Jetzt wird \u00fcber diese Daten genauer berichtet.<\/p>\n<p>Auch auf der Seite der Datenbank gibt es ein gewisses Caching f\u00fcr grundlegende Abfragen \u2013 f\u00fcr Diagramme und andere Dinge.<\/p>\n<p>Caching auf der Seite des Zabbix-Servers: Wir haben ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Was ist das?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente, Trigger speichern; alles, was f\u00fcr die Verarbeitung von Preprocessing, Datensammlung ben\u00f6tigt wird, von welchen Hosts gesammelt werden soll und in welcher H\u00e4ufigkeit. All dies wird im ConfigurationCache gespeichert, um nicht immer auf die Datenbank zugreifen und \u00fcberfl\u00fcssige Anfragen erstellen zu m\u00fcssen. Nach dem Start des Servers aktualisieren wir diesen Cache (erstellen ihn) und aktualisieren ihn regelm\u00e4\u00dfig (je nach Konfigurationseinstellungen).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching in Zabbix. Datensammlung<\/h3>\n<p>\nHier ist das Schema ausreichend gro\u00df:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Hauptakteure im Schema sind diese Sammler:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas sind die eigentlichen Sammelprozesse, verschiedene \u00abPoller\u00bb, die f\u00fcr unterschiedliche Arten von Abfragen verantwortlich sind. Sie sammeln Daten \u00fcber ICMP, IPMI, verschiedene Protokolle und leiten alles an das Preprocessing weiter.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAu\u00dferdem, wenn wir berechnete Datenelemente haben (wer mit \u00abZabbix\u00bb vertraut ist, wei\u00df das), gibt es berechnete, aggregierte Datenelemente \u2013 wir beziehen sie direkt aus dem ValueCache. Wie er gef\u00fcllt wird, werde ich sp\u00e4ter erl\u00e4utern. Alle diese Sammler nutzen ConfigurationCache, um ihre Aufgaben zu erhalten, und leiten sie dann zum Preprocessing weiter.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas Preprocessing nutzt ebenfalls ConfigurationCache, um die Schritte zu erhalten, bearbeitet diese Daten auf vielf\u00e4ltige Weise. Seit Version 4.2 wurde es auf einen Proxy ausgelagert. Das ist sehr praktisch, da das Preprocessing selbst eine recht anspruchsvolle Aufgabe ist. Und wenn Sie ein sehr gro\u00dfes \u00abZabbix\u00bb mit einer gro\u00dfen Anzahl von Datenelementen und einer hohen Abfragerate haben, erleichtert das die Arbeit erheblich.<\/p>\n<p>Dementsprechend, nachdem wir diese Daten auf irgendeine Weise mit Hilfe des Preprocessings bearbeitet haben, speichern wir sie im HistoryCache, um sie weiter zu verarbeiten. Damit endet die Datensammlung. Wir kommen zum Hauptprozess.<\/p>\n<h3>Arbeit des History Syncers<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer wichtigste Prozess in \u201eZabbix\u201c (da es sich um eine monolithische Architektur handelt) ist der History Syncer. Dies ist der Hauptprozess, der sich mit der atomaren Verarbeitung jedes Datenelements besch\u00e4ftigt, also jedes Wertes.<\/p>\n<ul>\n<li>ein Wert kommt (er entnimmt ihn aus dem HistoryCache);<\/li>\n<li>\u00fcberpr\u00fcft im Configuration Syncer: Gibt es Trigger f\u00fcr Berechnungen \u2013 er berechnet sie;<br \/>\nwenn ja \u2013 erstellt er Ereignisse, erstellt eine Eskalation, um eine Benachrichtigung zu erzeugen, wenn dies gem\u00e4\u00df der Konfiguration erforderlich ist;<\/li>\n<li>speichert Trigger f\u00fcr die sp\u00e4tere Verarbeitung, Aggregation; wenn Sie aggregieren, z. B. in der letzten Stunde, merkt sich dieser Wert den ValueCache, um nicht auf die Historientabelle zugreifen zu m\u00fcssen; so wird der ValueCache mit den notwendigen Daten gef\u00fcllt, die zur Berechnung der Trigger, der berechneten Elemente usw. ben\u00f6tigt werden;<\/li>\n<li>dar\u00fcber hinaus speichert der History Syncer alle Daten in der Datenbank;<\/li>\n<li>die Datenbank schreibt sie auf die Festplatte \u2013 damit endet der Verarbeitungsprozess.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Datenbanken. Caching<\/h3>\n<p>\nAuf der Datenbankseite, wenn Sie Grafiken oder Berichte \u00fcber Ereignisse sehen m\u00f6chten, gibt es verschiedene Caches. Aber im Rahmen dieses Vortrags werde ich nicht dar\u00fcber sprechen.<\/p>\n<p>F\u00fcr MySQL gibt es den Innodb_buffer_pool und eine Menge anderer Caches, die ebenfalls konfiguriert werden k\u00f6nnen.<br \/>\nAber das sind die Hauptsachen:<\/p>\n<ul>\n<li>shared_buffers;<\/li>\n<li>effective_cache_size;<\/li>\n<li>shared_pool.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch habe f\u00fcr alle Datenbanken aufgef\u00fchrt, dass es bestimmte Caches gibt, die es erm\u00f6glichen, die h\u00e4ufig ben\u00f6tigten Daten im Arbeitsspeicher zu halten. Dort haben sie ihre eigenen Technologien daf\u00fcr.<\/p>\n<h3>Zur Datenbankleistung<\/h3>\n<p>\nDementsprechend gibt es ein wettbewerbsf\u00e4higes Umfeld, das hei\u00dft, der \u201eZabbix\u201c-Server sammelt Daten und schreibt sie. Beim Neustart liest er ebenfalls aus der Historie, um den ValueCache zu f\u00fcllen usw. Gleichzeitig k\u00f6nnen Sie Skripte und Berichte haben, die die \u201eZabbix\u201c-API verwenden, die auf der webbasierten Benutzeroberfl\u00e4che basiert. Die \u201eZabbix\u201c-API greift auf die Datenbank zu und erh\u00e4lt die ben\u00f6tigten Daten f\u00fcr Grafiken, Berichte oder eine Liste von Ereignissen, den letzten Problemen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAuch eine sehr beliebte L\u00f6sung zur Visualisierung ist Grafana, die von unseren Nutzern verwendet wird. Es kann sowohl direkt \u00fcber die \u201eZabbix\u201c-API als auch \u00fcber die Datenbank eingreifen. Es schafft ebenfalls einen gewissen Wettbewerb um den Datenzugriff: Eine feinere, gute Datenbankkonfiguration ist erforderlich, um schnelle Ergebnisse und Tests zu gew\u00e4hrleisten.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Geschichte l\u00f6schen. In Zabbix gibt es den Housekeeper<\/h3>\n<p>\nEin dritter Aufruf, der in \"Zabbix\" verwendet wird, ist das L\u00f6schen der Geschichte mithilfe des Housekeepers. Der \"Housekeeper\" beachtet alle Einstellungen, das hei\u00dft, in unseren Datenelementen ist angegeben, wie lange (in Tagen) die Daten gespeichert werden sollen, wie lange Trends und \u00c4nderungsdynamiken gespeichert werden.<\/p>\n<p>Ich habe nichts \u00fcber den TrendCache gesagt, den wir in Echtzeit berechnen: Daten kommen herein, wir aggregieren sie \u00fcber eine Stunde (haupts\u00e4chlich handelt es sich um Zahlen der letzten Stunde), die durchschnittliche\/minimale Anzahl und schreiben dies einmal pro Stunde in die \u00c4nderungsdynamikstabelle (\"Trends\"). Der \"Housekeeper\" wird gestartet und l\u00f6scht die Daten mit normalen Selects aus der DB, was nicht immer effizient ist.<\/p>\n<p>Wie erkennt man, dass das ineffizient ist? Sie k\u00f6nnen in den Performancegrafiken der internen Prozesse folgendes Bild sehen:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIhr History syncer ist st\u00e4ndig besch\u00e4ftigt (rote Grafik). Und die \"orange\" Linie, die oben verl\u00e4uft, ist der \"Housekeeper\", der gestartet wird und darauf wartet, dass die DB alle Zeilen l\u00f6scht, die er festgelegt hat.<\/p>\n<p>Nehmen wir eine beliebige Item-ID: Die letzten 5000 m\u00fcssen gel\u00f6scht werden; nat\u00fcrlich nach Indizes. Aber normalerweise ist das Dataset recht gro\u00df \u2013 die Datenbank liest dies trotzdem von der Festplatte und hebt es in den Cache, und das ist eine sehr kostspielige Operation f\u00fcr die DB. Je nach Gr\u00f6\u00dfe kann dies zu bestimmten Performanceproblemen f\u00fchren.<\/p>\n<p>Der \"Housekeeper\" l\u00e4sst sich einfach deaktivieren \u2013 wir haben die allen bekannten Weboberfl\u00e4che. Die Einstellung in der Administration general (Einstellungen f\u00fcr den \"Housekeeper\") deaktiviert das interne Housekeeping f\u00fcr die interne Geschichte und die Trends. Folglich verwaltet der \"Housekeeper\" dies nicht mehr:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWas kann man als N\u00e4chstes tun? Sie haben ihn deaktiviert, Ihre Grafiken haben sich eingependelt... Welche Probleme k\u00f6nnen in diesem Fall noch auftreten? Was kann helfen?<\/p>\n<h3>Partitionierung<\/h3>\n<p>\nNormalerweise wird dies auf jeder relationalen Datenbank, die ich aufgez\u00e4hlt habe, auf unterschiedliche Weise eingerichtet. MySQL hat seine eigene Technologie. Aber insgesamt sind sie sehr \u00e4hnlich, wenn wir \u00fcber PostgreSQL 10 und MySQL sprechen. Nat\u00fcrlich gibt es viele interne Unterschiede, wie das alles umgesetzt wird und wie sich das auf die Performance auswirkt. Aber insgesamt f\u00fchrt das Anlegen einer neuen Partition oft ebenfalls zu bestimmten Problemen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJe nach Ihrem Setup (wie viele Daten Sie an einem Tag generieren) wird normalerweise das Minimum festgelegt \u2013 das sind 1 Tag\/Partition, und f\u00fcr \u201eTrends\u201c, Ver\u00e4nderungen \u2013 1 Monat\/neue Partition. Dies kann sich \u00e4ndern, wenn Ihr Setup sehr gro\u00df ist.<\/p>\n<p>Lassen Sie mich gleich zu den Gr\u00f6\u00dfen des Setups sagen: Bis zu 5.000 neue Werte pro Sekunde (nvps, wie man so sch\u00f6n sagt) gelten als kleines \u201eSetup\u201c. Mittelgro\u00df sind 5 bis 25 Tausend Werte pro Sekunde. Alles dar\u00fcber hinaus ist bereits gro\u00dfe und sehr gro\u00dfe Installationen, die eine sehr sorgf\u00e4ltige Datenbankkonfiguration erfordern.<\/p>\n<p>Bei sehr gro\u00dfen Installationen ist 1 Tag m\u00f6glicherweise nicht optimal. Ich habe pers\u00f6nlich auf MySQL Partitionen von 40 Gigabyte pro Tag (und mehr) gesehen. Dies ist ein sehr gro\u00dfes Datenvolumen, das zu Problemen f\u00fchren kann. Es muss reduziert werden.<\/p>\n<h3>Warum ist Partitionierung notwendig?<\/h3>\n<p>\nWas Partitionierung bietet, denke ich, wissen alle \u2013 das ist die Zerlegung von Tabellen. Oft sind das separate Dateien auf der Festplatte und span-abfragen. Es w\u00e4hlt eine Partition optimaler aus, wenn es in die normale Partitionierung passt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00fcr \u201eZabbix\u201c wird insbesondere nach Reichweite, das hei\u00dft nach Zeitstempel (eine gew\u00f6hnliche Zahl, Zeit seit Beginn der Epoche) partitioniert. Sie setzen den Beginn des Tages\/Ende des Tages, und dies bildet die Partition. Entsprechend, wenn Sie auf Daten von vor zwei Tagen zugreifen, wird alles schneller aus der Datenbank abgerufen, weil nur eine Datei in den Cache geladen und ausgegeben werden muss (nicht eine gro\u00dfe Tabelle).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nViele DBs arbeiten auch bei Inserts (Einf\u00fcgungen in eine Child-Tabelle) schneller. W\u00e4hrend ich abstrakt spreche, ist das auch m\u00f6glich. Partitionierung hilft oft.<\/p>\n<h3>Elasticsearch f\u00fcr NoSQL<\/h3>\n<p>\nNeu in 3.4 haben wir eine L\u00f6sung f\u00fcr NoSQL implementiert. Wir haben die M\u00f6glichkeit hinzugef\u00fcgt, in Elasticsearch zu schreiben. Sie k\u00f6nnen bestimmte Typen w\u00e4hlen: entweder Zahlen oder bestimmte Zeichen; wir haben String-Text, Logs k\u00f6nnen Sie in Elasticsearch schreiben\u2026 Entsprechend wird das Web-Interface auch auf Elasticsearch zugreifen. Das funktioniert in manchen F\u00e4llen hervorragend, kann aber momentan genutzt werden.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hypertabellen<\/h3>\n<p>\nF\u00fcr 4.4.2 haben wir auf eine Sache geachtet, wie TimescaleDB. Was ist das? Es ist eine Erweiterung f\u00fcr PostgreSQL, das bedeutet, es hat eine native PostgreSQL-Schnittstelle. Dar\u00fcber hinaus erm\u00f6glicht diese Erweiterung eine viel effizientere Arbeit mit Zeitserien-Daten und hat ein automatisches Partionierungssystem. So sieht das aus:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas ist ein Hypertable \u2013 ein Konzept in Timescale. Das ist die Hypertabelle, die Sie erstellen, und darin befinden sich Chunks. Chunks sind Partitionen, dies sind Kind-Tabellen, wenn ich mich nicht irre. Das ist wirklich effizient.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB und PostgreSQL<\/h3>\n<p>\nDie Hersteller von TimescaleDB versichern, dass sie einen besseren Algorithmus zur Bearbeitung von Anfragen verwenden, insbesondere von Inserts, der es erm\u00f6glicht, eine nahezu konstante Leistung bei wachsendem Datensatzvolumen zu gew\u00e4hrleisten. Nach 200 Millionen Zeilen beginnt ein gew\u00f6hnliches PostgreSQL-System, erheblich langsamer zu werden und verliert seine Leistung fast auf null, w\u00e4hrend Timescale es erm\u00f6glicht, Inserts so effizient wie m\u00f6glich bei beliebiger Datenmenge einzuf\u00fcgen.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Wie installiere ich TimescaleDB? Ganz einfach!<\/h3>\n<p>\nIn der Dokumentation gibt es es, es ist beschrieben \u2013 Sie k\u00f6nnen es aus den Paketen f\u00fcr alle installieren\u2026 Es h\u00e4ngt von den offiziellen PostgreSQL-Paketen ab. Man kann es manuell kompilieren. So kam es, dass ich f\u00fcr die Datenbank kompilieren musste.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn Zabbix aktivieren wir einfach die Extension. Ich denke, dass diejenigen, die die Extension in PostgreSQL verwendet haben\u2026 Sie aktivieren einfach die Extension, erstellen sie f\u00fcr die Zabbix-Datenbank, die Sie nutzen.<\/p>\n<p>Und der letzte Schritt\u2026<\/p>\n<h3>TimescaleDB. Migration von Historientabellen<\/h3>\n<p>\nSie m\u00fcssen einen Hypertable erstellen. Daf\u00fcr gibt es eine spezielle Funktion \u2013 Create hypertable. Im ersten Parameter geben Sie die Tabelle an, die in dieser Datenbank ben\u00f6tigt wird (f\u00fcr die die Hypertabelle erstellt werden soll).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFeld, nach dem erstellt werden soll, und chunk_time_interval (dies ist der Chunk-Zeitintervall (Partitionen, die verwendet werden sollen). 86.400 \u2013 das ist ein Tag. <\/p>\n<p>Parameter migrate_data: Wenn Sie ihn auf true setzen, werden alle aktuellen Daten in die zuvor erstellten Chunks verschoben.<\/p>\n<p>Ich habe selbst migrate_data verwendet \u2013 es dauert eine betr\u00e4chtliche Zeit, je nach Gr\u00f6\u00dfe Ihrer Datenbank. Ich hatte mehr als ein Terabyte \u2013 die Erstellung dauerte mehr als eine Stunde. In einigen F\u00e4llen habe ich w\u00e4hrend der Tests historische Daten f\u00fcr den Text (history_text) und den String (history_str) gel\u00f6scht, um sie nicht zu \u00fcbertragen \u2013 sie waren mir tats\u00e4chlich nicht interessant.<\/p>\n<p>Und das letzte Update nehmen wir in unserer db_extension vor: Wir installieren TimescaleDB, damit die DB und insbesondere unser \u201eZabbix\u201c verstehen, dass es eine db_extension gibt. Diese aktiviert es und verwendet die Syntax und Abfragen zur DB korrekt, indem es die bereits erforderlichen \u201eFeatures\u201c f\u00fcr TimescaleDB nutzt.<\/p>\n<h3>Serverkonfiguration<\/h3>\n<p>\nIch habe zwei Server verwendet. Der erste Server ist eine ziemlich kleine virtuelle Maschine mit 20 Prozessoren und 16 Gigabyte RAM. Ich habe darauf PostgreSQL 10.8 eingerichtet:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas Betriebssystem war Debian, das Dateisystem \u2013 xfs. Ich habe minimale Einstellungen vorgenommen, um genau diese Datenbank zu verwenden, abgesehen davon, dass auch \u201eZabbix\u201c selbst verwendet wird. Auf demselben Rechner waren der \u201eZabbix\u201c-Server, PostgreSQL und Lastagenten installiert.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch habe 50 aktive Agenten verwendet, die LoadableModule nutzen, um schnell verschiedene Ergebnisse zu generieren. Diese erzeugten Zeilen, Zahlen und so weiter. Ich habe die DB mit einer gro\u00dfen Menge Daten gef\u00fcllt. Die anf\u00e4ngliche Konfiguration umfasste 5.000 Datenelemente pro Host, und ungef\u00e4hr jedes Datenelement hatte einen Trigger \u2013 um eine reale Konfiguration zu erstellen. Manchmal ist sogar mehr als ein Trigger erforderlich.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch habe das Update-Intervall geregelt, indem ich nicht nur 50 Agenten verwendet habe (ich habe weitere hinzugef\u00fcgt), sondern auch mit Hilfe dynamischer Datenelemente und das Update-Intervall auf 4 Sekunden reduziert.<\/p>\n<h3>Leistungstest. PostgreSQL: 36.000 NVPs<\/h3>\n<p>\nDer erste Lauf, die erste Konfiguration war auf einer reinen PostgreSQL 10-Installation auf dieser Hardware (35.000 Werte pro Sekunde). Im Allgemeinen, wie auf dem Bildschirm sichtbar, dauert das Einf\u00fcgen von Daten Bruchteile einer Sekunde \u2013 alles l\u00e4uft gut und schnell, SSD-Festplatten (200 Gigabyte). Das Einzige, was ist, dass 20 GB ziemlich schnell gef\u00fcllt werden.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs wird weiterhin viele solcher Diagramme geben. Dies ist das Standard-Dashboard f\u00fcr die Leistung des \u201eZabbix\u201c-Servers.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas erste Diagramm \u2013 die Anzahl der Werte pro Sekunde (blau, oben links), 35.000 Werte in diesem Fall. Dies (oben in der Mitte) ist die Auslastung der Sammlungsprozesse, und dies (oben rechts) ist die Auslastung der internen Prozesse: History Syncers und Housekeeper, der hier (unten in der Mitte) eine betr\u00e4chtliche Zeit in Anspruch nahm.<\/p>\n<p>Dieses Diagramm (unten in der Mitte) zeigt die Nutzung des ValueCache \u2013 wie viele ValueCache-Treffer f\u00fcr Trigger (einige tausend Werte pro Sekunde). Ein weiteres wichtiges Diagramm ist das vierte (unten links), das die Nutzung des HistoryCache zeigt, von dem ich gesprochen habe, der ein Puffer vor dem Einf\u00fcgen in die DB ist.<\/p>\n<h3>Leistungstest. PostgreSQL: 50 Tausend NVPs<\/h3>\n<p>\nDanach habe ich die Belastung auf 50 Tausend Werte pro Sekunde auf derselben Hardware erh\u00f6ht. Beim Laden mit dem \u201eHauskeeper\u201c wurden 10 Tausend Werte bereits in 2-3 Sekunden mit Berechnung geschrieben. Das wird im n\u00e4chsten Screenshot gezeigt:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer \u201eHauskeeper\u201c f\u00e4ngt an, die Arbeit zu st\u00f6ren, aber insgesamt liegt die Auslastung der History-Sync-Server noch bei 60 % (drittes Diagramm, oben rechts). Der HistoryCache beginnt w\u00e4hrend der Arbeit des \u201eHauskeepers\u201c aktiv gef\u00fcllt zu werden (unten links). Er lag bei etwa einem halben Gigabyte und f\u00fcllte sich um 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Leistungstest. PostgreSQL: 80 Tausend NVPs<\/h3>\n<p>\nIch habe die Belastung auf 80 Tausend Werte pro Sekunde erh\u00f6ht:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas waren etwa 400 Tausend Datenelemente, 280 Tausend Trigger. Wie Sie sehen k\u00f6nnen, war die Einf\u00fcgebelastung der History-Sync-Server (es gab 30 St\u00fcck) bereits ziemlich hoch. Danach habe ich verschiedene Parameter erh\u00f6ht: History-Sync-Server, Cache... Auf dieser Hardware begann die Auslastung der History-Sync-Server, sich dem Maximum zu n\u00e4hern, praktisch \u201ein die H\u00f6he\u201c \u2013 entsprechend stieg die Auslastung des HistoryCache sehr stark an:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW\u00e4hrend dieser ganzen Zeit habe ich alle Systemparameter \u00fcberwacht (wie CPU und RAM genutzt werden) und festgestellt, dass die Festplattenauslastung maximal war \u2013 ich hatte die maximale Kapazit\u00e4t dieser Festplatte auf dieser Hardware, auf dieser virtuellen Maschine, erreicht. PostgreSQL begann bei solcher Intensit\u00e4t, Daten ziemlich aktiv abzulehnen, und die Festplatte konnte nicht schnell genug schreiben und lesen...<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch habe einen anderen Server genommen, der bereits 48 Prozessoren und 128 Gigabyte RAM hatte:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAu\u00dferdem habe ich ihn \u201eaufger\u00fcstet\u201c \u2013 ich habe 60 History-Sync-Server installiert und eine akzeptable Leistung erreicht. Tats\u00e4chlich sind wir nicht \u201ein die H\u00f6he\u201c, aber das ist wahrscheinlich schon das Leistungslimit, wo man damit etwas unternehmen muss.<\/p>\n<h3>Leistungstest. TimescaleDB: 80 Tausend NVPs<\/h3>\n<p>\nIch hatte die Hauptaufgabe \u2013 TimescaleDB zu nutzen. In jedem Diagramm ist ein Einbruch zu sehen:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDiese Ausf\u00e4lle entsprechen genau der Migration von Daten. Danach hat sich das Profil des History-Sinkers auf dem 'Zabbix'-Server, wie Sie sehen, deutlich ver\u00e4ndert. Es erlaubt, Daten fast dreimal schneller einzuf\u00fcgen und ben\u00f6tigt weniger HistoryCache \u2013 entsprechend werden Ihnen die Daten rechtzeitig bereitgestellt. Wieder einmal: 80.000 Werte pro Sekunde \u2013 das ist eine ziemlich hohe Rate (nat\u00fcrlich nicht f\u00fcr 'Yandex'). Insgesamt handelt es sich um ein recht gro\u00dfes Setup mit einem Server.<\/p>\n<h3>Leistungstest von PostgreSQL: 120.000 NVPs<\/h3>\n<p>\nDann habe ich die Anzahl der Datenelemente auf eine halbe Million erh\u00f6ht und einen berechneten Wert von 125.000 pro Sekunde erhalten:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd ich habe solche Grafiken erhalten:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIm Prinzip ist dies ein funktionierendes Setup, es kann eine recht lange Zeit arbeiten. Aber da ich nur eine Festplatte mit 1,5 Terabyte hatte, habe ich sie in ein paar Tagen verbraucht. Das Wichtigste ist, dass zur gleichen Zeit neue Partitionen auf TimescaleDB erstellt wurden und das f\u00fcr die Leistung vollkommen unauff\u00e4llig war, was man von MySQL nicht sagen kann.<\/p>\n<p>Normalerweise werden Partitionen nachts erstellt, da dies das Einf\u00fcgen und die Arbeit mit Tabellen insgesamt blockiert und zu einer Verschlechterung des Services f\u00fchren kann. In diesem Fall ist das nicht der Fall! Die Hauptaufgabe war es \u2013 die M\u00f6glichkeiten von TimescaleDB zu \u00fcberpr\u00fcfen. Es ergab sich eine Zahl von 120.000 Werten pro Sekunde.<\/p>\n<p>Es gibt auch Beispiele in der 'Community':<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEine Person hat ebenfalls TimescaleDB aktiviert und die Belastung durch die Verwendung von io.weight ist auf dem Prozessor gesunken; auch die Nutzung interner Prozesse wurde durch die Aktivierung von TimescaleDB verringert. Dabei handelt es sich um normale HDDs, also um eine normale virtuelle Maschine auf normalen Festplatten (nicht SSD)!<\/p>\n<p>F\u00fcr einige kleine Setups, die an der Leistung der Festplatte scheitern, scheint mir TimescaleDB eine sehr gute L\u00f6sung zu sein. Es wird es recht gut erm\u00f6glichen, bis zur Migration auf schnellere Hardware f\u00fcr die Datenbank weiter zu arbeiten.<\/p>\n<p>Ich lade Sie alle zu unseren Veranstaltungen ein: Conference \u2013 in Moskau, Summit \u2013 in Riga. Nutzen Sie unsere Kan\u00e4le \u2013 'Telegram', Forum, IRC. Wenn Sie Fragen haben \u2013 kommen Sie zu unserem Stand, wir k\u00f6nnen \u00fcber alles sprechen.<\/p>\n<h3>Fragen aus dem Publikum<\/h3>\n<p>\nFrage aus dem Publikum (im Folgenden \u2013 A): \u2013 Wenn TimescaleDB so einfach einzurichten ist und so viel Leistungsteigerung bietet, w\u00e4re es dann vielleicht eine gute Idee, dies als beste Praxis f\u00fcr die Einrichtung von \"Zabbix\" mit \"Postgres\" zu verwenden? Gibt es irgendwelche potenziellen Fallen oder Nachteile dieser L\u00f6sung, oder kann ich, wenn ich mich f\u00fcr \"Zabbix\" entschieden habe, beruhigt \"Postgres\" nehmen, direkt \"Timescale\" installieren, es nutzen und mir keine Sorgen um irgendwelche Probleme machen?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Ja, ich w\u00fcrde sagen, dass dies eine gute Empfehlung ist: Verwenden Sie \"Postgres\" gleich mit der Erweiterung TimescaleDB. Wie ich bereits erw\u00e4hnt habe, gibt es viele gute R\u00fcckmeldungen, obwohl dieses \"Feature\" experimentell ist. Aber die Tests zeigen tats\u00e4chlich, dass es eine hervorragende L\u00f6sung (mit TimescaleDB) ist, und ich denke, dass es sich weiterentwickeln wird! Wir beobachten, wie sich diese Erweiterung entwickelt, und werden anpassen, was notwendig ist.<\/p>\n<p>Selbst w\u00e4hrend der Entwicklung haben wir uns auf eines ihrer bekannten \"Features\" gest\u00fctzt: dort konnte man mit Chunks etwas anders arbeiten. Aber dann haben sie es in der n\u00e4chsten Version entfernt, und wir mussten uns nicht mehr auf diesen Code st\u00fctzen. Ich w\u00fcrde empfehlen, diese L\u00f6sung in vielen Setups zu verwenden. Wenn Sie MySQL verwenden... F\u00fcr mittlere Setups funktioniert jede L\u00f6sung ganz gut.<\/p>\n<p><b>A:<\/b> \u2013 In den letzten Diagrammen, die von der Community stammen, gab es ein Diagramm mit \"Housekeeping\":<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs hat weiter funktioniert. Was macht \"Housekeeping\" im Fall von TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Im Moment kann ich das nicht genau sagen \u2013 ich werde den Code anschauen und genauer darauf eingehen. Es verwendet Anfragen von TimescaleDB nicht zum L\u00f6schen von Chunks, sondern aggregiert irgendwie. Ich bin nicht bereit, diese technische Frage jetzt zu beantworten. Wir werden es heute oder morgen am Stand kl\u00e4ren.<\/p>\n<p><b>A:<\/b> \u2013 Ich habe eine \u00e4hnliche Frage \u2013 zur Leistung der L\u00f6schoperation in \"Timescale\".<br \/>\nA (Antwort aus dem Publikum): \u2013 Wenn Sie Daten aus einer Tabelle l\u00f6schen, und wenn Sie das \u00fcber delete tun, m\u00fcssen Sie die Tabelle durchgehen \u2013 l\u00f6schen, aufr\u00e4umen, alles f\u00fcr die zuk\u00fcnftige Vakuumierung markieren. In \"Timescale\" k\u00f6nnen Sie, da Sie Chunks haben, diese einfach entsorgen. Grob gesagt, sagen Sie nur zur Datei, die in den Big Data liegt: \u201eL\u00f6schen!\u201c<\/p>\n<p>\u201eTimescale\u201c versteht einfach, dass es diesen Chunk nicht mehr gibt. Da es in den Abfrageplaner integriert ist, erfasst es Ihre Bedingungen im Select oder in anderen Operationen und erkennt sofort, dass es diesen Chunk nicht mehr gibt \u2013 \u201eIch gehe dort nicht mehr hin!\u201c (Daten fehlen). Das ist alles! Das bedeutet, das Scannen der Tabelle wird durch das L\u00f6schen der Bin\u00e4rdatei ersetzt, deshalb ist das schnell.<\/p>\n<p><b>A:<\/b> \u2013 Wir haben das Thema NoSQL bereits angesprochen. Soweit ich verstehe, ist es f\u00fcr \u201eZabbix\u201c nicht unbedingt n\u00f6tig, Daten zu modifizieren, denn das ist alles eher eine Art Log. Kann man spezialisierte Datenbanken verwenden, die ihre Daten nicht \u00e4ndern k\u00f6nnen, aber dabei viel schneller speichern, sammeln und bereitstellen \u2013 Clickhouse zum Beispiel, oder etwas Kafka-\u00e4hnliches? .. Kafka ist doch auch ein Log! Kann man die irgendwie integrieren?<\/p>\n<p><b>AG:<\/b> \u2013 Einen Export kann man machen. Wir haben ab Version 3.4 eine bestimmte \u201eFunktion\u201c: Sie k\u00f6nnen alle historischen Dateien, Events und alles andere in Dateien schreiben; und dann mit einem Handler an jede andere Datenbank senden. Tats\u00e4chlich machen viele das und schreiben direkt in die Datenbank. Die Histogramm-Synchronisatoren schreiben das alles in Dateien, rotieren diese Dateien usw., und das k\u00f6nnen Sie in \u201eClickhouse\u201c \u00fcbertragen. Ich kann nichts zu den Pl\u00e4nen sagen, aber vielleicht wird die weitere Unterst\u00fctzung von NoSQL-L\u00f6sungen (wie \u201eClickhouse\u201c) fortgesetzt.<\/p>\n<p><b>A:<\/b> \u2013 Also, kann man im Grunde ganz auf PostgreSQL verzichten?<\/p>\n<p><b>AG:<\/b> \u2013 Nat\u00fcrlich, der schwierigste Teil bei \u201eZabbix\u201c sind die historischen Tabellen, die die meisten Probleme verursachen, und die Events. In diesem Fall, wenn Sie Events nicht lange speichern und die Historie mit Trends in einem anderen schnellen Speicher aufbewahren, denke ich, dass es im Allgemeinen keine Probleme geben wird.<\/p>\n<p><b>A:<\/b> \u2013 K\u00f6nnen Sie einsch\u00e4tzen, wie viel schneller alles funktionieren wird, wenn man auf \u201eClickhouse\u201c umschaltet?<\/p>\n<p><b>AG:<\/b> \u2013 Ich habe das nicht getestet. Ich denke, dass man mindestens dieselben Zahlen relativ einfach erreichen kann, wenn man bedenkt, dass \u201eClickhouse\u201c seine eigene Schnittstelle hat, aber ich kann nicht eindeutig sagen. Es ist besser, es zu testen. Alles h\u00e4ngt von der Konfiguration ab: wie viele Hosts Sie haben usw. Das Einf\u00fcgen ist das eine, aber man muss diese Daten auch abholen \u2013 entweder mit Grafana oder etwas anderem.<\/p>\n<p><b>A:<\/b> \u2013 Also geht es um einen gleichwertigen Wettbewerb und nicht um einen gro\u00dfen Vorteil dieser schnellen Datenbanken?<\/p>\n<p><b>AG:<\/b> \u2013 Ich denke, wenn wir integrieren, wird es genauere Tests geben.<\/p>\n<p><b>A:<\/b> \u2013 Wo ist das alte, gute RRD hingekommen? Was hat dazu gef\u00fchrt, dass auf SQL-Datenbanken umgestiegen wurde? Urspr\u00fcnglich wurden alle Metriken ja auf RRD gesammelt.<\/p>\n<p><b>AG:<\/b> \u2013 In \"Zabbix\" gab es RRD vielleicht in einer sehr alten Version. SQL-Datenbanken waren immer vorhanden \u2013 der klassische Ansatz. Der klassische Ansatz sind MySQL, PostgreSQL (existiert schon seit sehr langer Zeit). Wir haben die gemeinsame Schnittstelle f\u00fcr SQL-Datenbanken und RRD praktisch nie genutzt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.\" src=\"\/wp-content\/uploads\/2020\/01\/ac5f02494c63983601cc09c0b22e722b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Ein wenig Werbung \ud83d\ude42<\/h3>\n<p>\nDanke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? M\u00f6chten Sie mehr interessante Inhalte sehen? Unterst\u00fctzen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">Cloud-VPS f\u00fcr Entwickler ab 4,99 $<\/a><\/noindex>, <b>ein einzigartiges \u00c4quivalent zu Einsteigerservern, das wir f\u00fcr Sie entwickelt haben:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Die ganze Wahrheit \u00fcber VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt?<\/a><\/noindex> (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verf\u00fcgbar).<\/p>\n<p><b>Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so g\u00fcnstig?<\/b> Nur bei uns <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab $199<\/a><\/noindex> in den Niederlanden! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 ab $99!<\/b><\/b> Lesen Sie, wie <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern f\u00fcr 9000 Euro im Preis-Leistungs-Verh\u00e4ltnis aufbaut?<\/a><\/noindex><br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/485470\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL. \u0422\u0430\u043a\u0436\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u0432\u0443\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u0422\u043e\u043c\u0441\u043a\u00bb. 24 \u0438\u044e\u043d\u044f, 16:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55734","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Andrej Gu\u0161tin (Zabbix): hohe Leistung und natives Partitionieren | ProHoster","description":"Wir werden die Arbeit von Zabbix mit der TimescaleDB-Datenbank als Backend betrachten. Wir zeigen, wie man von Grund auf neu startet und wie man von PostgreSQL migriert.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55734","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-09-28 01:51:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}