Wie speichert man Zeitreihen von 100 x 25 Hz über viele Jahre - Sql Server oder Zeitreihen-Datenbank

Question

Ich versuche, mögliche Methoden zur Speicherung von 100 Kanälen mit 25-Hz-Gleitkommadaten zu ermitteln. Das Ergebnis wird sein 78.840.000.000 Datenpunkte pro Jahr .

Idealerweise wären all diese Daten für Websites und Werkzeuge wie SQL Server Reporting Services effizient verfügbar. Wir sind uns bewusst, dass relationale Datenbanken für Zeitreihen dieser Größenordnung ungeeignet sind, haben aber noch keine überzeugende zeitreihenspezifische Datenbank gefunden.

Kernpunkte sind die Komprimierung für eine effiziente Speicherung sowie einfache und effiziente Abfragen, Berichte und Data Mining.

• Wie würden Sie mit diesen Daten umgehen?

• Gibt es Funktionen oder Tabellendesigns in Sql Server, die eine solche Menge von Zeitreihendaten verarbeiten können?

• Wenn nicht, gibt es irgendwelche 3rd-Party-Erweiterungen für Sql-Server, um effizient Mammut-Zeitreihen zu verarbeiten?

• Wenn nicht, gibt es Zeitreihendatenbanken, die auf die Verarbeitung solcher Daten spezialisiert sind und dennoch einen natürlichen Zugang über SQL, .Net und SQL Reporting Services bieten?

Danke!

Answer 1

Ich würde die Tabelle z. B. nach Datum partitionieren, um die Daten in winzige Teile aufzuteilen. 216,000,000 Zeilen je.

Sofern Sie keine Ganzjahresstatistiken benötigen, ist dies mit Indizes leicht zu bewerkstelligen.

Sagen wir, die Abfrage wie " Geben Sie mir einen Durchschnittswert für die gegebene Stunde " wird eine Sache von Sekunden sein.

Answer 2

Ich nehme an, Sie brauchen einen zufälligen Zugriff auf die Datenreihen. Die Idee, die ich bereits für die Regendaten-Tabelle verwendet habe, besteht darin, den gesamten Datensatz in kleinere Teile zu unterteilen, um einen Eintrag für jeweils einige Minuten oder sogar eine Minute zu erstellen. Dann kann man dieses immer noch große Array aus der Datenbank herausnehmen und direkt auf den benötigten Teil zugreifen, man kann eine direkte Korrelation zwischen dem Zeitversatz und dem Byte-Offset finden.

Answer 3

Der von Ihnen beschriebene Funktionssatz ist für einen Analysewürfel. Schauen Sie sich die Analysis Services von Microsoft an, wenn Sie in diesem Bereich der technischen Welt tätig sind:

http://msdn.microsoft.com/en-us/library/ms175609(SQL.90).aspx

Was die Modell müssen Sie ein Kimball-Modell (das Standardmodell für Data Warehousing) mit einer Zeitdimension implementieren. Vor einiger Zeit stieß ich bei der Speicherung von Medienprotokolldateien auf dieses Problem.

Viel Glück!

Answer 4

Sie können sich die Infobright Community oder Enterprise Edition ansehen, denke ich. Es ist ein spaltenorientierter Speicher, der für Analysezwecke und große Daten (bestehende Installationen mit bis zu 30 TB, wie es heißt) und eine gute Komprimierungsrate konzipiert ist.

Datenlader sind auch ziemlich schnell und es gibt Konnektoren für ETL-Tools (Talend, Kettle usw.).

Die Gemeinschaftsversion ist unter den Bedingungen der GNU GPL frei erhältlich, erlaubt aber das Hinzufügen von Daten nur über den nativen Lader. Die Enterprise-Edition unterstützt das Hinzufügen/Aktualisieren einzelner Zeilen über DML.

Ein weiterer Vorteil ist, dass Sie es mit allen Tools verwenden können, die MySQL-Verbindungen unterstützen.

Die Spaltenorientierung ermöglicht es Ihnen, z.B. Spalten für die Datumskomponente auf jeder benötigten Aggregationsebene hinzuzufügen (ich verwende Datum, Wochennummern, Monate und Quartale), um die Leistung zu verbessern, aber es geht auch ohne sie.

Ich verwende es für eine (noch) relativ kleine Menge an Geschäftsvorgangsdaten zu Analysezwecken mit R als Datenanalysewerkzeug über eine mysql-Schnittstelle und Python (numpy)-Skripte als eine Art ETL.

Nachteile: Fehlen einer offiziellen utf-8-Unterstützung, Aggregation nach Funktionswerten (select month(date from ...)) noch nicht implementiert (Plan: Juli 2009, AFAIK), aber ich verwende ETL dafür.

リンク http://www.infobright.org/Download/ICE/

Answer 5

Sie haben

A. 365 x 24 x 100 = 876.000 stündlich Signale (alle Kanäle) pro Jahr

B. jedes Signal umfasst 3600 * 25 = 90.000 Datenpunkte

Wie wäre es, wenn Sie die Daten als eine Zeile pro Signal speichern, mit Spalten für Zusammenfassungs-/Abfragestatistiken für derzeit unterstützte Anwendungsfälle und einer blob des komprimierten Signals für zukünftige Signale?