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
SQlite kann bis 140 TB, ist open source, weit verbreitet und sehr ausgereift.
InfluxDb ist auf Zeitreihen optimiert und eventuell einen Blick wert.
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.
Wie lange dauert nach Tag gruppieren & min/max/avg/count von jedem berechnen? Ungetestet:
1 | select timestamp, count(*) as samples, min(value), max(value), avg(value) from my_table GROUP BY DATE(timestamp) ORDER BY timestamp; |
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.
Beitrag #5723507 wurde von einem Moderator gelöscht.
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.
Schrauberking schrieb: > Jetzt probier InfluxDB dagegen. Hört sich gut an, das werde ich bestimmt mal ausprobieren.
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.
:
Bearbeitet durch User
глупний форентроль 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Indizez.png
4,4 KB
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? :)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
Wurde schon DB2 für win/linux empfohlen? Leider TEUER, sonst sehr gut.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.