SQlite Zugriffe auf SD für Raspi optimieren?

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

SQlite Zugriffe auf SD für Raspi optimieren?

Beitrag von Timm Thaler »

Ich möchte zwei Datenbanken auf dem Raspi anlegen. Darin sollen Temperaturdaten usw. geloggt werden.

Erste Datenbank: Tagesverlauf in 5-Minuten-Abständen, ergibt 288 Datensätze pro Tag. Ergibt ungefähr 1MB an Daten im Monat. Datensätze, die älter als 30 Tage sind, sollen gelöscht werden.
Zweite Datenbank: Jahresverlauf aus den Daten der ersten Datenbank, Mittelwerte, Min-Max-Werte, kumulierte Laufzeiten usw. Ergibt 365 Datensätze pro Jahr. Jedes Jahr soll eine neue Datenbank angelegt werden.

Im Raspi habe ich eine 32GB SD-Karte. Für die möchte ich die Schreibzugriffe minimieren. Daher möchte ich verstehen, wie SQlite-Datenbanken unter Lazarus verwaltet werden.

1. Wenn ich alle 5 Minuten einen Datensatz zufüge, wird dann nur der Datensatz geschrieben, oder wird jedesmal die komplette Datenbank geschrieben?
2. Wenn ich die alten Datensätze lösche, wird dabei die Datenbank komplett neu geschrieben?
3. 30 Tage mal 288 Datensätze klingt jetzt nicht so viel, sind aber auch fast 9000 Datensätze. Kann man das problemlos handhaben? Die Datenbank wird ja, wenn ich es richtig verstanden habe, von Lazarus komplett im RAM vorgehalten, das wären dann etwa 1-2MB, je nachdem welches Datenformat ich wähle (für Temperaturwerte mit 0.1°C Auflösung im Bereich -50 bis 250°C scheint mir real etwas überdimensioniert, das würde auch als Festkommazahl in 2 Byte passen, aber real ist wahrscheinlich am Einfachsten).

Gibt es einen einfachen Datenbankviewer für den Raspi, mit dem ich die gespeicherten Werte überprüfen kann?

Disclaimer: Ich habe bisher weder mit SQlite noch mit anderen Datenbanken gearbeitet.

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: SQlite Zugriffe auf SD für Raspi optimieren?

Beitrag von Timm Thaler »

Ich hab jetzt noch was zu Round-Robin-Datenbanken gelesen. Das würde ja für meinen Zweck auch passen, denn die Datenmenge pro 30 Tage bzw. pro Jahr ist ja bekannt.

Allerdings müssen auch diese Daten geschrieben werden.

Oder mache ich mir da zu viele Sorgen wegen der SD-Karte bei diesen Datenmengen? Was wird denn sonst so vom Betriebssystem während der Laufzeit geschrieben (Protokolle, Cache für Update usw.)?

Andererseits habe ich schon gelesen, dass sich Leute mit MySQL-Datenbanken auf dem Raspi in wenigen Monaten die SD-Karte ruiniert haben.

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: SQlite Zugriffe auf SD für Raspi optimieren?

Beitrag von Socke »

Die Frage ist, wie du auf die Datenbank zugreifst. Wenn du die SQLDB- oder Zeos-Komponenten verwendest, können diese die gesamten Daten im Speicher puffern, sodass du nur z.B. einmal am Tag die Daten tatsächlich auf die SD-Karte wegschreibst. Stürzt dein Programm zwischen zwei Sicherungen ab (z.B. Stromausfall) sind natürlich alle Daten seit der letzten Sicherung verloren.

Auf der anderen Seite sollten 9000 Schreibvorgänge die SD-Karte auch nicht übermäßig belasten - zumal diese sowieso anders berechnet werden müssen:
  • Bei jeder Änderung, die du an eine Datenbank übergibst, wird diese in einem "Log" gespeichert. Das ist in der Regel eine Datei auf der SD-Karte. Diese kannst du aber auch abschalten.
  • Die Datenbank ändert immer einen Speicherblock (eine Seite oder Page). In einem solchen Speicherblock sind in der Regel mehrere Datensätze untergebracht. Die Anzahl der Datensätze kann für unterschiedliche Tabellen unterschiedliche sein (je nach Größe eines Datensatzes).
  • Die Datenbank übergibt den geänderten Speicherblock an das Betriebssystem, um diesen auf der Datenbank-Datei wegzuschreiben. Hierbei ist auf dem Dateisystem festgelegt, wie groß die kleineste zu lesende oder zu schreibende Einheit, die sogenannte Clustergröße, ist. Ist diese Clustergröße größer als die Datenbank-Seite, wird auch mehr als die eine geänderte Datenbankseite geschrieben. Ist die Clustergröße kleiner als eine Datenbank-Seite, muss das Dateisystem mehrere Schreiboperationen durchfürhen.
  • Zuletzt ist auch der Flash-Speicher in der SD-Karte in Blöcke aufgeteilt. Die Größe der Flash-Blöcke ist durch den Hersteller festgelegt und nicht änderbar. Der Controller-Chip kennt diese Größe und entscheidet selbsständig, auf welchen Flash-Block die geänderte Dateisystem-Cluster gespeichert wird. Bei ein und der selben Datei wird üblicherweise bei jedem Schreibvorgang ein anderer Flash-Block verwendet. Dadurch nutzen sich die einzelnen Flash-Blöcke gleichmäßig ab, sodass die gesamte SD-Karte länger hält.

Timm Thaler hat geschrieben:Oder mache ich mir da zu viele Sorgen wegen der SD-Karte bei diesen Datenmengen? Was wird denn sonst so vom Betriebssystem während der Laufzeit geschrieben (Protokolle, Cache für Update usw.)?

Andererseits habe ich schon gelesen, dass sich Leute mit MySQL-Datenbanken auf dem Raspi in wenigen Monaten die SD-Karte ruiniert haben.

Bei deinen Datenmengen: ja. Auch eine MySQL-Datenbank lässt sich problemlos betreiben, wenn man keine Daten ändert ;-)
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

creed steiger
Beiträge: 957
Registriert: Mo 11. Sep 2006, 22:56

Re: SQlite Zugriffe auf SD für Raspi optimieren?

Beitrag von creed steiger »

Ich hab hier sowas auf einem Pi laufen.
Es werden minütlich 5 Messwerte in eine Firebird Datenbank geschrieben.
Seit einem 3/4 Jahr und keinerlei Probleme.

Sichern kann natürlich nicht schaden.


Als ich das damals aufgesetzt habe, habe ich erstmal den I/O mit iotop kontrolliert.
Dann /var/log und /tmp in Ramdisks ausgelagert weil die Logfiles das höchste Schreibaufkommen hatten.
Auch mit systemd war da noch ein Problem, das die Logfiles vollgemüllt wurden.

Die Datenbank gleich in eine Ramdisk wäre auch eine Möglichkeit, periodisch auf Stick und/oder Netzlaufwerk sichern.

Ein TinyCore Linux das kpl. im Speicher läuft fällt mir da auch noch ein.

Antworten