it-swarm-eu.dev

Speichern von Zeitreihendaten, relational oder nicht?

Ich erstelle ein System, das Geräte mithilfe von SNMP in (wahrscheinlich) 5-Minuten-Intervallen nach Daten abfragt, die sich auf unterschiedliche Messgrößen wie CPU-Auslastung, Festplattenauslastung, Temperatur usw. beziehen. Das ultimative Ziel ist es, einem Benutzer des Systems Visualisierungen in Form von Zeitreihengraphen bereitzustellen.

Ich habe in der Vergangenheit die Verwendung von RRDTool in Erwägung gezogen, es jedoch abgelehnt, da das unbegrenzte Speichern der erfassten Daten für mein Projekt wichtig ist. Ich möchte einen umfassenderen und flexibleren Zugriff auf die erfassten Daten. Also meine Frage ist 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 ein data_instances Tabelle, in der jede Instanz von Daten gespeichert wird, die für jede Metrik erfasst werden, die für alle Geräte gemessen wird, mit den folgenden Feldern:

Felder: idfk_to_devicefk_to_metricmetric_valuetimestamp

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

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

dabei ist d die Anzahl der Geräte, m_d ist die kumulative Anzahl der Metriken, die für alle Geräte aufgezeichnet wird, f ist die Häufigkeit, mit der Daten abgefragt werden, und t ist die Gesamtmenge von Zeit das System hat Daten gesammelt.

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

Indizes

Ohne Indexe auf fk_to_device und fk_to_metric Das Scannen dieses ständig wachsenden Tisches würde zu viel Zeit in Anspruch nehmen. Daher ist die Indizierung der oben genannten Felder und auch von timestamp (zum Erstellen von Diagrammen mit lokalisierten Zeiträumen) erforderlich.

Nicht relational (NoSQL)

MongoDB hat das Konzept einer Auflistung , im Gegensatz zu Tabellen können diese programmgesteuert ohne Setup 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 Abschnitt wird jedoch vorgeschlagen, den größten Teil der traditionellen relationalen Abfragearbeit in der Struktur zu erledigen, in der die Daten unter NoSQL gespeichert werden.

Unentschieden

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

176
Marcus Whybrow

Definitiv relational. Grenzenlose Flexibilität und Erweiterung.

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

Korrektur

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

  2. Ihr Tisch hat ein ernstes Hindernis. In Anbetracht Ihrer Beschreibung ist die tatsächliche PK (Gerät, Metrik, Datum/Uhrzeit). (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 Spalte Id macht nichts, sie ist vollständig und überflüssig.

      • Eine Id -Spalte ist niemals ein Schlüssel (doppelte Zeilen, die in einer relationalen Datenbank nicht zulässig sind, müssen auf andere Weise verhindert werden).
      • Die Spalte Id erfordert einen zusätzlichen Index, der die Geschwindigkeit von INSERT/DELETE Offensichtlich beeinträchtigt und den belegten Speicherplatz vergrößert.

      • 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. Zum Verständnis lesen Sie diese Antwort aus dem Was ist Sechste Normal Form? Überschrift weiter.

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

    • Ich habe genau die gleiche Tabelle (natürlich ohne den Id "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 (dh Devices oben und Metrics unten oder gedreht) unter Verwendung genau desselben SQL-Codes zu schwenken (ja, Zellen wechseln). Ich verwende die Tabelle, um eine unbegrenzte Anzahl von Grafiken und Diagrammen für Kunden zu erstellen, die ihre Serverleistung verbessern möchten.

    • Statistikdatenmodell überwachen .
      (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 das kommerzielle Produkt DM nicht anzeigen.)

    • Es ermöglicht mir, Diagramme wie dieses zu erstellen, sechs Tastenanschläge nach dem Empfang einer rohen Überwachungsstatistikdatei von der Kunden mit einem einzelnen SELECT-Befehl . 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 Statistik-Matrizen und damit der Charts. (Mit freundlicher Genehmigung des Kunden verwendet.)

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

Noch eine Sache

Nicht zuletzt ist SQL ein IEC/ISO/ANSI-Standard. Die Freeware ist eigentlich Non-SQL; Es ist betrügerisch, den Begriff SQL zu verwenden, wenn sie nicht den Standard enthalten. Sie können "Extras" zur Verfügung stellen, aber ihnen fehlen die Grundlagen.

149
PerformanceDBA

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

1) Datenalterung

Bei der Zeitreihenverwaltung müssen in der Regel Alterungsrichtlinien erstellt werden. In einem typischen Szenario (z. B. Überwachung der Server-CPU) muss Folgendes gespeichert werden:

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

  • 5 Minuten detaillierte Aggregatproben für einen mittleren Zeitraum (z. B. 1 Woche)

  • 1 Stunde Detail darüber (z. B. bis zu 1 Jahr)

Obwohl relationale Modelle es mit Sicherheit ermöglichen (mein Unternehmen hat für einige große Kunden mit Zehntausenden von Datenreihen massive zentralisierte Datenbanken 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. kartenreduzierte Jobs a-la-Splunk)

2) Echtzeiterfassung

Noch wichtiger ist, dass einige nicht relationale Datenspeicher inhärent verteilt sind und eine effizientere Datenerfassung in Echtzeit (oder nahezu in Echtzeit) ermöglichen, die aufgrund der Erstellung von Hotspots (Verwaltung der Indexierung beim Einfügen in RDBMS) ein Problem darstellen kann eine einzelne Tabelle). Dieses Problem im RDBMS-Bereich wird in der Regel durch das Zurücksetzen auf Stapelimportverfahren behoben (wir haben es in der Vergangenheit so gehandhabt), während No-SQL-Technologien eine massive Echtzeiterfassung und -aggregation erfolgreich abgeschlossen haben (siehe Splunk, zum Beispiel, erwähnt in früheren Antworten). .

19
Paolo Bozzola

Ihre Tabelle enthält Daten in einer einzelnen Tabelle. Also ist relational vs. nicht relational nicht die Frage. Grundsätzlich müssen Sie viele sequentielle Daten lesen. Wenn Sie nun genug RAM zum Speichern jahrelanger Daten haben, dann geht nichts über die Verwendung von Redis/MongoDB usw.

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

NoSQL erstellt den Index für Geräte-ID und Metrik-ID auf seine eigene Weise. Selbst wenn Sie dies bei einer Datenbank tun, befinden sich der Index und die Daten möglicherweise an verschiedenen Stellen, und es würde eine Menge Festplatten-E/A-Vorgänge geben.

Tools wie Splunk verwenden NoSQL-Backends, um Zeitreihendaten zu speichern, und verwenden dann Map Reduce, um Aggregate zu erstellen (was möglicherweise später gewünscht wird). Daher ist meiner Meinung nach 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 (vielleicht nicht, mit anständiger Hardware und richtigen Konfigurationen)?.

7
Ravindra

Erstellen Sie eine Datei mit dem Namen 1_2.data. verrückte Idee? was Sie erhalten:

  • Sie sparen bis zu 50% Platz, da Sie die Werte 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 (timestamp, metric_value) in der Datei, indem Sie die Daten anhängen, damit Sie eine kostenlose Bestellung nach Zeitstempel erhalten. (unter der Annahme, dass Ihre Quellen für ein Gerät keine Daten aus der Bestellung senden)

=> Abfragen nach Zeitstempel werden erstaunlich schnell ausgeführt, da Sie die Binärsuche verwenden können, um die richtige Stelle in der Datei zu finden, von der gelesen werden soll.

wenn es Ihnen noch besser gefällt, denken Sie darüber nach, Ihre Dateien so zu teilen.

  • 1_2_january2014.data
  • 1_2_Februar2014.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 erscheint eine cloudbasierte spaltenorientierte Lösung. Schauen Sie sich also vielleicht Folgendes an: http://timeseries.gur

4
hellomichibye

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.

3
sunil

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

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

2
Phil Jackson

Ich denke, die Antwort auf diese Art von Frage sollte sich hauptsächlich auf die Art und Weise drehen, wie Ihre Datenbank Speicherplatz nutzt. Einige Datenbankserver verwenden RAM und Festplatte, andere RAM nur (optional Festplatte für Persistenz) usw.). Die meisten gängigen SQL-Datenbanklösungen verwenden Speicher + Festplattenspeicher und schreibt die Daten in ein zeilenbasiertes Layout (jedes eingefügte Raw wird an die gleiche physische Position geschrieben.) In Zeitreihengeschäften ist die Arbeitslast in den meisten Fällen wie folgt: Relativ geringes Intervall von massiven 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-Datenbanken (Google, 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 SQL auf einer Seite beherrscht, 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 dennoch spaltenorientiert RAM, CPU-Cache und Festplatte, damit Ihre Lösung optimal zu Zeitreihen passt

2
Shay

5 Millionen Zeilen sind nichts für die heutigen Torrential-Daten. Erwarten Sie, dass die Daten in wenigen Monaten in TB oder PB vorliegen. Zu diesem Zeitpunkt skalieren RDBMS nicht mit der Aufgabe, und wir benötigen die lineare Skalierbarkeit von NoSql-Datenbanken Spaltenpartition zum Speichern der Daten, Hinzufügen von mehr Spalten und weniger Zeilen zur Leistungssteigerung Nutzen Sie die Open TSDB-Arbeit, die über HBASE oder MapR_DB usw. ausgeführt wird.

2
Juan Asenjo

Ich stelle regelmäßig ähnliche Anforderungen und nutze Zabbix seit kurzem, 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 Datenbank von Zabbix zu extrahieren und sie nach Belieben zu verarbeiten. Wenn Sie Zabbix noch nicht ausgecheckt haben, ist es möglicherweise Ihre Zeit wert, dies zu tun.

1
monch1962

Sie sollten nach Zeitreihendatenbank suchen. Es wurde zu diesem Zweck erstellt.

Eine Zeitreihendatenbank (TSDB) ist ein Softwaresystem, das für die Verarbeitung von Zeitreihendaten optimiert ist. Dabei handelt es sich um Arrays von Zahlen, die nach Zeit indiziert sind (Datum und Uhrzeit oder Datum/Uhrzeit-Bereich).

Beliebtes Beispiel für eine Zeitreihendatenbank InfluxDB

0
Adam