Forum: PC-Programmierung Messdaten speichern


von Harald J. (Gast)


Lesenswert?

Hallo zusammen. Ich brauche mal ein paar Tipps. Ich möchte Messdaten so 
bis 20GB speichern und übertragen. Das Schema ist fest. Die 
Übertragungsdauer ist erstmal egal weil das nur gespeicherte Dateien 
sind. Beim messen sollen diese Daten Direkt in den Massenspeicher 
geschrieben werden aber im RAM vorhalten geht aufgrund der Größe nicht. 
Später soll gelesen werden und zwar ohne die ganze Datei im RAM zu 
haben. Bisher habe ich das immer mit flatbuffers gemacht aber die müssen 
zum schreiben im RAM sein (Lesen geht durch memory mapped files ohne 
RAM).

Was wäre die präferierte Lösung? Eine SQL Datenbank?

von Mark B. (markbrandis)


Lesenswert?

Harald J. schrieb:
> Ich möchte Messdaten so bis 20GB speichern

Das an sich sollte auf einem PC kein Problem sein; es gibt schon lange 
hinreichend große Festplatten dafür.

> und übertragen.

Wohin übertragen? An einen anderen PC? Über was für eine Schnittstelle? 
?

> Beim messen sollen diese Daten Direkt in den Massenspeicher
> geschrieben werden aber im RAM vorhalten geht aufgrund der Größe nicht.

Muss ja auch nicht? Solange die Datei zum Schreiben geöffnet ist, und 
nicht mehr Daten pro Zeiteinheit anfallen als die Festplatte 
"wegschreiben" kann, sehe ich hier kein Problem.

Etwas anderes wäre es, wenn die 20 GB an Daten innerhalb einer sehr 
kurzen Zeit anfallen würden. Davon gehe ich jetzt aber mal nicht aus, 
weil es so nicht beschrieben wurde.

: Bearbeitet durch User
von Peter M. (r2d3)


Lesenswert?

Harald J. schrieb:
> Was wäre die präferierte Lösung? Eine SQL Datenbank?

Je nach geheimen Verwendungszweck kann eine Binärdatei, 
editorenfreundliche CSV- oder XML-Dateien aber auch eine Datenbank 
präferiert werden.

von dbase0 (Gast)


Lesenswert?

Harald J. schrieb:
> Was wäre die präferierte Lösung? Eine SQL Datenbank?

Eine TSDB? Z.B. InfluxDB

von georg (Gast)


Lesenswert?

Peter M. schrieb:
> Je nach geheimen Verwendungszweck

Kommt ganz drauf an, wie die Daten strukturiert sind - einfach Messwert 
nach Messwert oder wahlfreier Zugriff nötig - und wie sie abgerufen 
werden sollen - einfach so wie sie gespeichert wurden, dann braucht man 
kein SQL, oder wie sonst?

Bitte noch ein paar Salamischeiben.

Georg

von Gret (Gast)


Lesenswert?

f=Fileopen()
 writefile(f,blaaa);
 closefilef(f)

Jetzt aber weg mit dem Troll

von Mark W. (kram) Benutzerseite


Lesenswert?


von MaWin (Gast)


Lesenswert?

Harald J. schrieb:
> Eine SQL Datenbank

Sollen die Daten irgendwie anders übertragen werden, als sie beim Messen 
angefallen sind ?

Irgendwie datensatzübergreifend umsortiert, gruppiert, aufbereitet, 
zusammengefasst, selektiert ?
Nein, dann macht eine Datenbank keinerlei Sinn.

Memory mapped file geht ja nur auf Systemen mit virtueller 
Speicherverwaltung, läuft das ganze also mindestens auf einem PC ?

Wie bekommt der Messdaten

Harald J. schrieb:
> messen sollen diese Daten Direkt in den Massenspeicher geschrieben
> werden

dass hin ? Ohne Umweg über RAM, Software, bleibt ja nur DMA zu DMA 
fähigem Massenspeicher.

Das kann ein PC eher nicht.

Obwohl deine Grundanforderung, Messdaten bei der Erfassung auf einen 
Massenspeicher (SDCard, Festplatte) zu schreiben um sie auf Wunsch 
wieder auszulesen und irgendwohin zu übertragen (TCP/IP oder USB ?) ja 
äusserst primitiv ist und mit Buffern in Sektorgrösse des 
Massenspeichers im RAM auskommt, sind deine sonstigen Anforderungen 
abstrus und verkomplizierend. Ist das wirklich nötig ?

von Bastler (Gast)


Lesenswert?

Harald J. schrieb:
> Beim messen sollen diese Daten Direkt in den Massenspeicher
> geschrieben werden aber im RAM vorhalten geht aufgrund der Größe nicht.
> Später soll gelesen werden und zwar ohne die ganze Datei im RAM zu
> haben. Bisher habe ich das immer mit flatbuffers gemacht aber die müssen
> zum schreiben im RAM sein

Mach halt Chunks, z.B. 1 GB groß. Dazu mit Flatbuffer eine übergeordnete 
Struktur, um die Chunks zu verwalten. Geht ja mit Flatbuffer easy.

Im einfachsten Fall speicherst Du in jedem Chunk eine Stream-ID, die Du 
beim Start des Streams erzeugst und eine laufende Nummer. Im letzten 
Chunk noch ein Flag, dass es der letzte Chunk war.

Dein Softwareschicht zwischen Stream und Flatbuffer muss halt immer wenn 
ein Treshold an geschriebenen Datensätzen rum ist, den aktuellen Chunk 
auf Platte schreiben und den nächsten Chunk starten. Nichts wildes.

Wenn Du willst, machst Du noch eine Index-Datei in der die einzelnen 
Chunks referenziert werden. Brauch man aber nicht unbedingt. Kommt halt 
drauf an, was man will...

Bitte 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
Noch kein Account? Hier anmelden.