InfluxDB CEO und Entwickler hier. Die nächste Version von InfluxDB (0.9.5) wird unsere neue Speicher-Engine haben. Mit dieser Engine können wir entweder einzelne Ereignisdaten oder regelmäßig gesampelte Serien effizient speichern. d.h. unregelmäßige und regelmäßige Zeitreihen.
InfluxDB unterstützt die Datentypen int64, float64, bool und string, die jeweils unterschiedliche Komprimierungsschemata verwenden. Prometheus unterstützt nur float64.
Für die Komprimierung wird die Version 0.9.5 eine Komprimierung mit Prometheus aufweisen. In einigen Fällen sehen wir bessere Ergebnisse, da wir die Komprimierung von Zeitstempeln basierend auf dem, was wir sehen, variieren. Im besten Fall handelt es sich um eine regelmäßige Serie in exakten Intervallen. In diesen können wir standardmäßig 1k-Punkte-Zeitstempel als 8-Byte-Startzeit, ein Delta (Zick-Zack-codiert) und eine Zählung (auch Zick-Zack-kodiert) komprimieren.
Abhängig von der Form der Daten, die wir gesehen haben < 2,5 Bytes pro Punkt im Durchschnitt nach Kompaktierungen.
YMMV basierend auf Ihren Zeitstempeln, dem Datentyp und der Form der Daten. Zufällige Floats mit Zeitstempeln im Nanosekundenbereich mit großen variablen Deltas wären zum Beispiel die schlechtesten.
Die variable Genauigkeit in Zeitstempeln ist ein weiteres Merkmal, das InfluxDB hat. Sie kann Skalierungszeiten von Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden darstellen. Prometheus ist auf Millisekunden festgelegt.
Ein weiterer Unterschied ist, dass Schreibvorgänge in InfluxDB dauerhaft sind, nachdem eine Erfolgsantwort an den Client gesendet wurde. Prometheus puffert Schreibvorgänge im Speicher und löscht sie standardmäßig alle 5 Minuten, wodurch ein Fenster mit potenziellem Datenverlust geöffnet wird.
Unsere Hoffnung ist, dass, sobald 0.9.5 von InfluxDB veröffentlicht wird, es eine gute Wahl für Prometheus-Benutzer sein wird, als Langzeitmetrik-Speicher (in Verbindung mit Prometheus) zu verwenden. Ich bin mir ziemlich sicher, dass die Unterstützung bereits in Prometheus ist, aber bis die Version 0.9.5 abstürzt, könnte es ein bisschen steinig sein. Natürlich müssen wir zusammenarbeiten und einige Tests durchführen, aber darauf hoffe ich.
Für die Aufnahme von Einzelserver-Metriken würde ich erwarten, dass Prometheus eine bessere Leistung hat (obwohl wir hier keine Tests durchgeführt haben und keine Zahlen haben), da sie keine Schreibvorgänge auf die Festplatte anhängen den Index ausschreiben.
Die Abfragesprache zwischen den beiden ist sehr unterschiedlich. Ich bin mir nicht sicher, was sie unterstützen, was wir noch nicht tun, oder umgekehrt, also müssten Sie in die Dokumente auf beiden graben, um zu sehen, ob es etwas gibt, was Sie tun können, das Sie brauchen. Längerfristig ist es unser Ziel, dass die Suchfunktion von InfluxDB eine Obermenge von Graphite, RRD, Prometheus und anderen Zeitreihenlösungen sein wird. Ich sage Superset, weil wir diese später zusätzlich zu analytischen Funktionen abdecken wollen. Es wird offensichtlich Zeit brauchen, um dorthin zu gelangen.
Schließlich ist ein langfristiges Ziel für InfluxDB die Unterstützung von hoher Verfügbarkeit und horizontaler Skalierbarkeit durch Clustering. Die aktuelle Clusterimplementierung ist noch nicht vollständig und nur in Alpha verfügbar. Wir arbeiten jedoch daran und es ist ein zentrales Designziel für das Projekt. Unser Clustering-Design besteht darin, dass die Daten letztendlich konsistent sind.
Nach meinem Wissen verwendet Prometheus Double-Writes für HA (daher gibt es keine Konsistenzgarantie) und Federation für horizontale Skalierbarkeit. Ich bin mir nicht sicher, wie die Abfrage über föderierte Server funktionieren würde.
Innerhalb eines InfluxDB-Clusters können Sie die Servergrenzen abfragen, ohne alle Daten über das Netzwerk zu kopieren. Das liegt daran, dass jede Abfrage in eine Art MapReduce-Job zerlegt wird, der im laufenden Betrieb ausgeführt wird.
Es gibt wahrscheinlich mehr, aber das ist, was ich im Moment denken kann.
Prometheus Entwickler hier. Paul hat Recht, dass Prometheus immer float-only ist und bleibt (Strings sind nur begrenzt über Labels möglich), während InfluxDB viele Datentypen unterstützt. Ich würde annehmen, dass die Abfragesprachen in der Praxis ziemlich ähnlich sind (Prometheus ist Turing Complete). Unser HA-Ansatz besteht darin, redundante Server zu isolieren, der Alertmanager dedutiert Alerts von ihnen. Wir verwenden im Allgemeinen einen AP-Ansatz für das Monitoring und nicht für den CP, da es besser ist, ein wenig Daten zu verlieren, als wenn Ihr Monitoring untergeht. Prometheus möchte ein System sein, auf das Sie sich im Notfall verlassen können. –
Das InfluxDB-Clustering-Design ist auch weitgehend AP, aber es soll schließlich konsistent sein. Das erreichen wir durch Hinted Handoff (verfügbar in der aktuellen Version) und Active Anti-Entroy (die wir in der 0.9 starten.6 Freigabezyklus). Offensichtlich sind wir noch nicht fertig mit dem Clustering, aber das ist das Designziel. Mehr Details hier: https://influxdb.com/blog/2015/06/03/InfluxDB_clustering_design.html –
Ein anderer Prometheus Entwickler hier. Yep, Prometheus selbst zielt nicht darauf ab, ein dauerhafter Langzeitspeicher zu sein. Aber auf andere Weise ist sein Umfang größer und mehr über aktive Systeme und Service-Überwachung: von Client-Bibliotheken (die nicht nur einige Metriken ausgeben, sondern auch Metriken wie Zähler, Messgeräte, Histogramme und Zusammenfassungen verwalten). , über aktive Zielerkennung/Datenerfassung, Dashboarding, bis hin zur Alarmberechnung und Benachrichtigung. Die Abfragesprache ist ebenfalls nicht SQL-ähnlich, funktioniert aber sehr gut für Berechnungen von dimensionalen Zeitreihendaten. – Julius