Ich erstelle ein System, das Geräte mit (wahrscheinlich) 5-Minuten-Intervallen mithilfe von SNMP nach Daten zu unterschiedlichen Metriken wie CPU-Auslastung, Festplattenauslastung, Temperatur usw. abfragt. Das ultimative Ziel besteht darin, einem Benutzer des Systems Visualisierungen in Form von Zeitreihendiagrammen bereitzustellen.

Ich habe in der Vergangenheit die Verwendung von RRDTool in Betracht gezogen, es jedoch abgelehnt, da das unbegrenzte Speichern der erfassten Daten für mein Projekt wichtig ist. Ich möchte einen höheren und flexibleren Zugriff auf die erfassten Daten. Meine Frage lautet also wirklich:

Was ist besser, eine relationale Datenbank (wie MySQL oder PostgreSQL) oder eine nicht relationale oder NoSQL-Datenbank (wie MongoDB oder Redis) in Bezug auf die Leistung bei der Abfrage von Daten für die grafische Darstellung.

Relational

Bei einer relationalen Datenbank würde ich eine data_instancesTabelle verwenden, in der jede Instanz von Daten gespeichert wird, die für jede Metrik erfasst wurden, die für alle Geräte gemessen wird, mit den folgenden Feldern:

Felder: id fk_to_device fk_to_metric metric_value timestamp

Wenn ich ein Diagramm für eine bestimmte Metrik auf einem bestimmten Gerät zeichnen möchte, muss ich diese einzelne Tabelle abfragen , um die anderen Geräte und die anderen für dieses Gerät analysierten Metriken herauszufiltern :

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

Die Anzahl der Zeilen in dieser Tabelle wäre:

d * m_d * f * t

wobei ddie Anzahl von IS - Geräte , m_dist die akkumulative Zahl der Messwerte für alle Geräte aufgezeichnet werden, fist die Frequenz , mit der Daten für die abgefragt wird , und tist die Gesamtmenge an Zeit , das System das Sammeln von Daten ist.

Für einen Benutzer, der ein Jahr lang alle 5 Minuten 10 Metriken für 3 Geräte aufzeichnet , hätten wir knapp 5 Millionen Datensätze.

Indizes

Ohne Indexe fk_to_deviceund fk_to_metricScannen würde diese ständig wachsende Tabelle zu viel Zeit in Anspruch nehmen. Daher ist die Indizierung der oben genannten Felder und auch timestamp(zum Erstellen von Diagrammen mit lokalisierten Zeiträumen) eine Voraussetzung.

Nicht relational (NoSQL)

MongoDB hat das Konzept einer Sammlung , im Gegensatz zu Tabellen können diese ohne Setup programmgesteuert erstellt werden. Mit diesen konnte ich die Speicherung von Daten für jedes Gerät oder sogar jede für jedes Gerät aufgezeichnete Metrik partitionieren.

Ich habe keine Erfahrung mit NoSQL und weiß nicht, ob sie Funktionen zur Verbesserung der Abfrageleistung wie die Indizierung bieten. Im vorherigen Absatz wird jedoch vorgeschlagen, den größten Teil der traditionellen relationalen Abfragearbeit in der Struktur auszuführen, in der die Daten unter NoSQL gespeichert werden.

Unentschieden

Würde sich eine relationale Lösung mit korrekter Indizierung innerhalb eines Jahres auf einen Crawl reduzieren? Oder bietet die sammlungsbasierte Struktur von NoSQL-Ansätzen (die meinem mentalen Modell der gespeicherten Daten entspricht) einen spürbaren Vorteil?

Auf jeden Fall relational. Unbegrenzte Flexibilität und Erweiterung.

Zwei Korrekturen, sowohl im Konzept als auch in der Anwendung, gefolgt von einer Erhöhung.

Korrektur

1. Es geht nicht darum, "nicht benötigte Daten herauszufiltern"; Es werden nur die benötigten Daten ausgewählt. Ja, wenn Sie einen Index zur Unterstützung der in der WHERE-Klausel angegebenen Spalten haben, ist dieser natürlich sehr schnell und die Abfrage hängt nicht von der Größe der Tabelle ab (das Abrufen von 1.000 Zeilen aus einer 16-Milliarden-Zeilentabelle erfolgt sofort). .

2. Ihr Tisch hat ein ernstes Hindernis. In Anbetracht Ihrer Beschreibung lautet die tatsächliche PK (Gerät, Metrik, DateTime). (Bitte nennen Sie es nicht TimeStamp, das bedeutet etwas anderes, aber das ist ein kleines Problem.) Die Eindeutigkeit der Zeile wird identifiziert durch:

      (Device, Metric, DateTime)
   

   • Die IdSpalte macht nichts, sie ist völlig überflüssig.

     • Eine IdSpalte ist niemals ein Schlüssel (doppelte Zeilen, die in einer relationalen Datenbank verboten sind, müssen auf andere Weise verhindert werden).

     • Die IdSpalte erfordert einen zusätzlichen Index, der offensichtlich die Geschwindigkeit von behindert INSERT/DELETEund den verwendeten Speicherplatz erhöht .

     • Sie können es loswerden. Bitte.

Elevation

1. Nachdem Sie das Hindernis beseitigt haben, haben Sie es möglicherweise nicht erkannt, aber Ihr Tisch befindet sich in der sechsten Normalform. Sehr hohe Geschwindigkeit mit nur einem Index auf der PK. Lesen Sie zum Verständnis diese Antwort aus der Was ist die sechste Normalform? weiter vorwärts.

   • (Ich habe nur einen Index, nicht drei; auf den Nicht-SQLs benötigen Sie möglicherweise drei Indizes).

   • Ich habe genau die gleiche Tabelle ( Idnatürlich ohne den "Schlüssel"). Ich habe eine zusätzliche Spalte Server. Ich unterstütze mehrere Kunden aus der Ferne.

     (Server, Device, Metric, DateTime)

   Die Tabelle kann verwendet werden, um die Daten mit genau demselben SQL-Code zu schwenken (dh Devicesüber die Oberseite und die Unterseite Metricsoder geschwenkt) (ja, die Zellen wechseln). Ich verwende die Tabelle, um eine unbegrenzte Anzahl von Grafiken und Diagrammen für Kunden bezüglich ihrer Serverleistung zu erstellen.

   • Überwachen des Statistikdatenmodells .
     (Zu groß für Inline; einige Browser können Inline nicht laden; klicken Sie auf den Link. Auch dies ist die veraltete Demoversion. Aus offensichtlichen Gründen kann ich Ihnen kein kommerzielles Produkt DM zeigen.)

   • Es ermöglicht mir, Diagramme wie dieses zu erstellen , sechs Tastenanschläge, nachdem ich mit einem einzigen SELECT-Befehl eine unformatierte Überwachungsstatistikdatei vom Kunden erhalten habe . Beachten Sie das Mix-and-Match; Betriebssystem und Server im selben Diagramm; eine Vielzahl von Pivots. Natürlich gibt es keine Begrenzung für die Anzahl der Statistikmatrizen und damit für die Diagramme. (Wird mit freundlicher Genehmigung des Kunden verwendet.)

   • Leser, die mit dem Standard zur Modellierung relationaler Datenbanken nicht vertraut sind, finden die IDEF1X-Notation möglicherweise hilfreich.

Eine Sache noch

Last but not least ist SQL ein IEC / ISO / ANSI-Standard. Die Freeware ist eigentlich Non-SQL; Es ist betrügerisch, den Begriff SQL zu verwenden, wenn sie den Standard nicht bereitstellen. Sie können "Extras" bereitstellen, aber ihnen fehlen die Grundlagen.

Fand die obigen Antworten sehr interessant. Ich versuche hier ein paar weitere Überlegungen hinzuzufügen.

1) Datenalterung

Das Zeitreihenmanagement muss normalerweise Alterungsrichtlinien erstellen. Ein typisches Szenario (z. B. Überwachung der Server-CPU) erfordert Folgendes:

• 1-Sekunden- Rohproben für einen kurzen Zeitraum (z. B. für 24 Stunden)

• 5- minütige Detailaggregatproben für einen mittleren Zeitraum (z. B. 1 Woche)

• 1 Stunde Detail darüber (zB bis zu 1 Jahr)

Obwohl relationale Modelle es sicher ermöglichen (mein Unternehmen hat massive zentralisierte Datenbanken für einige große Kunden mit Zehntausenden von Datenreihen implementiert), diese angemessen zu verwalten, bietet die neue Generation von Datenspeichern interessante Funktionen, die untersucht werden müssen:

• automatisierte Datenbereinigung (siehe Befehl EXPIRE von Redis)

• mehrdimensionale Aggregationen (z. B. Jobs mit Kartenreduzierung a-la-Splunk)

2) Echtzeiterfassung

Noch wichtiger ist, dass einige nicht relationale Datenspeicher von Natur aus verteilt sind und eine wesentlich effizientere Echtzeit- (oder nahezu Echtzeit-) Datenerfassung ermöglichen, die aufgrund der Erstellung von Hotspots (Verwaltung der Indizierung beim Einfügen) ein Problem mit RDBMS darstellen kann eine einzelne Tabelle). Dieses Problem im RDBMS-Bereich wird normalerweise gelöst, indem auf Stapelimportverfahren zurückgegriffen wird (wir haben es in der Vergangenheit auf diese Weise verwaltet), während No-SQL-Technologien eine massive Echtzeiterfassung und -aggregation erfolgreich durchgeführt haben (siehe beispielsweise Splunk, wie in früheren Antworten erwähnt). .

Ihre Tabelle enthält Daten in einer einzelnen Tabelle. Relational vs non relational ist also nicht die Frage. Grundsätzlich müssen Sie viele sequentielle Daten lesen. Wenn Sie über genügend RAM verfügen, um Daten im Wert von einem Jahr zu speichern, können Sie Redis / MongoDB usw. nicht mehr verwenden.

In den meisten NoSQL-Datenbanken werden Ihre Daten am selben Speicherort auf der Festplatte und in komprimierter Form gespeichert, um den Zugriff auf mehrere Festplatten zu vermeiden.

NoSQL macht dasselbe wie das Erstellen des Index für die Geräte-ID und die Metrik-ID, jedoch auf seine eigene Weise. Selbst wenn Sie dies in der Datenbank tun, befinden sich der Index und die Daten möglicherweise an verschiedenen Stellen, und es würde eine Menge Festplatten-E / A geben.

Tools wie Splunk verwenden NoSQL-Backends zum Speichern von Zeitreihendaten und verwenden dann Map Reduce, um Aggregate zu erstellen (was möglicherweise später gewünscht wird). Meiner Meinung nach ist die Verwendung von NoSQL eine Option, da die Leute es bereits für ähnliche Anwendungsfälle ausprobiert haben. Aber wird eine Million Zeilen die Datenbank zum Crawlen bringen (möglicherweise nicht, mit anständiger Hardware und richtigen Konfigurationen).

Erstellen Sie eine Datei und nennen Sie sie 1_2.data. seltsame Idee? Was man bekommt:

• Sie sparen bis zu 50% des Speicherplatzes, da Sie den Wert fk_to_device und fk_to_metric nicht für jeden Datenpunkt wiederholen müssen.
• Sie sparen noch mehr Platz, weil Sie keine Indizes benötigen.
• Speichern Sie Paare von (Zeitstempel, metrischer Wert) in der Datei, indem Sie die Daten anhängen, damit Sie eine Bestellung per Zeitstempel kostenlos erhalten. (vorausgesetzt, Ihre Quellen senden keine Daten für ein Gerät aus der Reihenfolge)

=> Abfragen nach Zeitstempel werden erstaunlich schnell ausgeführt, da Sie mithilfe der binären Suche die richtige Stelle in der Datei finden können, aus der Sie lesen können.

Wenn es Ihnen noch besser gefällt, denken Sie darüber nach, Ihre Dateien so aufzuteilen.

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

oder benutze kdb + von http://kx.com, weil sie das alles für dich tun :) spaltenorientiert ist das, was dir helfen kann.

Es taucht eine Cloud-basierte spaltenorientierte Lösung auf. Vielleicht möchten Sie einen Blick darauf werfen: http://timeseries.guru

Wenn Sie sich GPL-Pakete ansehen, ist RRDTool eine gute Wahl . Es ist ein gutes Werkzeug zum Speichern, Extrahieren und Zeichnen von Zeitreihendaten. Ihr Anwendungsfall sieht genauso aus wie Zeitreihendaten.

Dies ist ein Problem, das wir bei ApiAxle lösen mussten. Wir haben einen Blog-Beitrag darüber geschrieben, wie wir es mit Redis gemacht haben. Es ist noch nicht lange da draußen, aber es erweist sich als effektiv.

Ich habe RRDTool auch für ein anderes Projekt verwendet, das ausgezeichnet war.

Ich denke, dass sich die Antwort auf diese Art von Frage hauptsächlich auf die Art und Weise beziehen sollte, wie Ihre Datenbank Speicher verwendet. Einige Datenbankserver verwenden RAM und Festplatte, andere nur RAM (optional Festplatte für Persistenz) usw. Die meisten gängigen SQL-Datenbanklösungen verwenden Speicher + Festplattenspeicher und schreiben die Daten in ein zeilenbasiertes Layout (jedes eingefügte Raw wird in dasselbe geschrieben physischer Standort). In Zeitreihenspeichern ist die Arbeitslast in den meisten Fällen wie folgt: Relativ geringes Intervall mit einer großen Anzahl von Einfügungen, während Lesevorgänge spaltenbasiert sind (in den meisten Fällen möchten Sie einen Datenbereich aus einer bestimmten Spalte lesen, die eine Metrik darstellt).

Ich habe festgestellt, dass Columnar Databases (google it, MonetDB, InfoBright, parAccel usw.) hervorragende Arbeit für Zeitreihen leisten.

Was Ihre Frage betrifft, die ich persönlich für etwas ungültig halte (wie alle Diskussionen mit dem Fehlerbegriff NoSQL - IMO): Sie können einen Datenbankserver verwenden, der einerseits SQL sprechen kann, was Ihr Leben sehr einfach macht, da jeder SQL für viele kennt Jahre und diese Sprache wurde immer wieder für Datenabfragen perfektioniert; Verwenden Sie RAM, CPU-Cache und Festplatte jedoch weiterhin spaltenorientiert, damit Ihre Lösung am besten zu Zeitreihen passt

5 Millionen Zeilen sind nichts für die heutigen Torrentialdaten. Erwarten Sie, dass die Daten in wenigen Monaten in der TB oder PB vorliegen. Zu diesem Zeitpunkt skalieren RDBMS nicht auf die Aufgabe und wir benötigen die lineare Skalierbarkeit von NoSql-Datenbanken. Die Leistung würde für die zum Speichern der Daten verwendete Spaltenpartition erreicht, indem mehr Spalten und weniger Zeilen hinzugefügt würden, um die Leistung zu steigern. Nutzen Sie die Open TSDB-Arbeit, die über HBASE oder MapR_DB usw. ausgeführt wird.

Ich habe regelmäßig ähnliche Anforderungen und verwende seit kurzem Zabbix, um diese Art von Daten zu sammeln und zu speichern. Zabbix verfügt über eine eigene Grafikfunktion, aber es ist einfach genug, die Daten aus der Zabbix-Datenbank zu extrahieren und zu verarbeiten, wie Sie möchten. Wenn Sie Zabbix noch nicht ausgecheckt haben, lohnt es sich möglicherweise, dies zu tun.

Sie sollten in die Zeitreihendatenbank schauen . Es wurde zu diesem Zweck erstellt.

Eine Zeitreihendatenbank (TSDB) ist ein Softwaresystem, das für die Verarbeitung von Zeitreihendaten, nach Zeit indizierten Zahlenfeldern (Datum / Uhrzeit oder Datum / Uhrzeit) optimiert ist.

Beliebtes Beispiel für die Zeitreihendatenbank InfluxDB