Hallo
Ich arbeite an einem Projekt, bei dem über einen längeren Zeitraum Daten
aufegzeichnet werden sollen.
Jeder Datensatz besteht aus Datum und Uhrzeit sowie verschiedenen
Sensorendaten- Der einzelne Datensatz ist etwa 300 byte groß.
Aufgezeichnet wird sekündlich.
Das heißt im Jahr fällt einen Datenmenge von über 9GB an.
Welche Software kann solche großen Datenmengen bzw so viele Datensätze
verarbeiten? Ich möchhte die Daten anschließend nach verschiedenen
Kriterien sortieren können, Datensätze filtern bzw. succhen, Statistiken
und Diagramme erstellen
Wenn die Auswertungen schon bekannt sind:
https://oss.oetiker.ch/rrdtool/ wurde genau für diese Aufgabe
konzipiert.
Wenn du erst mal Daten sammeln willst, und später festlegst, welche
Auswertungen du brauchst, ist eine Relationale Datenbank besser.
Pocahontas schrieb:> Ich arbeite an einem Projekt, bei dem über einen längeren Zeitraum Daten> aufegzeichnet werden sollen.> Jeder Datensatz besteht aus Datum und Uhrzeit sowie verschiedenen> Sensorendaten- Der einzelne Datensatz ist etwa 300 byte groß.> Aufgezeichnet wird sekündlich.> Das heißt im Jahr fällt einen Datenmenge von über 9GB an.>> Welche Software kann solche großen Datenmengen bzw so viele Datensätze> verarbeiten?
Jede ernstzunehmende relationale Datenbank kann das.
> Ich möchhte die Daten anschließend nach verschiedenen> Kriterien sortieren können, Datensätze filtern bzw. succhen
Das alles ist Job einer solchen Datenbank. Das können die richtig gut.
> Statistiken> und Diagramme erstellen
Das allerdings nicht. Das ist Sache der Anwendung. Zur Not: Excel. Das
kann auf jede gängige relationale DB ohne großen Sackstand zugreifen und
bietet dann Unmassen Möglichkeiten für eine interaktive Auswertung und
Repräsentation der Daten. Du muss nur ein bissel Code schreiben, um die
DB-Aufgaben Filtern und Sortieren auch tatsächlich an die DB zu
delegieren.
Hier im Forum hat einer ein Programm geschrieben, mit dem große
CSV-Dateien visualisiert werden können. Ich sehe mir damit in Kurvenform
die Dateien an, die mein Datenlogger von der Lüftungsanlage aufzeichnet.
Beitrag "Re: Visualisierung von geloggten Daten"
Ist zwar nur ein Viewer, aber vielleicht trotzdem nützlich für deine
Aufgabe.
Wenn die Eintraege gleich gross sind macht eine Datenbank sowieso keinen
Sinn, dann nimmt man besser ein flaches typisiertes File. Oder mehrere
davon, zB jeden Tag ein neues.
Der TO erwartet jährlich ca. 9 GByte Daten mit 300 Byte langen Zeilen.
Das werden 30 Millionen Datensätze.
Ich habe testweise eine 9 Gybyte große csv-Tabelle mit einer knappen
Milliarde Zellen generiert.
Genau 30 Millionen Zeilen x 33 Spalten = 990.000.000 Zellen.
Spalte 1 enthält einen UNIX Zeitstempel, die Spalten 2 - 32 enthalten
8-stellige Zufallswerte.
Beim Versuch, diese CSV-Tabell in Excel 2017 unter Windows 10 zu laden
meldete das System nach etwa 30 Sekunden:
"Die Datei enthält mehr als 1.048.576 Zeilen oder 16.384 Spalten."
Also ist Excel für die geforderte Aufgabenstellung ungeeignet.
Dann habe ich die CSV Daten unter LINUX in eine MySQL Datenbank
importiert.
Dort hatte ich Spalte 1 als Primärschlüssel definiert. Als
Storage-Engine wählte ich MyISAM.
Der Import klappte problemlos:
mysql> \. importcsv.sql
Query OK, 30000000 rows affected (5 min 15.50 sec)
Nach etwas mehr als 5 Minuten konnte die Datenbank verwendet werden.
Eine einfach Abfrage wie z.B. Zeige die Datensätze 29999970 - 29999999
dauert nun 2 Sekunden)
Das Sortieren der gesamten Tabelle nach dem Spalteninhalt einer Zeile
dauert 12,5 Sekunden.
Zum zuverlässigen Ablegen der Daten und schnellen Auswerten der Inhalte
aus 30 Millionen Datenzeilen scheint mir die Abfrage einer SQL Datenbank
eine geeignete Lösung zu sein.
Das Durchsuchen aller Tabellenwerte nach 55497575 dauerte 25 Sekunden.
Die selbe Suche in der CSV-Datei mit Grep dauerte 38 Sekunden.
Name H. schrieb:> macht eine Datenbank sowieso keinen> Sinn, dann nimmt man besser ein flaches typisiertes File
Ja, aber dann muss man Abfragen, Sortieren usw. selbst programmieren,
das dürfte die Fähigkeiten des TO erheblich übersteigen.
Georg
DPA schrieb:> Wie lange dauert nach Tag gruppieren & min/max/avg/count von jedem> berechnen?
Zu lange. Für Zeitreihen (time series data) gibt es spezialisierte
Datenbanken, die das besser können. InfluxDB wurde schon genannt.
RRDtool dito. Google findet mit dem genannten Suchwort noch mehr.
9 GB kostet ein müdes Lächeln, ungefähr
so lange dauert es
die von einer SSD ins RAM zu befördern...
Schreibe es einfach in ein (binary) File, und
mach dann ein memory map ins RAM.
DPA schrieb:> Wie lange dauert nach Tag gruppieren & min/max/avg/count von jedem> berechnen?
Ich habe folgende Abfrage für 4 der 32 Spalten erstellt:
SELECT FROM_UNIXTIME(Zeitstempel),
count(*) as Samples,
MIN(Wert1), MAX(Wert1), AVG(Wert1),
MIN(Wert2), MAX(Wert2), AVG(Wert2),
MIN(Wert3), MAX(Wert3), AVG(Wert3),
MIN(Wert4), MAX(Wert4), AVG(Wert4)
FROM testwerte
GROUP BY DATE(FROM_UNIXTIME(Zeitstempel))
Je nach sonstiger Rechnerlast dauerte die Abfrage bei meinen 30 Mio.
Datensätzen zu verschiedenen Zeiten zwischen 1 Minute und 8 Minuten
Soeben z.B.
Meldung des verwendeten HeidiSQL Clients:
Dauer der Abfrage: 00:01:19.6 (+ 0,094 Sek. Netzwerk)
Ich denke, dass man MySQL oder MariaDB für die Datenmenge verwenden
kann.
Vermutlich wird eine spezialisierte Datenbank wie InfluxDB, die zur
Verarbeitung und Auswertung von zeitbasierenden Daten entwickelt wurde,
eine noch bessere Wahl sein.
>Ich habe folgende Abfrage für 4 der 32 Spalten erstellt:
Die Zeiten sind doch voellig ueberzogen. Bei einem flat File bringt die
Platte gegen 500MByte pro Sekunde, daher sollten die Zeiten in den
Sekunden liegen. Aber man kann sich's auch schwer machen.
Name H. schrieb:> flat File
LOL, man kann sichs auch schwer machen.
SQL-Datenbank ist schon das richtige für den Job (filtern, sortieren,
gruppieren, etc), alles andere wäre umständlicher aufwendiger Krampf
hoch 3.
Name H. schrieb:> Die Zeiten sind doch voellig ueberzogen. Bei einem flat File bringt die> Platte gegen 500MByte pro Sekunde, daher sollten die Zeiten in den> Sekunden liegen. Aber man kann sich's auch schwer machen.
Mag sein, dass die Verwendung einer SQL Datenbank überzogen ist.
Ich benötigte etwa 7 Minuten um die nach Tagen sortiereten Werte in
einer scrollbaren Tabelle zu betrachten.
Davon 5 Minuten für den csv Import in die Datenbank. Etwa 20 Sekunden
zur Formulierung und Eingabe der Abfrage und 1,5 Minuten Warten auf das
Ergebnis.
Meine Festplatten können derzeit noch nicht von selst Ergebisse
ausgeben.
Ich muss, wenn ich die Platte bzw. Files direkt nutzen will, ein
Programm für diese Aufgabe schreiben.
SQL Abfragen formulieren kann ich besser, als Programme schreiben.
Ich befürchte, die wenigsten von uns werden es innerhalb von 8 Minuten
schaffen eine funktionierende Routine für die Aufgabe zu schreiben.
rh-doc schrieb:> Davon 5 Minuten für den csv Import in die Datenbank. Etwa 20 Sekunden> zur Formulierung und Eingabe der Abfrage und 1,5 Minuten Warten auf das> Ergebnis.
Jetzt probier InfluxDB dagegen.
Da geht das ohne fühlbare Verzögerung "in Echtzeit".
Im grafana die Zeiteinstellung angeklickt, Maus losgelassen, blinzel,
graph ist aktualisiert. Sicher weniger als ½ Sekunde.
Und davon vergeht noch die meiste Zeit im Webbrowser, nicht in der
Datenbank.
rh-doc schrieb:> Mag sein, dass die Verwendung einer SQL Datenbank überzogen ist.
Das ist doch Schwachsinn.
Es gibt kostenlose, gut getestete SQL-Datenbanken, in die viele 100000
(wenn nicht Millionen) Stunden Entwicklerzeit geflossen ist, mit dem
einzigen Ziel, sie so zuverlässig und effizient wie möglich zu machen.
Nur Vollidoten kämen zu dem Entschluß, diese nicht zu benutzen.
Natürlich kann man für eine sehr konkrete Aufgabe immer auch einen
effizienteren Code schreiben als für den allgemeinen Fall, den
generische SQL-DBs abbilden wollen. Aber kann man ihn auch so gut und
umfassend testen, wie es bei diesen geschieht? Und was passiert, wenn
sich die Anforderungen ändern? Dann ist man schnell in der Situation,
dass eine kompletter Neubau erforderlich wird.
Wie gesagt: Nur Vollidoten kämen zu dem Entschluß, diese nicht zu
benutzen...
Bei 9GB im Jahr kann man sogar ein Textfile verwenden.
Nicht dass eine Datenbank dafür nicht doch eine bessere Lösung wäre,
aber 9GB im Jahr ist echt nicht viel.
Das Werkzeug sollte sich am Problem orientieren. Was aber voraussetzt,
dass man das Problem kennt. Bisher ist Pocahontas allerdings nicht mit
sonderlich viel Information zum Problem rüber gekommen, so dass die
Antworten manches von einem Rorschach-Test haben und jeder das
empfiehlt, was er kennt.
So ist beispielsweise bisher völlig offen, ob die Daten in vollem Detail
auf ewig vorliegen müssen und beliebige Abfragen auf eine beliebige
Auswahl davon möglich sein müssen, oder ob eine Zwischenkondensation der
Daten oder der Abfragen erfolgen kann. Eine spezielle Form davon wurde
kurz über die rrdtools erwähnt.
Wie der Name schon sagt, sind relationale Datenbanken auf Relationen
spezialisiert. Wo keine Relationen sind, sondern einfach bloss ein
grosser Haufen einfachst strukturierter Daten, können sie ebenfalls
geeignet sein, müssen aber nicht die bestmögliche Lösung darstellen.
So hängt es auch ein wenig davon ab, was für Abfragen man macht. Sind
die recht simpel über SQL abdeckbar, oder wird da ohnehin jedesmal der
Datenbestand per Programm abgegrast? Für letzteres ist neben schlichten
Files auch sowas wie die Berkeley DB einsetzbar.
глупний форентроль schrieb im Beitrag #5723507:
> Wenn der Poster kein tyisiertes file zugreifen und die Werte sortieren> kann, soll er's eh sein lassen und vielleicht was anderes machen.> Foerster, Kindergaertner, Jurist Banker, ..
Das ist eine richtig gute Idee: Jeder, der irgend etwas nicht kann, soll
es einfach lassen.
Wenn sich alle Menschen daran halten, leben wir bald wieder alle in
Höhlen und das globale Ökosystem kann sich erholen.
A. K. schrieb:> Wie der Name schon sagt, sind relationale Datenbanken auf Relationen> spezialisiert.
Hähä. Du hast offensichtlich das Konzept und dessen Implikationen völlig
missverstanden.
Natürlich kann ein RDBM auch mit einer einzelnen verschissenen flachen
Tabelle optimal umgehen. Das ist nämlich einfach nur der einfachste
Spezialfall des allgemeinen Falls.
Die DB stellt auch hier alles zur Verfügung, was nötig ist, um auch mit
dieser einen verschissenen Tabelle für jede damit auszuführende
Operation die bestmögliche Lösung zu finden. Und: man muss den Kram
nicht selber implementieren. Die DB stellt hochoptimierte
Implementierungen bereits zu Verfügung, man muss sie einfach nur nutzen.
Typischer Fall für den trivialen Scheiss, der hier als quasi
"Gegenanzeige" zu lesen war: Da richtet man einfach einen B-Tree-Index
auf den Spaltenteil ein und die Abfrage wird gleich um Größenordnungen
schneller ausgeführt.
Man muss halt einfach nur wissen, wie man das konkrete Abfrageproblem am
effizientesten lösen könnte (das muss man sowieso), braucht das dann
aber nicht selbst implementieren, sondern delegiert es einfach mittels
einer einzigen Zeile Quelltext an die SQL-DB, denn die kann das schon...
c-hater schrieb:> Hähä. Du hast offensichtlich das Konzept und dessen Implikationen völlig> missverstanden.
Und du hast meinen Betrag nicht verstanden. Unstrittig ist, dass man
auch mit Kanonen auf Spatzen schiessen kann. Weshalb ich hauptsächlich
auf die offene Frage hinaus wollte, oder das eher Spatz oder eher
Elefant ist, auf das man hier schiesst. Wenn beispielsweise mit rrdtools
sowohl Speicherung als auch grafische Darstellung fix und fertig
abgedeckt werden kann, wozu dann SQL?
Weshalb ich es für sinnvoll halte, erst das Problem zu analysieren, und
dann das Werkzeug auszusuchen. Manche machen das umgekehrt.
Schrauberking schrieb:> rh-doc schrieb:>> Davon 5 Minuten für den csv Import in die Datenbank. Etwa 20 Sekunden>> zur Formulierung und Eingabe der Abfrage und 1,5 Minuten Warten auf das>> Ergebnis.>> Jetzt probier InfluxDB dagegen.
Das klingt irgendwie nicht so, als ob in der Tabelle der richtige Index
angelegt wäre.
Sven B. schrieb:> Das klingt irgendwie nicht so, als ob in der Tabelle der richtige Index> angelegt wäre.
Genau. Hier hat jemand nicht die gigantischen Optimierungsmöglichkeiten
verstanden, die ihm absolut kostenlos zu Verfügung stehen, die er
einfach nur für seine konkrete Anwendung nutzbar machen muss.
Wahnsinn: eine einzige Zeile Befehl an die DB und alle zukünftigen
(gleichgestrickten) Abfragen laufen um viele Größenordnungen schneller.
Wer diese Vorteile nicht begreift, ist echt arm dran...
Nun. Wenn man in einer Datenbank Minimum und Maximum sucht, muss man
alle Records anschauen. Da bringt ein Index gar nichts. Da ist ein
flaches File am schellsten
глупний форентроль schrieb:> Nun. Wenn man in einer Datenbank Minimum und Maximum sucht, muss man> alle Records anschauen. Da bringt ein Index gar nichts. Da ist ein> flaches File am schellsten
Hä? Wenn ich eine sortierte Liste aller Werte habe, kann ich das zum
Beispiel in konstanter Zeit und muss genau 2 Einträge anschauen.
c-hater schrieb:> Wahnsinn: eine einzige Zeile Befehl an die DB und alle zukünftigen> (gleichgestrickten) Abfragen laufen um viele Größenordnungen schneller.
Welche Zeile muß ich denn Deiner geschätzten Erfahrung nach eingeben,
damit die einzelnen Spalten noch besser als B-Tree indiziert werden?
c-hater schrieb:> Hier hat jemand nicht die gigantischen Optimierungsmöglichkeiten> verstanden
Kennst Du mich?
Hallo глупний форентроль,
глупний форентроль schrieb:> Nun. Wenn man in einer Datenbank Minimum und Maximum sucht, muss man> alle Records anschauen. Da bringt ein Index gar nichts. Da ist ein> flaches File am schellsten
Die Suche in einem flachen File kostet Dich O(n).
Die Suche in einer Datenbank mit Indexierung an der richtigen Stelle
liegt eher in der Größe O(log(n)).
Ich würde auf diesen Vorteil nicht verzichten.
Beispiel:
Flat-File mit 9GB, 4 Byte/Wert, macht dan 2,25E9 Werte in der Datei.
Im Schnitt bedeutet das 1,125E9 Werte anfassen, schlimmstenfalls 2,25E9
Werte.
Ein einfach Binärbaum, der natürlich Speicherplatz kostet, braucht
log2(2,25E9) = ~31 Zugriffe.
Überzeugt? :)
c-hater schrieb:> Es gibt kostenlose, gut getestete SQL-Datenbanken, in die viele 100000> (wenn nicht Millionen) Stunden Entwicklerzeit geflossen ist, mit dem> einzigen Ziel, sie so zuverlässig und effizient wie möglich zu machen.
Das ist richtig. Trotzdem gibt es für spezielle Daten auch wieder
spezialisierte Datenbanken, die es schneller und besser können.
Zeitreihen-Daten sind ein klassisches Beispiel. DNA wäre ein weiteres.
Und glaub mir, ich weiß wovon ich rede. SQL Datenbanken sind mein
tägliches Brot.
> Nur Vollidoten kämen zu dem Entschluß, diese nicht zu benutzen.
Nur Vollidioten verwenden für jedes Problem den Hammer. Fortgeschrittene
haben einen besser ausgestatteten Werkzeugkasten und verwenden das für
die jeweilige Aufgabe am besten geeignete Werkzeug.
rh-doc schrieb:> Welche Zeile muß ich denn Deiner geschätzten Erfahrung nach eingeben,> damit die einzelnen Spalten noch besser als B-Tree indiziert werden?
In Deinem Fall wären es wohl zwei Zeilen:
1
DROP INDEX 'Zeitstempel';
2
CREATE INDEX `Zeitstempel` ON `testwerte` (DATE(FROM_UNIXTIME(`Zeitstempel`)));
c-hater schrieb:>> Mag sein, dass die Verwendung einer SQL Datenbank überzogen ist.>> Das ist doch Schwachsinn.>> Es gibt kostenlose, gut getestete SQL-Datenbanken, in die viele 100000> (wenn nicht Millionen) Stunden Entwicklerzeit geflossen ist, mit dem> einzigen Ziel, sie so zuverlässig und effizient wie möglich zu machen.>> Nur Vollidoten kämen zu dem Entschluß, diese nicht zu benutzen.
Aber die sind in C geschrieben, wie verträgt sich das mit Deinen
Überzeugungen?
A. K. schrieb:> Wie der Name schon sagt, sind relationale Datenbanken auf Relationen> spezialisiert.
Ja, die sind auf Tabellen spezialisiert. Daher der Name.
> Wo keine Relationen sind, sondern einfach bloss ein> grosser Haufen einfachst strukturierter Daten
Klingt für mich aber durchaus wie eine Tabelle. Warum soll das keine
Tabelle sein?
Ein anderes Wort für Tabelle ist übrigens Relation. Es gibt Datenbanken
die Daten in Tabellen verwalten, diese bezeichnet man als "Relationale
Datenbanken", ein gleichwertiger Begriff dafür wäre "Tabellenbasierte
Datenbanken". Scheint mir eigentlich der perfekte Ort zu sein um eine
große Tabelle fester Struktur aufzubewahren und damit zu arbeiten.
Bernd K. schrieb:> Aber die sind in C geschrieben, wie verträgt sich das mit Deinen> Überzeugungen?
Sehr gut. Denn natürlich: wirkliche kritische Teile gibt's dann doch
wieder in der ultimativen Sprache der jeweiligen Zielhardware, also in
Assembler. Weil's halt garnicht anders geht.
Du hast vermutlich einfach nur nicht richtig verstanden, was meine
Überzeugungen und Intententionen sind, obwohl ich das schon mehrfach
relativ ausführlich dargestellt habe...
db6 schrieb:> Wurde schon DB2 für win/linux empfohlen?
Gibt es nicht mehr. Es heißt jetzt nicht "DB2", sondern "Db2".
> Leider TEUER
Db2 Developer-C ist bis 100 GB kostenlos. (Oracle XE: 12 GB; SQL Server
Express: 10 GB)
> Überzeugt?
Eine Suche in einem Binaerbaum bringt ja erst etwas wenn ich diesen
Binaerbaum habe ... und er muss sortiert sein.
Ich bin davon ausgegangen, man hat die Daten in zetlicher Abfolge, sucht
Min & Max und weg damit. Dann muss ich auch nicht sortieren.
Über die Art der Abfragen im Startbeitrag ist exakt nichts bekannt. Die
min/max-Abfrage war ein Beispiel einer anderen Person. Deshalb ja mein
Hinweis auf die Sinnlosigkeit bekannter Lösungen für völlig unbekannte
Probleme.
