Laden...

Wo und wie speichert man am besten große Datenmengen?

Erstellt von PierreDole vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.577 Views
P
PierreDole Themenstarter:in
74 Beiträge seit 2017
vor 4 Jahren
Wo und wie speichert man am besten große Datenmengen?

Moin,
ich möchte große Datenmengen speichern und bin mir nicht sicher, wie ich das anstellen soll. Es handelt sich um Telemetriedaten einer Rennsimulation. Es sind zwar nicht viele Daten auf einmal, 10 Datensätze mit ca 10 Zeichen pro Satz, aber ich bekomme sie 60 mal in der Sekunde, bei einer Renndauer von ca 30 Minuten. Das wären 108.000 Einträge, und zwar pro Rennen!

Was eignet sich am besten zum Speichern dieser Daten? Eine Datenbanktabelle wird im Nu riesengroß. Nach 10 Rennen hätte die Tabelle über eine Million Einträge. Oder sollte ich für jedes Rennen eine neue Tabelle anlegen? Dann wird aber die Datenbank irgendwann sehr groß und mit der statistischen Auswertung wäre es auch kompliziert. Da muss es eine bessere Möglichkeit geben.

Apropos Statistik: Wie verfahre ich da am besten? Macht es Sinn die Statistik zur Laufzeit zu berechnen und separat zu speichern?

Und dann würde ich noch gerne wissen, wie ich diese Daten speichere. Daß ich nicht 60 Mal in der Sekunde auf den Speicherort zugreifen sollte, ist mir bewusst (korrigiert mich, wenn ich falsch liege). Es muss also ein Datenpool her. Wie groß sollte er sein, bzw wie oft sollte ich speichern? Ich meine, je öfter ich speichere, desto mehr arbeitet der Rechner und je seltener ich speichere, desto größer die Datenmenge im Speicher. Gibt es da eine Faustformel für ein Optimum?

16.806 Beiträge seit 2008
vor 4 Jahren

108.000 mag sich für dich viel anhören - für Datenbanken ist das ein Klacks.
Das sind prinzipiell so wenig Daten, dass sich eine auf Telemetrie-Daten spezialisierte Datenbank (Timeseries Databases) nicht Mal wirklich lohnt, wenn Du nicht eh schon eine hast.
Übliche Datenbanken wie mssql oder PostgreSQL haben keine einfachen Tabellenlimits, sondern die Anzahl der Zeilen richtet sich i.d.R. nach der Wahl des Keys.

Du kannst hier auch normalerweise (kommt natürlich auch immer auf die Datenbank-Kiste an) ungepuffert in die Datenbank schreiben bzw. das dem Datenbank-Treiber überlassen.
Weil auch I/O mäßig sind 60 Einträge pro Sekunde nichts.
MSSql schafft auf meiner kleinen NAS mit Docker problemlos 80.000 Einträge pro Sekunde - und die hat nur ein Core und 500 MB RAM (wobei ich glaube, dass der Flaschenhals hier nicht Mal die Datenbank, sondern der IO Controller der NAS ist).

Diese ganzen "Sinn-Fragen" kann man aber im Prinzip nicht pauschal beantworten.
Wenn Du eine Live-Analyse willst, dann arbeitet man i.d.R. mit Streaming.
Es ist quasi einfach nur eine Mischung von Technologien.

Aber viele Daten sind das nicht 😃

S
324 Beiträge seit 2007
vor 4 Jahren

Wie Abt schon sagt, würde man für solche Temetriedaten eine TimeseriesDb nutzen. Ich persönlich habe sehr gute Erfahrungen mit InfluxDb (https://www.influxdata.com) gemacht.
Wir nutzen Influx Hauptsächtlich dafür Sensordaten von IoT-Geräten zu sammeln und zu analysieren.
Das schöne daran ist, das man mit Chronograf ein Web Frontend dazu bekommt in dem man direkt die Daten auswerten und Grafisch als Diagramme und Dashboards anzeigen lassen kann.
Influx ist in Go geschrieben, hat keine Abhängigkeiten und ist für jede Plattform verfügbar.

Wenn es um die Menge der Daten in Bezug auf die Speichergröße der DB ankommt (Influx hat da auch ein sehr effizientes Speicher-Format), lohnt sich eventl. auch ein Blick auf MongoDB. in MongoDb gibt es inzwischen 3 verschiedene Komprimierungs-Einstellungen wie Daten in der DB komprimiert werden können.
Wir nutzen MongoDb z.B. dazu Protokoll-Dateien und Schnittstellen-Dateien durchsuchbar zu Archivieren oder Inhalte von "alten" Tabellen zu Archivieren.
So haben wir z.B. Erfahrungen gemacht wo wir den Inhalt einer 461MB DBase Datei in MongoDb übernommen haben und darin komprimiert für die selben Daten nur noch Speicherplatz von 18MB brauchen.

P
PierreDole Themenstarter:in
74 Beiträge seit 2017
vor 4 Jahren

Ich bin sehr überrascht, daß diese Datenmengen nicht viele sind. Ich hatte aber auch nie wirklich davor damit zu tun gehabt. 😃

Vielen Dank für eure Einschätzung und Vorschläge. Ich werde mich erstmal in diese Datenbanken einlesen und mir einen Überblick verschaffen.