Wie wir mehrere Zeitreihendatenbanken getestet haben

In den letzten Jahren haben sich Zeitreihendatenbanken (Time-series databases) von einer Kuriosität, die entweder in speziellen Monitoringsystemen (und an bestimmte Lösungen gebunden) oder in Big-Data-Projekten verwendet wurde, zu einem 'Alltagsprodukt' entwickelt. In Russland gebührt diesem Trend ein besonderer Dank an Yandex und ClickHouse. Bis zu diesem Zeitpunkt mussten Sie, wenn Sie eine große Menge an Zeitreihendaten speichern wollten, entweder die Mühe auf sich nehmen, einen monströsen Hadoop-Stack zu implementieren und zu verwalten, oder sich mit protokollspezifischen Lösungen für jedes System auseinandersetzen.

Es mag so erscheinen, als ob im Jahr 2019 der Artikel darüber, welche TSDB zu verwenden ist, nur aus einem Satz bestehen würde: 'Nutzen Sie einfach ClickHouse.' Aber… es gibt Nuancen.

In der Tat entwickelt sich ClickHouse aktiv weiter, die Nutzerbasis wächst, und die Unterstützung wird sehr intensiv gepflegt, aber sind wir nicht vielleicht Gefangene des öffentlichen Erfolgs von ClickHouse geworden, der möglicherweise andere, effektivere oder zuverlässigere Lösungen überschattet?

Zu Beginn des vergangenen Jahres haben wir unser eigenes Monitoring-System überarbeitet, wobei die Wahl einer geeigneten Datenbank zur Speicherung der Daten in den Fokus rückte. Über die Geschichte dieser Wahl möchte ich hier berichten.

Problemstellung

Zunächst ein notwendiges Vorwort: Warum benötigen wir überhaupt ein eigenes Monitoring-System und wie war es aufgebaut?

Wir begannen 2008 mit der Bereitstellung von Support-Dienstleistungen, und bis 2010 wurde klar, dass es schwierig wurde, die Daten über die Abläufe in der Kundeninfrastruktur mit den damaligen Lösungen zu aggregieren (wir sprechen hier über, entschuldigung, Cacti, Zabbix und das aufkommende Graphite).

Unsere Hauptanforderungen waren:

• Die Betreuung einer (zu diesem Zeitpunkt – Dutzenden, und perspektivisch – Hunderten) von Kunden in einem einzigen System und gleichzeitig eine zentralisierte Verwaltung der Benachrichtigungen;
• Flexibilität im Management des Benachrichtigungssystems (Eskalation von Benachrichtigungen zwischen den diensthabenden Mitarbeitern, Berücksichtigung von Zeitplänen, Wissensdatenbank);
• Die Möglichkeit zur tiefen Detaillierung von Grafiken (Zabbix zeichnete damals Grafiken als Bilder auf);
• langfristige Speicherung großer Datenmengen (Jahr und mehr) und die Möglichkeit einer schnellen Abfrage.

In diesem Artikel interessiert uns der letzte Punkt.

Wenn wir über Speicher sprechen, waren die Anforderungen wie folgt:

• das System sollte schnell arbeiten;
• es wäre wünschenswert, dass das System eine SQL-Schnittstelle hat;
• das System muss stabil sein und eine aktive Benutzerbasis sowie Unterstützung haben (wir hatten einmal die Notwendigkeit, solche Systeme zu unterstützen, wie zum Beispiel MemcacheDB, das nicht mehr weiterentwickelt wurde, oder das verteilte Speicher MooseFS, dessen Bugtracker auf Chinesisch geführt wurde: eine Wiederholung dieser Geschichte für unser Projekt wollten wir vermeiden);
• Einhaltung des CAP-Theorems: Consistency (notwendig) – die Daten müssen aktuell sein, wir wollen nicht, dass das Managementsystem für Benachrichtigungen keine neuen Daten erhält und uns mit Alerts über fehlende Daten in allen Projekten belästigt; Partition Tolerance (notwendig) – wir wollen kein Split-Brain-System erhalten; Availability (nicht kritisch, falls eine aktive Kopie existiert) – wir können selbst auf das Backup-System im Falle eines Ausfalls umschalten, durch Code.

Seltsamerweise stellte sich zu diesem Zeitpunkt MySQL als die ideale Lösung für uns heraus. Unsere Datenstruktur war äußerst einfach: Server-ID, Zähler-ID, Zeitstempel und Wert; Die schnelle Abfrage aktueller Daten wurde durch die große Größe des Buffer-Pools gewährleistet, während historische Daten auf SSDs abgerufen wurden.

So gelang es uns, frische Daten der letzten zwei Wochen mit einer Genauigkeit von bis zu einer Sekunde in 200 ms vor der vollständigen Datenanzeige abzurufen, und wir lebten ziemlich lange mit diesem System.

Inzwischen verging die Zeit und die Datenmenge wuchs. Bis 2016 erreichte das Datenvolumen mehrere Dutzend Terabyte, was bei gemieteten SSD-Speichern eine erhebliche Kostenbelastung darstellte.

Zu diesem Zeitpunkt hatten spaltenbasierte Datenbanken, über die wir intensiv nachdachten, an Popularität gewonnen: In spaltenbasierten DBs werden die Daten, wie man verstehen kann, spaltenweise gespeichert, und wenn man sich unsere Daten ansieht, erkennt man leicht eine große Anzahl von Duplikaten, die man bei Verwendung einer spaltenbasierten DB durch Komprimierung reduzieren könnte.

Doch das zentrale System des Unternehmens arbeitete weiterhin stabil, und es war nicht gewünscht, mit einem Wechsel zu etwas anderem zu experimentieren.

Im Jahr 2017 stellten sich die Entwickler von Clickhouse auf der Percona Live Konferenz in San Jose wahrscheinlich zum ersten Mal vor. Auf den ersten Blick war das System produktionsreif (Yandex.Metrica ist schließlich ein harter Produktionsfall), die Unterstützung war schnell und unkompliziert, und vor allem war die Bedienung einfach. Ab 2018 begannen wir mit dem Übergangsprozess. Zu diesem Zeitpunkt gab es jedoch bereits zahlreiche „reife“ und bewährte TSDB-Systeme, und wir entschieden uns, erhebliche Zeit zu investieren, um Alternativen zu vergleichen und sicherzustellen, dass es laut unseren Anforderungen keine konkurrenten Lösungen zu Clickhouse gibt.

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

• Das neue System sollte mindestens die gleiche Leistung wie MySQL mit der gleichen Hardware bieten;
• Der Speicher des neuen Systems sollte erheblich weniger Platz beanspruchen;
• Die Datenbank sollte weiterhin einfach zu verwalten sein;
• Das bestehende Anwendung sollte minimal bei der Änderung der Datenbank geändert werden müssen.

Welche Systeme haben wir in Betracht gezogen

Apache Hive/Apache Impala
Ein bewährter Hadoop-Stack. Es handelt sich im Wesentlichen um eine SQL-Schnittstelle, die über Datenspeicher in eigenen Formaten auf HDFS aufgebaut ist.

Vorteile.

• Bei stabiler Nutzung ist es sehr einfach, Daten zu skalieren.
• Es gibt spaltenbasierte Lösungen zur Datenspeicherung (weniger Platz).
• Sehr schnelle Ausführung paralleler Aufgaben bei vorhandenen Ressourcen.

Nachteile.

• Das ist Hadoop, und es ist kompliziert in der Nutzung. Wenn wir nicht bereit sind, eine fertige Lösung in der Cloud zu nutzen (was wir aus Kostengründen nicht sind), muss der gesamte Stack von Administratoren manuell erstellt und unterstützt werden, und das möchten wir wirklich vermeiden.
• Daten werden aggregiert tatsächlich schnell.

Jedoch:

Die Geschwindigkeit wird durch die Skalierung der Anzahl der Rechnerserver erreicht. Einfacher gesagt, wenn wir ein großes Unternehmen sind, das Analysen durchführt, und es für das Geschäft kritisch wichtig ist, Informationen so schnell wie möglich zu aggregieren (auch wenn das den Einsatz vieler Rechenressourcen bedeutet) – könnte das unsere Wahl sein. Aber wir waren nicht bereit, den Hardwarepark drastisch zu vergrößern, um die Geschwindigkeit der Aufgabenbearbeitung zu erhöhen.

Druid/Pinot

Bereits wesentlich mehr über spezifisch TSDB, aber wiederum – Hadoop-Stack.

Es gibt ein hervorragender Artikel, der die Vor- und Nachteile von Druid und Pinot im Vergleich zu ClickHouse vergleicht. .

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

• Sie haben einen heterogenen Datentyp (in unserem Fall erfassen wir nur Zeitreihen von Servermetriken, was im Wesentlichen eine Tabelle ist. Es können jedoch auch andere Fälle auftreten: Zeitreihen zu Geräten, wirtschaftliche Zeitreihen usw. — jede mit ihrer eigenen Struktur, die aggregiert und verarbeitet werden muss).
• Diese Datenmenge ist jedoch sehr groß.
• Tabellen und Daten mit Zeitreihen erscheinen und verschwinden (das heißt, ein bestimmter Datensatz kommt an, wird analysiert und dann gelöscht).
• Es gibt keine klaren Kriterien, nach denen Daten partitioniert werden können.

In den entgegengesetzten Fällen schneidet ClickHouse jedoch besser ab, und das ist unser Fall.

ClickHouse

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

Es 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.

Es kommt auf die Shortlist für Tests.

Cassandra,

Einerseits wissen wir, dass Systeme zur Überwachung von Metrikzeitreihen wie beispielsweise SignalFX oder OkMeter es verwenden. Es gibt jedoch spezifische Anforderungen.

Cassandra ist keine spaltenorientierte Datenbank im gewohnten Sinne. Sie ähnelt eher einer zeilenorientierten Datenbank, ermöglicht jedoch eine unterschiedliche Anzahl von Spalten pro Zeile, wodurch eine spaltenbasierte Darstellung leicht realisierbar ist. In diesem Sinne ist es nachvollziehbar, dass bei einer Begrenzung von 2 Milliarden Spalten Daten genau in diesen Spalten gespeichert werden können (wie zum Beispiel bei Zeitreihen). Zum Vergleich: In MySQL gibt es eine Begrenzung von 4096 Spalten, und man kann schnell auf den Fehlercode 1117 stoßen, wenn man versucht, das Gleiche zu tun.

Die Cassandra-Datenbank ist auf die Speicherung großer Datenmengen in einem verteilten System ohne Master ausgerichtet. Laut der erwähnten CAP-Theorie liegt der Schwerpunkt von Cassandra mehr auf AP, also auf der Datenverfügbarkeit und der Widerstandsfähigkeit gegen Partitionstrennung. Daher eignet sich dieses Tool hervorragend, wenn hauptsächlich in diese Datenbank geschrieben und nur selten darauf zugegriffen wird. In diesem Zusammenhang ist es sinnvoll, Cassandra als 'kaltes' Speicherformat zu nutzen, also als langfristigen, zuverlässigen Speicherort für große Mengen historischer Daten, 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ähnt habe, besteht kein Interesse daran, den Code aktiv an die gewählte Datenbanklösung anzupassen, daher werden wir die Tests etwas eingeschränkt durchführen – ohne Anpassung der Datenbankstruktur an die Spezifikationen von Cassandra.

Prometheus

Und aus reinem Interesse haben wir beschlossen, die Leistung des Prometheus-Speicherorts zu testen – einfach um zu verstehen, ob wir schneller oder langsamer sind als die aktuellen Lösungen und in welchem Maß.

Testmethodik und Ergebnisse

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

1. Wir laden historische Daten für eine Woche hoch (840 Millionen Werte pro Tag; 208.000 Metriken);
2. Wir erzeugen Schreiblast (wir betrachteten 6 Lastarten, siehe unten);
3. Parallel zur Schreiblast machen wir von Zeit zu Zeit Abfragen, um Benutzeranfragen, die mit Grafiken arbeiten, zu simulieren. Um es nicht zu kompliziert zu machen, wählten wir Daten für 10 Metriken aus (genau so viele wie auf dem CPU-Diagramm) für eine Woche.

Wir belasten das System, indem wir das Verhalten unseres Monitoring-Agenten emulieren, der alle 15 Sekunden Werte für jede Metrik sendet. Dabei interessieren uns folgende Variablen:

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

Zur Batch-Größe: Da fast alle unsere Testdatenbanken nicht mit Einzel-Insertions belastet werden sollten, benötigen wir einen Relay, der die ankommenden Metriken sammelt und sie bündelt, um sie in der Datenbank per Batch-Insert zu schreiben.

Um besser zu verstehen, wie die erhaltenen Daten später interpretiert werden können, 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 nur eine virtuelle Entität – lediglich um zu verstehen, dass beispielsweise 10.000 Metriken etwa 80 Server entsprechen.

Unter Berücksichtigung all dessen, hier unsere 6 Lastmodi für die Schreibdatenbank:

Es gibt hier zwei Punkte. Erstens waren diese Batch-Größen für Cassandra zu groß, dort haben wir Werte von 50 oder 100 verwendet. Zweitens arbeitet Prometheus strikt im Pull-Modus, d.h. er holt selbst die Daten von den Metrikquellen ab (und sogar der Pushgateway ändert die Situation nicht grundlegend, trotz seines Namens). Entsprechende Lasten wurden durch eine Kombination von statischen Konfigurationen realisiert.

Die Testergebnisse sind wie folgt:

Was zu beachten ist: fantastisches schnelles Abfragen von Prometheus, schrecklich langsames Abfragen von Cassandra, inakzeptabel langsames Abfragen von InfluxDB; bei der Schreibgeschwindigkeit hat ClickHouse eindeutig gewonnen, und Prometheus nimmt nicht am Wettbewerb teil, da er die Inserts selbst intern vornimmt und wir nichts messen.

Insgesamt: ClickHouse und InfluxDB haben sich am besten bewährt, jedoch kann ein Cluster aus InfluxDB nur auf Basis der kostenpflichtigen Enterprise-Version aufgebaut werden, während ClickHouse kostenlos ist und in Russland entwickelt wurde. Verständlich, dass in den USA die Wahl wahrscheinlich auf InfluxDB fällt, während wir hier ClickHouse bevorzugen.

Quelle: habr.com