In den letzten Jahren haben sich Zeitreihendatenbanken von einer seltsamen Sache (hochspezialisiert entweder in offenen Überwachungssystemen (und an bestimmte Lösungen gebunden) oder in Big-Data-Projekten verwendet) zu einem „Konsumprodukt“ entwickelt. Auf dem Territorium der Russischen Föderation gilt hierfür insbesondere Yandex und ClickHouse. Wenn Sie bis zu diesem Zeitpunkt eine große Menge an Zeitreihendaten speichern mussten, mussten Sie sich entweder damit abfinden, einen riesigen Hadoop-Stack aufzubauen und zu warten, oder mit Protokollen kommunizieren, die für jedes System individuell waren.
Es mag den Anschein haben, dass im Jahr 2019 ein Artikel darüber, welche TSDB es wert ist, verwendet zu werden, nur aus einem Satz besteht: „Verwenden Sie einfach ClickHouse.“ Aber... es gibt Nuancen.
Tatsächlich entwickelt sich ClickHouse aktiv weiter, die Benutzerbasis wächst und der Support ist sehr aktiv, aber sind wir zu Geiseln des öffentlichen Erfolgs von ClickHouse geworden, der andere, vielleicht effektivere/zuverlässigere Lösungen in den Schatten gestellt hat?
Anfang letzten Jahres begannen wir mit der Überarbeitung unseres eigenen Monitoring-Systems, wobei sich die Frage nach der Auswahl einer geeigneten Datenbank zur Datenspeicherung stellte. Ich möchte hier über die Geschichte dieser Wahl sprechen.
Formulierung des Problems
Zunächst einmal ein notwendiges Vorwort. Warum brauchen wir überhaupt ein eigenes Monitoringsystem und wie wurde es konzipiert?
Wir begannen 2008 mit der Bereitstellung von Supportdiensten, und 2010 wurde klar, dass es schwierig wurde, Daten über die in der Client-Infrastruktur ablaufenden Prozesse mit den damals vorhandenen Lösungen zu aggregieren (wir sprechen über, Gott vergib mir, Cacti, Zabbix). und das aufkommende Graphit).
Unsere Hauptanforderungen waren:
- Unterstützung (damals Dutzende und in Zukunft Hunderte) von Clients innerhalb eines Systems und gleichzeitig das Vorhandensein eines zentralen Alarmmanagementsystems;
- Flexibilität bei der Verwaltung des Alarmsystems (Eskalation von Alarmen zwischen diensthabenden Beamten, Terminplanung, Wissensdatenbank);
- die Fähigkeit, Diagramme detailliert darzustellen (Zabbix stellte Diagramme damals in Form von Bildern dar);
- Langzeitspeicherung einer großen Datenmenge (ein Jahr oder länger) und die Möglichkeit, diese schnell abzurufen.
In diesem Artikel interessiert uns der letzte Punkt.
Apropos Lagerung: Die Anforderungen waren wie folgt:
- das System muss schnell arbeiten;
- es ist wünschenswert, dass das System über eine SQL-Schnittstelle verfügt;
- Das System muss stabil sein und über eine aktive Benutzerbasis und Support verfügen (einmal standen wir vor der Notwendigkeit, Systeme wie MemcacheDB zu unterstützen, das nicht mehr entwickelt wurde, oder den verteilten Speicher MooseFS, dessen Bugtracker auf Chinesisch gehalten wurde: wir wollten diese Geschichte für unser Projekt nicht wiederholen);
- Einhaltung des CAP-Theorems: Konsistenz (erforderlich) – die Daten müssen aktuell sein, wir möchten nicht, dass das Alarmverwaltungssystem keine neuen Daten empfängt und Warnungen über das Nichteintreffen von Daten für alle Projekte ausspuckt; Partitionstoleranz (erforderlich) – wir möchten kein Split-Brain-System erhalten; Verfügbarkeit (nicht kritisch, wenn eine aktive Replik vorhanden ist) – wir können im Falle eines Unfalls mithilfe von Code selbst auf das Backup-System umschalten.
Kurioserweise erwies sich MySQL damals als die ideale Lösung für uns. Unsere Datenstruktur war äußerst einfach: Server-ID, Zähler-ID, Zeitstempel und Wert; Die schnelle Erfassung aktueller Daten wurde durch einen großen Pufferpool sichergestellt, und die Erfassung historischer Daten wurde durch SSD sichergestellt.
So erhielten wir eine Stichprobe frischer zweiwöchiger Daten mit Details bis zu einer Sekunde, 200 ms bevor die Daten vollständig gerendert wurden, und lebten ziemlich lange in diesem System.
Mittlerweile verging die Zeit und die Datenmenge wuchs. Bis 2016 erreichten die Datenmengen Dutzende Terabyte, was im Zusammenhang mit gemietetem SSD-Speicher einen erheblichen Aufwand darstellte.
Zu diesem Zeitpunkt hatten spaltenbasierte Datenbanken eine aktive Verbreitung gefunden, worüber wir aktiv nachzudenken begannen: In spaltenbasierten Datenbanken werden Daten, wie Sie verstehen können, in Spalten gespeichert, und wenn man sich unsere Daten ansieht, ist es leicht, eine große Größe zu erkennen Anzahl der Duplikate, die in Wenn Sie eine spaltenbasierte Datenbank verwenden, komprimieren Sie diese mithilfe der Komprimierung.
Das Schlüsselsystem des Unternehmens funktionierte jedoch weiterhin stabil und ich wollte nicht mit der Umstellung auf etwas anderes experimentieren.
2017, auf der Percona Live-Konferenz in San Jose, haben sich Clickhouse-Entwickler vermutlich zum ersten Mal angekündigt. Auf den ersten Blick war das System produktionsbereit (naja, Yandex.Metrica ist ein anspruchsvolles Produktionssystem), der Support war schnell und einfach und, was am wichtigsten ist, die Bedienung war einfach. Seit 2018 haben wir mit dem Übergangsprozess begonnen. Zu diesem Zeitpunkt gab es jedoch viele „erwachsene“ und bewährte TSDB-Systeme, und wir beschlossen, viel Zeit zu investieren und Alternativen zu vergleichen, um sicherzustellen, dass es gemäß unseren Anforderungen keine alternativen Lösungen zu Clickhouse gab.
Zusätzlich zu den bereits genannten Speicheranforderungen sind neue hinzugekommen:
- Das neue System sollte auf der gleichen Menge an Hardware mindestens die gleiche Leistung wie MySQL bieten.
- die Lagerung des neuen Systems soll deutlich weniger Platz beanspruchen;
- Das DBMS muss dennoch einfach zu verwalten sein;
- Ich wollte die Anwendung beim Wechsel des DBMS nur minimal ändern.
Über welche Systeme begannen wir nachzudenken?
Apache Hive/Apache Impala
Ein alter, kampferprobter Hadoop-Stack. Im Wesentlichen handelt es sich um eine SQL-Schnittstelle, die auf der Speicherung von Daten in nativen Formaten auf HDFS aufbaut.
Pros.
- Bei stabilem Betrieb ist es sehr einfach, Daten zu skalieren.
- Zur Datenspeicherung (geringerer Platzbedarf) gibt es Säulenlösungen.
- Sehr schnelle Ausführung paralleler Aufgaben, wenn Ressourcen verfügbar sind.
Nachteile
- Es ist Hadoop und es ist schwierig zu verwenden. Wenn wir nicht bereit sind, eine fertige Lösung in der Cloud zu nutzen (und wir sind auch aus Kostengründen nicht bereit), muss der gesamte Stack von Administratoren zusammengestellt und unterstützt werden, und das wollen wir wirklich nicht Das.
- Die Daten werden aggregiert .
Aber:
Geschwindigkeit wird durch die Skalierung der Anzahl der Rechenserver erreicht. Einfach ausgedrückt: Wenn wir ein großes Unternehmen sind, das sich mit Analysen beschäftigt und es für das Unternehmen von entscheidender Bedeutung ist, Informationen so schnell wie möglich zu aggregieren (auch um den Preis einer großen Menge an Rechenressourcen), könnte dies unsere Wahl sein. Aber wir waren nicht bereit, die Hardwareflotte zu vervielfachen, um Aufgaben zu beschleunigen.
Druide/Pinot
Es gibt noch viel mehr speziell zu TSDB, aber auch hier zum Hadoop-Stack.
Es gibt .
In wenigen Worten: Druid/Pinot sehen in folgenden Fällen besser aus als Clickhouse:
- Sie haben eine heterogene Datenbeschaffenheit (in unserem Fall zeichnen wir nur Zeitreihen von Servermetriken auf, und tatsächlich ist dies eine Tabelle. Aber es kann auch andere Fälle geben: Gerätezeitreihen, Wirtschaftszeitreihen usw. – jeweils mit eine eigene Struktur, die aggregiert und verarbeitet werden muss).
- Darüber hinaus gibt es viele dieser Daten.
- Tabellen und Daten mit Zeitreihen erscheinen und verschwinden (das heißt, ein Datensatz ist angekommen, wurde analysiert und gelöscht).
- Es gibt kein klares Kriterium, nach dem Daten partitioniert werden können.
Im umgekehrten Fall schneidet ClickHouse besser ab, und das ist unser Fall.
Clickhouse
- SQL-ähnlich
- Einfach zu verwalten.
- Die Leute sagen, es funktioniert.
Wird zum Testen in die engere Auswahl genommen.
InfluxDB
Eine ausländische Alternative zu ClickHouse. Von den Minuspunkten: Hochverfügbarkeit ist nur in der kommerziellen Version vorhanden, muss aber verglichen werden.
Wird zum Testen in die engere Auswahl genommen.
Kassandra
Einerseits wissen wir, dass es zur Speicherung metrischer Zeitreihen von Überwachungssystemen wie z. B. oder OkMeter. Es gibt jedoch Besonderheiten.
Cassandra ist keine spaltenbasierte Datenbank im herkömmlichen Sinne. Es sieht eher aus wie eine Zeilenansicht, aber jede Zeile kann eine unterschiedliche Anzahl von Spalten haben, was die Organisation einer Spaltenansicht erleichtert. In diesem Sinne ist es klar, dass es bei einer Begrenzung von 2 Milliarden Spalten möglich ist, einige Daten in Spalten (und derselben Zeitreihe) zu speichern. Beispielsweise gibt es in MySQL eine Beschränkung auf 4096 Spalten und es kann leicht passieren, dass beim Versuch, dasselbe zu tun, ein Fehler mit Code 1117 auftritt.
Die Cassandra-Engine konzentriert sich auf die Speicherung großer Datenmengen in einem verteilten System ohne Master, und beim oben erwähnten Cassandra-CAP-Theorem geht es eher um AP, also um die Datenverfügbarkeit und den Widerstand gegen Partitionierung. Daher kann dieses Tool großartig sein, wenn Sie nur in diese Datenbank schreiben und selten daraus lesen müssen. Und hier ist es logisch, Cassandra als „kalten“ Speicher zu verwenden. Das heißt, es handelt sich um einen langfristigen, zuverlässigen Ort zum Speichern großer Mengen historischer Daten, die selten benötigt werden, aber bei Bedarf abgerufen werden können. Der Vollständigkeit halber werden wir es dennoch auch testen. Aber wie ich bereits sagte, besteht kein Wunsch, den Code für die ausgewählte Datenbanklösung aktiv neu zu schreiben, daher werden wir ihn etwas eingeschränkt testen – ohne die Datenbankstruktur an die Besonderheiten von Cassandra anzupassen.
Prometheus
Nun, aus Neugier haben wir beschlossen, die Leistung des Prometheus-Speichers zu testen – nur um zu verstehen, ob wir schneller als aktuelle Lösungen oder langsamer sind und um wie viel.
Testmethodik und Ergebnisse
Daher haben wir 5 Datenbanken in den folgenden 6 Konfigurationen getestet: ClickHouse (1 Knoten), ClickHouse (verteilte Tabelle für 3 Knoten), InfluxDB, Mysql 8, Cassandra (3 Knoten) und Prometheus. Der Testplan sieht wie folgt aus:
- historische Daten für eine Woche hochladen (840 Millionen Werte pro Tag; 208 Metriken);
- wir erzeugen eine Aufnahmelast (6 Lademodi wurden berücksichtigt, siehe unten);
- Parallel zur Aufzeichnung treffen wir regelmäßig Auswahlen und emulieren dabei die Anforderungen eines Benutzers, der mit Diagrammen arbeitet. Um die Sache nicht zu sehr zu verkomplizieren, haben wir eine Woche lang Daten für 10 Metriken (genau so viele gibt es im CPU-Diagramm) ausgewählt.
Wir laden, indem wir das Verhalten unseres Überwachungsagenten emulieren, der alle 15 Sekunden Werte an jede Metrik sendet. Gleichzeitig sind wir daran interessiert, Folgendes zu variieren:
- die Gesamtzahl der Metriken, in die Daten geschrieben werden;
- Intervall zum Senden von Werten an eine Metrik;
- Chargengröße.
Über die Chargengröße. Da es nicht empfehlenswert ist, fast alle unserer experimentellen Datenbanken mit einzelnen Einfügungen zu laden, benötigen wir ein Relay, das eingehende Metriken sammelt, sie in Gruppen gruppiert und als Batch-Einfügungen in die Datenbank schreibt.
Um besser zu verstehen, wie die empfangenen Daten dann interpretiert werden sollen, stellen wir uns außerdem vor, dass wir nicht nur eine Reihe von Metriken senden, sondern die Metriken auf Servern organisiert sind – 125 Metriken pro Server. Hier ist der Server einfach eine virtuelle Einheit – nur um zu verstehen, dass beispielsweise 10000 Metriken etwa 80 Servern entsprechen.
Und hier sind unter Berücksichtigung all dessen unsere 6 Datenbank-Schreiblademodi:
Hier gibt es zwei Punkte. Erstens erwiesen sich diese Batch-Größen für Cassandra als zu groß, dort haben wir Werte von 50 oder 100 verwendet. Und zweitens, da Prometheus ausschließlich im Pull-Modus arbeitet, also Es selbst sammelt Daten aus Metrikquellen (und selbst Pushgateway ändert die Situation trotz des Namens nicht grundlegend). Die entsprechenden Lasten wurden mithilfe einer Kombination statischer Konfigurationen implementiert.
Die Testergebnisse sind wie folgt:
Was ist erwähnenswert: fantastisch schnelle Samples von Prometheus, furchtbar langsame Samples von Cassandra, unannehmbar langsame Samples von InfluxDB; Was die Aufnahmegeschwindigkeit angeht, hat ClickHouse alle gewonnen, und Prometheus nimmt nicht am Wettbewerb teil, da es selbst Einfügungen erstellt und wir nichts messen.
Infolgedessen: ClickHouse und InfluxDB haben sich als die Besten erwiesen, aber ein Cluster von Influx kann nur auf Basis der Enterprise-Version aufgebaut werden, die Geld kostet, während ClickHouse nichts kostet und in Russland hergestellt wird. Es ist logisch, dass in den USA die Wahl wahrscheinlich auf inInfluxDB und in unserem Land auf ClickHouse fällt.
Source: habr.com