SQLite Überlauf des Speichers verhindern

[ScooB]

Hi,

ich habe mal ne Frage wie man es realisieren kann wenn ich dauerhauft in eine SQLiteDB schreibe und meine DB irgendwann so groß ist das kein Speicherplatz vorhanden ist das ich dann die ältesten Daten lösche.

Ich müsste wissen ob ich über SQLite den Speicherplatz abfragen kann oder ob ich ne eigene Funktion zu überwachung schreiben müsste.

Gruß ScooB

[BlackJack]

@ScooB: So etwas ist üblicherweise jenseits der Abstraktionsschicht die ein DBMS bietet. Das wirst Du mit den ganz normalen Bertriebssystem-Mitteln lösen müssen. Also schauen ob auf dem Dateisystem auf dem die DB-Datei liegt der Platz knapp wird, oder deren Grösse überwachen. Und dann ist es mit dem löschen von Daten nicht getan, denn dadurch wird die Datei nicht kleiner, sondern Du musst das DBMS auch noch anweisen die Daten neu zu organisieren. Dafür gibt es keine Anweisung im SQL-Standard, aber SQLite kennt eine eigene Anweisung: VACUUM. Aber Achtung: Dafür kann bis zu zweimal der Speicherplatz den die DB bereits belegt benötigt werden, und die gesamte DB wird kopiert und neu angeordnet geschrieben. Das kann also bei grossen DBs relativ lange dauern.

Alternativ könntest Du Dir den `auto_vacuum` Modus von SQLite anschauen.

[Gregorrr]

Hi,

ich habe mal ne Frage wie man es realisieren kann wenn ich dauerhauft in eine SQLiteDB schreibe und meine DB irgendwann so groß ist das kein Speicherplatz vorhanden ist das ich dann die ältesten Daten lösche.

Ich müsste wissen ob ich über SQLite den Speicherplatz abfragen kann oder ob ich ne eigene Funktion zu überwachung schreiben müsste.

Gruß ScooB

Also eine SQLite DB kann bis zu 14 TByte groß werden. Was hast du vor? oO
Ansonsten kannst du dir ein Script in Python schreiben, ausserhalb der db, dass den Speicherplatz auf der Platte verwaltet.

[jens]

Viellicht LOG Ausgaben in DB schreiben und alte nicht löschen?

[BlackJack]

@Gregorrr: Die DB mag 14 TiB gross werden, aber die darunter liegende Platte wächst ja nicht auf magische Weise. Oder hast Du nur noch 14+ TiB-Platten im Einsatz‽

[ScooB]

Also so groß soll es schon net werden

Sagen wir mal ich würde es auf einem USB Stick speicher oder SD Karte und ich hätte 1GB Speicherplatz

also so habe ich mir das auch schon gedacht mit ner Überwachung die dann das ganze verwaltet

[ScooB]

Seh ich das richtig

wenn ich 1000 Einträge in der DB habe ist sie sagen wir mal 1MB groß jetzt lösch ich 500 Einträge bleibt sie 1MB groß,
wenn ich jetzt wieder 500 Einträge hinzufüge ist sie immer noch 1 MB groß oder?

Gruß

[BlackJack]

@ScooB: Das könnte so sein. Muss aber nicht. Man kann vielleicht davon ausgehen, dass die Datei nicht kontinuierlich wächst wenn man immer wieder Datensätze löscht, oder zumindest nur wenig, aber sicher sein kannst Du da nur wenn das irgendwo explizit in der Dokumentation steht.

[jens]

Bei MySQL kann man auch explizit "Aufräumen"... Evtl. gibt es das bei SQLite auch?

[BlackJack]

@jens: Ja, die VACUUM-Anweisung die ich schon erwähnte. Man sollte aber aufpassen das dafür bis zu doppelt so viel Platz der aktuellen Grösse *zusätzlich* benötigt werden kann.

[Gregorrr]

OK, bei sehr beschränktem Platz z.B. auf einem Stick macht es Sinn.

Die Standardeinstellungen sind bei SQLite, dass die Datenbank-Datei beim Löschen nicht schrumpft. D.h. nach dem Löschen bleibt die Größe der Datei enthalten.

Es gibt noch ein PRAGMA auto_vacuum, dass es ermöglicht, dass die Datenbank-Datei nach dem Löschen schrumpft automatisch. Diese PRAGMA ist standardmäßig ausgeschaltet. Man muss dieses einschalten, bevor man jegliche Tabelle erstellt.

Das Problem mit auto_vacuum ist, dass es bei einer 50 MB db-Datei bis zu > 1 Minute Aufräumarbeit dauern kann. [http://liferea.blogspot.de/2008/08/why- ... -good.html]

Wenn das kein Problem für dich darstellt, dass es ab und zu laggy sein kein. Schalt das PRAGMA ein.

[Leonidas]

@Gregorrr: Die DB mag 14 TiB gross werden, aber die darunter liegende Platte wächst ja nicht auf magische Weise. Oder hast Du nur noch 14+ TiB-Platten im Einsatz‽

Das ist ja egal wie groß die Platte ist, mit LVM & Co. sind 14+ TiB jetzt auch nicht so teuer. Vor nem Jahr 6 oder 8 TB mit RAID zusammengesetzt, die Festplattenpreise waren ja durchaus bezahlbar.

[/me]

Vor nem Jahr 6 oder 8 TB mit RAID zusammengesetzt, die Festplattenpreise waren ja durchaus bezahlbar.

Vor über 10 Jahren mehrere TB aus massenhaft 9GB SCSI-Platten zusammengebaut. Das ging auch - bis im Serverraum die Klimaanlage ausfiel ...

[Leonidas]

Naja, 6x3TB Platten sind jetzt auch kein so großes Ding, finde ich.

[BlackJack]

@Leonidas: Finde ich schon. Vielleicht bin ich auch einfach zu arm und mag mir nicht einen neuen Rechner kaufen wo die dann auch reinpassen würden.

[noisefloor]

Hallo,

wie viel Daten schreibst du denn? Ein DB mit 500 MB "nur Textdaten" (also keine großen Binärdateien) ist schon ziemlich viel. Zumindest, wenn du nicht gerade von Entreprise-Anwendungen redest.

Gruß, noisefloor

[ScooB]

@noisefloor

also die DB wird bis ca 8GB groß werden es werden Messwerte aus einer DB gelesen und diese sollen über einen Zeitraum gespeichert bleiben