Wie wir mehrere Zeitreihendatenbanken getestet haben

In den letzten Jahren haben sich Zeitreihendatenbanken (Time-series databases) von einer seltsamen Angelegenheit (die entweder in offenen Monitoringsystemen (und an spezifische Lösungen gebunden) oder in Big-Data-Projekten verwendet wurde) zu einem „Alltagsprodukt“ entwickelt. In der Russischen Föderation gebührt dafür ein spezieller Dank Yandex und ClickHouse. Bis zu diesem Zeitpunkt war es, wenn Sie eine große Menge an Zeitreihendaten speichern mussten, entweder notwendig, mit dem monströsen Hadoop-Stack zu arbeiten und ihn zu warten, oder sich mit protokollspezifischen Systemen auseinanderzusetzen.

Es mag scheinen, dass im Jahr 2019 ein Artikel darüber, welche TSDB man verwenden sollte, nur aus einem Satz bestehen müsste: „Nehmen Sie einfach ClickHouse“. Aber... es gibt Nuancen.

In der Tat entwickelt sich ClickHouse aktiv weiter, die Benutzerbasis wächst, und der Support wird sehr aktiv betrieben, aber sind wir vielleicht in die Falle der öffentlichen Erfolgsstory von ClickHouse geraten, die möglicherweise andere, effektivere oder zuverlässigere Lösungen überstrahlt?

Anfang letzten Jahres haben wir begonnen, unser eigenes Überwachungssystem zu überarbeiten, wobei die Frage aufkam, welche Datenbank zur Datenspeicherung geeignet wäre. Über die Geschichte dieser Entscheidung möchte ich hier berichten.

Aufgabenstellung

Vor allem – eine notwendige Einleitung. Warum benötigen wir überhaupt ein eigenes Überwachungssystem und wie war es aufgebaut?

Wir begannen 2008 mit der Bereitstellung von Supportdiensten, und bis 2010 wurde klar, dass die Aggregation von Daten über die in der Kundeninfrastruktur stattfindenden Prozesse mit den damals verfügbaren Lösungen schwierig wurde (wir sprechen von, Gott sei Dank, Cacti, Zabbix und dem entstehenden Graphite).

Unsere Hauptanforderungen waren:

• die Betreuung von (damals - Dutzenden und perspektivisch - Hunderten) Kunden in einem System und zugleich eine zentrale Alarmverwaltung;
• Flexibilität im Management des Alarmsystems (Esklation von Alarmen zwischen den Wachhabenden, Berücksichtigung von Zeitplänen, Wissensdatenbank);
• die Möglichkeit zur tiefen Detaillierung von Grafiken (Zabbix zeichnete damals Grafiken als Bilder).
• Langfristige Speicherung großer Datenmengen (ein Jahr und mehr) und die Möglichkeit ihrer schnellen Abfrage.

In diesem Artikel interessieren wir uns für den letzten Punkt.

Im Hinblick auf das Speichersystem waren die Anforderungen wie folgt:

• Das System sollte schnell arbeiten;
• Es wäre wünschenswert, wenn das System eine SQL-Schnittstelle hätte;
• Das System sollte stabil sein und über eine aktive Benutzerbasis sowie Unterstützung verfügen (wir hatten einmal die Notwendigkeit, solche Systeme wie MemcacheDB, das nicht mehr weiterentwickelt wurde, oder das verteilte Speicher MooseFS zu unterstützen, dessen Bug-Tracker auf Chinesisch geführt wurde: wir wollten diese Geschichte mit unserem Projekt nicht wiederholen);
• Entsprechung der CAP-Theorie: Consistency (notwendig) – die Daten müssen aktuell sein; wir wollen nicht, dass das Verwaltungssystem für Benachrichtigungen keine neuen Daten erhält und Alerts über den fehlenden Datenempfang zu allen Projekten sendet; Partition Tolerance (notwendig) – wir wollen kein Split-Brain-System; Availability (nicht kritisch, wenn es eine aktive Replica gibt) – wir können im Falle eines Ausfalls selbst auf das Backup-System umschalten, durch Code.

Seltsamerweise stellte sich zu diesem Zeitpunkt MySQL als die ideale Lösung für uns heraus. Unsere Datenstruktur war denkbar einfach: Server-ID, Zähler-ID, Timestamp und Wert; die schnelle Abfrage heißer Daten wurde durch die große Größe des Buffer-Pools gewährleistet, und die Abfrage historischer Daten durch SSD.

So erreichten wir die Abfrage frischer zweiwöchiger Daten mit einer Sekundengenauigkeit innerhalb von 200 ms bis zur vollständigen Darstellung der Daten und lebten lange in diesem System.

Inzwischen verging die Zeit und die Datenmenge wuchs. Bis 2016 erreichten die Datenmengen Hunderte Terabyte, was unter den Bedingungen gemieteter SSD-Speicher erheblichen Kosten verursachte.

Zu diesem Zeitpunkt hatten sich spaltenorientierte Datenbanken stark verbreitet, über die wir intensiv nachdachten: In spaltenorientierten Datenbanken werden die Daten, wie man verstehen kann, spaltenweise gespeichert, und wenn wir uns unsere Daten ansehen, können wir leicht viele Duplikate erkennen, die man durch die Nutzung einer spaltenorientierten Datenbank komprimieren könnte.

Doch das zentrale System des Unternehmens arbeitete weiterhin stabil, und wir wollten nicht mit einem Wechsel zu etwas anderem experimentieren.

Im Jahr 2017 haben die Entwickler von Clickhouse wahrscheinlich zum ersten Mal auf der Percona Live Konferenz in San Jose von sich reden gemacht. Auf den ersten Blick war das System produktionsbereit (nun, Yandex.Metrica ist immerhin eine harte Produktion), und die Unterstützung war schnell und unkompliziert, vor allem war der Betrieb einfach. Ab 2018 haben wir den Übergangsprozess eingeleitet. Doch zu diesem Zeitpunkt gab es bereits viele 'erwachsene' und bewährte TSDB-Systeme, und wir haben entschieden, erhebliche Zeit zu investieren, um Alternativen zu vergleichen, um sicherzugehen, dass es keine alternative Lösung zu Clickhouse gibt, die unseren Anforderungen gerecht wird.

Zusätzlich zu den bereits genannten Anforderungen an das Speicherformat kamen neue hinzu:

• Das neue System muss mindestens die gleiche Leistung wie MySQL auf der gleichen Hardware bieten.
• Der Speicher der neuen Systeme sollte erheblich weniger Platz beanspruchen.
• Die Datenbank muss nach wie vor einfach zu verwalten sein.
• Diese sollte bei einem Wechsel der Datenbank minimal verändert werden müssen.

Welche Systeme haben wir in Betracht gezogen

Apache Hive/Apache Impala
Der alte bewährte Hadoop-Stack. Eigentlich handelt es sich um eine SQL-Schnittstelle, die auf der Datenspeicherung in eigenen Formaten auf HDFS basiert.

Vorteile.

• Bei stabiler Betriebsführung ist es sehr einfach, die Daten zu skalieren.
• Es gibt spaltenbasierte Lösungen zur Datenspeicherung (weniger Platzbedarf).
• Sehr schnelle Ausführung paralleler Aufgaben, wenn genügend Ressourcen vorhanden sind.

Nachteile.

• Es ist Hadoop, und es ist kompliziert in der Handhabung. Wenn wir nicht bereit sind, eine fertige Lösung in der Cloud zu nutzen (und das sind wir wegen der Kosten nicht), muss der gesamte Stack von Administratoren aufgebaut und gewartet werden, was wir wirklich vermeiden möchten.
• Die Daten werden tatsächlich schnell aggregiert..

Allerdings:

Die Geschwindigkeit wird durch die Skalierung der Anzahl der Server erreicht. Einfach gesagt, wenn wir ein großes Unternehmen sind, das sich mit Analytik beschäftigt und es geschäftskritisch ist, Informationen so schnell wie möglich zu aggregieren (selbst wenn dies auf Kosten des Einsatzes zahlreicher Rechenressourcen geht), dann könnte dies unsere Wahl sein. Aber wir waren nicht bereit, den Hardwarepark für eine schnellere Ausführung der Aufgaben erheblich zu vergrößern.

Druid/Pinot

Bereits deutlich mehr über speziell TSDB, jedoch wieder ein Hadoop-Stack.

Ja einen ausgezeichneten Artikel, der die Vor- und Nachteile von Druid und Pinot im Vergleich zu ClickHouse analysiert. .

Kurz gesagt: Druid/Pinot schneiden besser als Clickhouse ab, wenn:

• Sie haben einen heterogenen Datentyp (in unserem Fall zeichnen wir nur Zeitserien von Servermetriken auf, und im Grunde handelt es sich um eine Tabelle. Aber es kann auch andere Fälle geben: Zeitreihen von Geräten, ökonomische Zeitreihen usw. — jede mit ihrer eigenen Struktur, die aggregiert und verarbeitet werden muss).
• Dabei gibt es von diesen Daten sehr viele.
• Tabellen und Daten mit Zeitreihen erscheinen und verschwinden (das heißt, eine bestimmte Datensammlung ist angekommen, wurde analysiert und dann gelöscht).
• Es gibt kein eindeutiges Kriterium, nach dem die Daten partitioniert werden können.

In den gegensätzlichen Fällen schlägt sich ClickHouse besser, und das ist unser Fall.

ClickHouse

• SQL-ähnlich.
• Einfach zu verwalten.
• Die Leute sagen, dass es funktioniert.

Kommt auf die Shortlist für Tests.

InfluxDB

Eine ausländische Alternative zu ClickHouse. Nachteile: Hochverfügbarkeit ist nur in der kommerziellen Version vorhanden, aber das muss verglichen werden.

Kommt auf die Shortlist für Tests.

Cassandra

Einerseits wissen wir, dass es für die Speicherung von metrischen Zeitserien von Überwachungssystemen wie z. B. SignalFX oder OkMeter verwendet wird. Es gibt jedoch Spezifika.

Cassandra ist keine spaltenorientierte Datenbank im herkömmlichen Sinne. Sie sieht eher aus wie eine zeilenorientierte, aber in jeder Zeile kann unterschiedlich viele Spalten vorhanden sein, wodurch eine spaltenorientierte Darstellung leicht organisiert werden kann. In diesem Sinne ist klar, dass man bei einer Begrenzung von 2 Milliarden Spalten bestimmte Daten genau in Spalten speichern kann (zum Beispiel die gleichen Zeitreihen). In MySQL gibt es eine Begrenzung von 4096 Spalten, und es kann leicht zu einem Fehler mit dem Code 1117 kommen, wenn man versucht, dasselbe zu tun.

Die Cassandra-Engine ist auf die Speicherung großer Datenmengen in einem verteilten System ohne Master ausgerichtet. In der oben genannten CAP-Theorie liegt Cassandra stärker im Bereich AP, also Verfügbarkeit von Daten und Widerstandsfähigkeit gegenüber Partitionierungsfehlern. Daher eignet sich dieses Werkzeug hervorragend, wenn es nur darum geht, Daten in diese Datenbank zu schreiben und selten daraus zu lesen. Es ist also sinnvoll, Cassandra als "kalten" Speicher zu verwenden. Das bedeutet, dass es sich um einen langfristigen, zuverlässigen Ort für die Speicherung großer Mengen historischer Daten handelt, die selten benötigt werden, aber bei Bedarf abgerufen werden können. Dennoch wollen wir der Vollständigkeit halber auch diese testen. Aber wie ich bereits erwähnte, besteht kein Wunsch, den Code aktiv für die gewählte Datenbanklösung neu zu schreiben, daher werden wir sie etwas eingeschränkt testen – ohne Anpassung der Datenbankstruktur an die Spezifikationen von Cassandra.

Prometheus

Ja, und aus Interesse haben wir beschlossen, die Leistung des Prometheus-Speichers zu testen – einfach um zu verstehen, ob wir schneller sind als die aktuellen Lösungen oder langsamer und wie stark.

Testmethodik und -ergebnisse

Wir haben 5 Datenbanken in 6 Konfigurationen getestet: ClickHouse (1 Knoten), ClickHouse (verteilte Tabelle auf 3 Knoten), InfluxDB, Mysql 8, Cassandra (3 Knoten) und Prometheus. Der Testplan lautet wie folgt:

1. Wir laden historische Daten für eine Woche hoch (840 Millionen Werte pro Tag; 208.000 Metriken);
2. Wir erzeugen eine Schreiblast (wir betrachteten 6 Lastmodi, siehe unten);
3. Parallel zum Schreiben führen wir regelmäßig Abfragen durch und simulieren Benutzeranfragen, die mit Grafiken arbeiten. Um es nicht zu kompliziert zu machen, wählten wir Daten für 10 Metriken (so viele wie im CPU-Diagramm) über eine Woche aus.

Wir belasten, indem wir das Verhalten unseres Überwachungsagents simulieren, der alle 15 Sekunden Werte in jede Metrik sendet. Dabei interessiert es uns, zu variieren:

• die Gesamtanzahl der Metriken, in die Daten geschrieben werden;
• das Intervall, in dem Werte in eine Metrik gesendet werden;
• die Batch-Größe.

Zur Batch-Größe. Da fast alle unsere Testdatenbanken mit einzelnen Inserts nicht überlastet werden sollten, benötigen wir einen Relayer, der die eingehenden Metriken sammelt und sie gruppiert, um sie in der Datenbank im Batch-Insert zu speichern.

Um besser zu verstehen, wie man die erhaltenen Daten später interpretieren kann, stellen wir uns vor, dass wir nicht einfach eine Menge von Metriken senden, sondern dass die Metriken in Servern organisiert sind – jeweils 125 Metriken pro Server. Hierbei ist der Server einfach eine virtuelle Entität – nur um zu verstehen, dass zum Beispiel 10000 Metriken etwa 80 Server entsprechen.

Und nun, unter Berücksichtigung all dessen, unsere 6 Lastmodi der Datenbank für Schreiboperationen:

Hier gibt es zwei Punkte. Erstens waren für Cassandra solche Batch-Größen zu groß; dort haben wir Werte von 50 oder 100 verwendet. Zweitens, da Prometheus strikt im Pull-Modus arbeitet, d.h. er selbst Daten von den Metrikquellen abruft (und sogar pushgateway, trotz des Namens, ändert die Situation nicht grundlegend), wurden die entsprechenden Lasten mit einer Kombination aus statischen Konfigurationen realisiert.

Die Testergebnisse sind wie folgt:

Was bemerkenswert ist:: fantastischerweise schnelle Abfragen aus Prometheus, erschreckend langsame Abfragen aus Cassandra, unakzeptabel langsame Abfragen aus InfluxDB; hinsichtlich der Schreibgeschwindigkeit hat ClickHouse allen anderen überlegen, während Prometheus nicht am Wettbewerb teilnimmt, da er die Inserts selbst intern vornimmt und wir nichts messen.

Insgesamt: ClickHouse und InfluxDB schnitten am besten ab, aber ein Cluster aus Influx kann nur auf Basis der Enterprise-Version aufgebaut werden, die kostenpflichtig ist, während ClickHouse kostenlos ist und in Russland entwickelt wurde. Logisch, dass in den USA die Wahl wohl zugunsten von InfluxDB fällt, während es bei uns ClickHouse ist.

Quelle: habr.com