Speichern von Zeitreihen Daten, relational oder nicht?

https://stackoverflow.com/questions/4814167

25-10-2019
|

Frage

Ich erstelle ein System, das Geräte für Daten zu unterschiedlichen Metriken wie CPU -Auslastung, Festplattennutzung, Temperatur usw. in (wahrscheinlich) 5 -Minuten -Intervallen unter Verwendung von SNMP befragt. Das ultimative Ziel ist es, einem Benutzer des Systems in Form von Zeitreihen-Diagramme Visualisierungen bereitzustellen.

Ich habe mich in der Vergangenheit mit RRDTool angesehen, aber es ist wichtig, die erfassten Daten auf unbestimmte Zeit zu speichern, ist für mein Projekt wichtig, und ich möchte ein höheres Niveau und flexibleren Zugriff auf die erfassten Daten. Meine Frage ist also wirklich:

Was besser ist, eine relationale Datenbank (wie MySQL oder PostgreSQL) oder eine nicht-relationale oder NoSQL-Datenbank (wie MongoDB oder Redis) in Bezug auf die Leistung beim Abfragen von Daten für die Grafik.

Relational

Bei einer relationalen Datenbank würde ich a verwenden data_instances Tabelle, in der jede Instanz von Daten gespeichert wird, die für jede für alle Geräte gemessene Metrik mit den folgenden Feldern erfasst werden:

Felder: id fk_to_device fk_to_metric metric_value timestamp

Wenn ich auf einem bestimmten Gerät ein Diagramm für eine bestimmte Metrik zeichnen möchte, muss ich diese einzigartige Tabelle abfragen herausfiltern Die anderen Geräte und die anderen Metriken werden 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

wo d ist die Anzahl von Geräte, m_d ist der akkumulativ Anzahl der Metriken für alle Geräte aufgezeichnet werden, f ist der Frequenz mit denen Daten für und befragt werden 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 unter 5 Millionen Aufzeichnungen.

Indizes

Ohne Indizes auf fk_to_device und fk_to_metric Das Scannen dieser kontinuierlich expandierenden Tabelle würde zu viel Zeit in Anspruch nehmen. So indizieren die oben genannten Felder und auch timestamp (Zum Erstellen von Grafiken mit lokalisierten Perioden) ist eine Voraussetzung.

Nicht-relationale (NoSQL)

MongoDB hat das Konzept von a Sammlung, 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 eine Abfrageleistungserhöhungsfunktionen wie die Indexierung bieten. Der vorherige Absatz schlägt jedoch vor, die meisten traditionellen relationalen Abfragenarbeit in der Struktur zu erledigen, durch die die Daten unter NoSQL gespeichert werden.

Unentschieden

Würde eine relationale Lösung mit der korrekten Indexierung innerhalb des Jahres auf ein Crawl reduzieren? Oder bietet die Sammelstruktur von NoSQL -Ansätzen (die meinem mentalen Modell der gespeicherten Daten entspricht) einen spürbaren Nutzen?

Lösung

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

Zwei Korrekturen, sowohl im Konzept als auch in der Anwendung, gefolgt von einer Erhebung.

Korrektur

Es wird nicht "die unbedachten Daten herausfiltern". es ist Nur auswählen die erforderlichen Daten. Ja, natürlich, wenn Sie einen Index haben, der die in der WHERE -Klausel identifizierten Spalten unterstützt, ist er sehr schnell und die Abfrage hängt nicht von der Größe der Tabelle ab (1000 Zeilen aus einer 16 -Milliarden -Zeilentabelle zu greifen ist augenblicklich) .
Ihr Tisch hat ein ernstes Hindernis. In Anbetracht Ihrer Beschreibung ist der tatsächliche PK (Gerät, metrisch, datetime). (Bitte nennen Sie es nicht Zeitstempel, das bedeutet etwas anderes, aber das ist ein kleines Problem.) Die Einzigartigkeit der die Zeile wird identifiziert durch:
```
   (Device, Metric, DateTime)
```
- Das Id Die Säule tut nichts, sie ist völlig und völlig überflüssig.
  - Ein Id Die Spalte ist niemals ein Schlüssel (doppelte Zeilen, die in einer relationalen Datenbank verboten sind, müssen mit anderen Mitteln verhindert werden).
  - Das Id Die Spalte erfordert einen zusätzlichen Index, der offensichtlich die Geschwindigkeit von behindert INSERT/DELETE, und fügt den verwendeten Speicherplatz hinzu.
  - Sie können es loswerden. Bitte.

Elevation

Nachdem Sie das Hindernis entfernt haben, haben Sie es vielleicht 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 Diese Antwort von dem Was ist die sechste normale Form? Auf dem Weg weiter.
- (Ich habe nur einen Index, nicht drei; auf den Nicht-SQLs benötigen Sie möglicherweise drei Indizes).
- Ich habe genau die gleiche Tabelle (ohne die Id "Key" natürlich). 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 zu drehen (dh. Devices oberhalb und Metrics Die Seite runter oder geplant) mit genau denselben SQL -Code (ja, die Zellen schalten). Ich verwende die Tabelle, um eine unbegrenzte Vielzahl von Diagrammen und Diagrammen für Kunden zu errichten, die ihre Serverleistung erzielen.
- Überwachen Sie das Statistikdatenmodell.
  (Zu groß für Inline; einige Browser können inline nicht laden; klicken Sie auf den Link. Auch das ist die veraltete Demo -Version. Aus offensichtlichen Gründen kann ich Ihnen nicht kommerzielles Produkt dm zeigen.)
- Es ermöglicht mir zu produzieren Diagramme wie diese, sechs Tastenanschläge nach Erhalt einer RAW -Überwachungs -Statistikdatei vom Kunden mit a Einzelauswahlbefehl. Beachten Sie den Mix-and-Match; Betriebssystem und Server auf demselben Diagramm; eine Vielzahl von Dreharbeiten. Natürlich gibt es keine Grenze für die Anzahl der Statistikmatrizen und damit die Diagramme. (Verwendet mit der freundlichen Erlaubnis des Kunden.)
- Leser, die mit dem Standard für die Modellierung relationaler Datenbanken nicht vertraut sind Idef1x Notation hilfreich.

Eine Sache noch

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

Andere Tipps

Fand sehr interessant die obigen Antworten. Versuchen Sie, hier ein paar weitere Überlegungen hinzuzufügen.

1) Datenalterung

Das Zeitreihenmanagement muss in der Regel Alterungsrichtlinien erstellen. Für ein typisches Szenario (z. B. CPU des Überwachungsservers) muss gespeichert werden:

1 Sek Rohproben für einen kurzen Zeitraum (zB für 24 Stunden)
5 Minuten Detail Aggregatproben für einen mittleren Zeitraum (z. B. 1 Woche)
1 Stunde Detail darüber (zB bis zu 1 Jahr)

Obwohl relationale Modelle es mit Sicherheit ermöglichen (mein Unternehmen hat massive zentralisierte Datenbanken für einige große Kunden mit Zehntausenden von Datenreihen implementiert), um sie angemessen zu verwalten, fügt die neue Generation von Datenspeichern interessante Funktionen hinzu, die untersucht werden sollten, wie:

Automatisierte Datenspülung (siehe Befehl von Redis Ablauf)
Mehrdimensionale Aggregationen (z. B. Map-Reduce-Jobs A-La-Splunk)

2) Echtzeitsammlung

Noch wichtiger ist, dass einige nicht-relationale Datenspeicher von Natur aus verteilt sind und eine viel effizientere Datenerfassung in Echtzeit (oder nahezu realer Zeit) ermöglichen, die aufgrund der Erstellung von Hotspots ein Problem sein kann eine einzelne Tabelle). Dieses Problem im RDBMS-Bereich wird normalerweise gelöst, um zu den Batch-Importverfahren zurückzuführen (wir haben es in der Vergangenheit auf diese Weise verwaltet), während No-SQL-Technologien in der massiven Echtzeit-Sammlung und -Aggregation gelungen sind (siehe zum Beispiel in früheren Antworten erwähnt). .

Ihre Tabelle hat Daten in einer einzigen Tabelle. Relational gegenüber nicht relational ist nicht die Frage. Grundsätzlich müssen Sie viele sequentielle Daten lesen. Wenn Sie nun genug RAM haben, um ein Jahr im Wert von Jahren zu speichern, dann verwenden Sie nichts mit Redis/MongoDB usw.

Meistens speichern NoSQL -Datenbanken Ihre Daten auf demselben Standort auf der Festplatte und in komprimierter Form, um mehrfacher Speicherzugriff zu vermeiden.

NoSQL tut dasselbe wie das Erstellen des Index für Geräte -ID und metrische ID, jedoch auf seine eigene Weise. Mit der Datenbank, auch wenn Sie dies tun, können der Index und die Daten an verschiedenen Orten liegen und es würde viel Festplatten -IO geben.

Tools wie Splunk verwenden NoSQL -Backends, um Zeitreihendaten zu speichern und dann die MAP -Reduzierung zu verwenden, um Aggregate zu erstellen (was möglicherweise das ist, was Sie später wünschen). Meiner Meinung nach ist NoSQL meiner Meinung nach eine Option, da die Leute es bereits für ähnliche Anwendungsfälle ausprobiert haben. Aber werden eine Million Zeilen die Datenbank zum Kriechen bringen (vielleicht nicht mit angemessener Hardware und ordnungsgemäßer Konfigurationen).

Erstellen Sie eine Datei, nennen Sie es 1_2.Data. VERTEILUNG IDEE? was du bekommst:

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

=> Abfragen nach Zeitstempel laufen erstaunlich schnell aus, da Sie eine binäre Suche verwenden können, um den richtigen Ort in der Datei zu finden, aus dem Sie lesen können.

Wenn Sie es noch optimierter mögen, sollten Sie darüber nachdenken, Ihre Dateien so zu teilen.

1_2_January2014.Data
1_2_February2014.Data
1_2_MARCH2014.DATA

oder kDB+ verwenden http://kx.com Weil sie das alles für Sie tun :) Spaltenorientiert ist Ihnen, was Ihnen helfen kann.

Spaltenorientierte Lösung, die auf Cloud-basierte spaltenorientierte Lösung auftauchen, möchten Sie sich also ansehen: http://timeseries.guru

Wenn Sie sich GPL -Pakete ansehen, Rrdtool ist gut zu sehen. Es ist ein gutes Werkzeug zum Speichern, Extrahieren und Diagramm von Datenreihendaten. Ihr Anwendungsfall sieht genauso wie Zeitreihendaten aus.

Dies ist ein Problem, das wir in Apiaaxle lösen mussten. Wir schrieb einen Blog -Beitrag auf darüber, wie wir es mit Redis gemacht haben. Es war nicht schon lange da draußen, aber es erweist sich als effektiv.

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

Ich denke, dass sich die Antwort auf diese Art von Frage hauptsächlich über die Art und Weise drehen sollte, wie Ihre Datenbank Speicher verwendet. Einige Datenbankserver verwenden RAM und Datenträger, einige verwenden nur RAM (optional Festplatte für Persistenz) usw. physischer Standort). In den meisten Fällen ist die Workload für Timeseries-Speicher in den meisten Fällen so etwas wie: relativ niedriges Intervall der massiven Anzahl von Einsätzen, während die Lesevorgänge auf Spaltenbasis basieren (in den meisten Fällen möchten Sie einen Datenbereich aus einer bestimmten Spalte lesen, die eine Metrik darstellen)

Ich habe Columnar -Datenbanken gefunden (Google It, Sie werden, dass Monetdb, InfoBright, Paraccel usw.) einen hervorragenden Job für Zeitreihen leisten.

Was Ihre Frage betrifft, was 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, wie jeder für viele kennt Jahre und diese Sprache wurde für Datenfragen immer wieder perfektioniert. Verwenden Sie aber trotzdem RAM, CPU -Cache und Festplatte auf säulenorientierte Weise, so

5 Millionen Zeilen sind für die heutigen heftigen Daten nichts. Erwarten Sie, dass Daten in nur wenigen Monaten im TB oder PB liegen. Zu diesem Zeitpunkt skalieren RDBMs nicht die Aufgabe und wir benötigen die lineare Skalierbarkeit von NoSQL -Datenbanken. Die Leistung würde für die Säulenpartition erreicht, die zum Speichern der Daten verwendet wird, wobei weitere Spalten und weniger Zeilen das Konzept hinzugefügt werden, um die Leistung zu steigern. Nutzen Sie die offenen TSDB -Arbeiten, die auf HBase oder MAPR_DB usw. durchgeführt wurden.

Ich habe regelmäßig ähnliche Anforderungen und habe kürzlich Zabbix verwendet, um diese Art von Daten zu sammeln und zu speichern. Zabbix hat seine eigene Grafikfunktion, aber es ist einfach genug, die Daten aus der Datenbank von Zabbix zu extrahieren und sie zu verarbeiten, wie Sie möchten. Wenn Sie Zabbix noch nicht überprüft haben, finden Sie es möglicherweise Ihre Zeit wert.

Sie sollten sich untersuchen Zeitreihendatenbank. Es wurde zu diesem Zweck erstellt.

Eine Zeitreihendatenbank (TSDB) ist ein Softwaresystem, das für die Handhabung von Zeitreihendaten, Arrays von Zahlen optimiert ist, die nach Zeit indexiert sind (ein DateTime- oder ein DateTime -Bereich).

Beliebtes Beispiel für die Zeitreihendatenbank InfluxDB

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow