Ich versuche, mögliche Methoden zum Speichern von 100 Kanälen von 25 Hz Gleitkommadaten zu identifizieren. Dies führt zu 78.840.000.000 Datenpunkten pro Jahr .
Im Idealfall wären alle diese Daten für Websites und Tools wie Sql Server Reporting Services effizient verfügbar. Wir sind uns bewusst, dass relationale Datenbanken bei der Bearbeitung von Zeitreihen dieser Größenordnung schlecht sind, aber eine überzeugende zeitserienspezifische Datenbank noch nicht identifiziert haben.
Die wichtigsten Probleme sind die Komprimierung für eine effiziente Speicherung, aber auch einfache und effiziente Abfragen, Berichterstellung und Data-Mining.
Wie würden Sie mit diesen Daten umgehen?
Gibt es in Sql Server Features oder Tabellen-Designs, die eine solche Menge an Zeitreihendaten verarbeiten können?
Wenn nicht, gibt es Erweiterungen von Drittanbietern für den Sql-Server, um effizient mit Mammut-Zeitreihen umgehen zu können?
Falls nicht, gibt es Zeitreihendatenbanken, die sich auf den Umgang mit solchen Daten spezialisiert haben und dennoch einen natürlichen Zugriff durch SQL, .Net und SQL Reporting Services bieten?
Danke!
Ich würde die Tabelle z. B. nach Datum aufteilen, um die Daten in winzige Bits von 216,000,000 Zeilen zu teilen.
Vorausgesetzt, Sie benötigen keine Ganzjahresstatistik, ist dies leicht durch Indizes bedienbar.
Sagen wir, die Abfrage wie " geben Sie mir einen Durchschnitt für die angegebene Stunde " ist eine Frage von Sekunden.
Ich nehme an, dass Sie einen zufälligen Zugriff auf die Datenserie benötigen. Die Idee, die ich bereits für die Niederschlagsdatentabelle verwendet habe, besteht darin, den gesamten Datensatz in kleinere Teile zu unterteilen, um einen Eintrag für alle paar Minuten oder sogar eine Minute zu erstellen. Dann können Sie dieses immer noch große Array aus der Datenbank aufrufen und direkt auf den benötigten Teil zugreifen. Sie können eine direkte Korrelation zwischen Zeitoffset und Byte-Offset finden.
Der Feature-Satz, den Sie beschreiben, ist für einen Analyse-Cube. Wenn Sie sich in diesem Teil der Tech-Welt befinden, sehen Sie sich die Analyseservices von Microsoft an:
Was das Modell betrifft, das Sie beschreiben, müssen Sie ein Kimball-Modell (das Standard-Data-Warehousing-Modell) mit einer Zeitdimension implementieren. Ich habe dieses Problem beim Speichern von Medienprotokolldateien vor einiger Zeit erkannt.
Viel Glück.
Sie können Infobright Community oder Enterprise Edition ausprobieren, denke ich. Es ist ein spaltenorientierter Speicher, der für Analysezwecke und große (bei bestehenden Installationen bis zu 30 TB) Daten und eine gute Kompressionsrate entwickelt wurde.
Data Loader sind auch ziemlich schnell und Konnektoren gibt es für ETL-Tools (Talend, Kessel und so weiter).
Die Community-Edition ist unter GNU GPL-Bedingungen frei verfügbar, erlaubt jedoch das Hinzufügen von Daten nur über nativen Loader. Enterprise Edition unterstützt das Hinzufügen / Aktualisieren von einzelnen Zeilen über DML.
Ein weiterer Vorteil, den Sie mit allen Tools nutzen können, die MySQL-Verbindungen unterstützen.
Spalten-Orientierung erlaubt es zB, Spalten für die Datum-Komponente auf jeder benötigten Aggregations-Ebene hinzuzufügen (Ich benutze Datum, Woche, Monate und Qtr.) für bessere Leistung, aber es ist auch gut ohne.
Ich benutze es für relativ kleine (noch) Menge von Geschäftstransaktionen Daten für analytische Zwecke mit R als Datenanalyse-Tool über MySQL-Schnittstelle und Python (numpy) Skripte als eine Art von ETL.
Nachteile: Mangel an offizieller utf-8-Unterstützung, Aggregation nach Funktionswerten (Monat auswählen (Datum von ...)) noch nicht implementiert (Plan: Juli 2009, AFAIK), dafür verwende ich ETL.
Link: Ссылка
Sie haben
A. 365 x 24 x 100 = 876.000 stündliche Signale (alle Kanäle) pro Jahr
B. jedes Signal umfasst 3600 * 25 = 90.000 Datenpunkte
Wie wäre es, wenn Sie Daten als eine Zeile pro Signal speichern, mit Spalten für Zusammenfassungs- / Abfrage-Statistiken für derzeit unterstützte Anwendungsfälle und einem blob des komprimierten Signals für zukünftige?
Haben Sie eine Zeitreihendatenbank wie Ссылка in Erwägung gezogen?
Wenn es sich nur um Gleitkommadaten handelt, bieten TSDBs eine weitaus bessere Leistung. Zeitreihen-Komprimierungsalgorithmen sind unterschiedlich, daher erhalten Sie bessere Speicher- und Abfrage-Raten.
Tags und Links sql-server database data-mining reporting-services