Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[BananaJoe]

@bahnuhr ich hätte die Anleitung jetzt so verstanden das er das jedesmal anwendet wenn ein Wert geschrieben wird ... mhh

[bahnuhr]

@bananajoe sagte in SQL - Aufbewahrungsdauer:

@bahnuhr ich hätte die Anleitung jetzt so verstanden das er das jedesmal anwendet wenn ein Wert geschrieben wird ... mhh

ja ich auch.
Klappt aber nicht.
Habe nun meine sql Datenbank (ca. 1,1 GB groß) komplett gelöscht und fange mit einer neuen komplett von 0 an.

issue angelegt:
https://github.com/ioBroker/ioBroker.sql/issues/293

[Gaspode]

@bahnuhr
Ich kann bestätigen, dass die Löschung zeitverzögert - wie von apollon77 im Guthub Issue beschrieben - funktioniert. Ein Adapterneustart war nicht erforderlich. Ich habe für einen Datenpunkt mit Daten von 12 Monaten den Zeitraum auf 6 Monate gesetzt und nach wenigen Stunden waren die älteren Daten weg.

[bahnuhr]

@gaspode sagte in SQL - Aufbewahrungsdauer:

@bahnuhr
Ich kann bestätigen, dass die Löschung zeitverzögert - wie von apollon77 im Guthub Issue beschrieben - funktioniert. Ein Adapterneustart war nicht erforderlich. Ich habe für einen Datenpunkt mit Daten von 12 Monaten den Zeitraum auf 6 Monate gesetzt und nach wenigen Stunden waren die älteren Daten weg.

So, ich glaube bei mir sind die Daten nun offensichtlich auch gelöscht.

Dies hat aber nicht zu Verringerung der Dateigröße geführt !
Weiterhin 1,1 GB.

Was bedeutet dies nun:
Im flot werden die Daten nicht mehr angezeigt.
Dies hat aber nicht wirklich zur Dateigrößenreduzierung geführt.

Ist also nicht unbedingt der sinnvolle Weg.
Wenn die Daten gelöscht sind, dann muss ! dies auch zur Reduzierung der Dateigröße führen.
Ansonsten hat das ganze keinen Sinn.

Noch jemand eine Idee ?

[Gaspode]

@bahnuhr said in SQL - Aufbewahrungsdauer:

Dies hat aber nicht zu Verringerung der Dateigröße geführt !
Weiterhin 1,1 GB.

Dafür kann der Adapter nix. Wenn du mySQL benutzt, empfehle ich

https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

[bahnuhr]

@gaspode sagte in SQL - Aufbewahrungsdauer:

Dafür kann der Adapter nix. Wenn du mySQL benutzt, empfehle ich

https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

Wenn nicht der Adapter, wer denn sonst ?
Benutze ja nur diesen.

Genauer:
sqlite.

[Gaspode]

@bahnuhr said in SQL - Aufbewahrungsdauer:

Wenn nicht der Adapter, wer denn sonst ?

Weil das mit relationalen Datenbanken nicht ganz so einfach ist. Da spielen viele Faktoren eine Rolle. Die Dateigröße hat da in der Regel nicht höchste Priorität. sqlite hab ich noch nie benutzt, da gibt es aber sicher ähnliche Mechanismen wie optimize table in mysql.

Edit: Hier ist ja die offizielle Doku:
https://www.sqlite.org/lang_vacuum.html

[bahnuhr]

@gaspode sagte in SQL - Aufbewahrungsdauer:

Weil das mit relationalen Datenbanken nicht ganz so einfach ist. Da spielen viele Faktoren eine Rolle. Die Dateigröße hat da in der Regel nicht höchste Priorität. sqlite hab ich noch nie benutzt, da gibt es aber sicher ähnliche Mechanismen wie optimize table in mysql.

Das ist mir zu hoch.
Ich benutze den Adapter sql; und dort Einstellung sqlite.
Keine Extra Installation oder sonstwas.

Ich bin der Meinung, das sollte schon Adapter kommen.

Aber egal. Bleibt wieder meine 1. Lösung
Datenbank löschen und neu aufbauen lassen.
Dann ist sie wieder klein.

[bahnuhr]

@gaspode

Dein 1. Link war wenigstens in Deutsch.
Der Link der jetzt da steht versteh ich noch weniger.

Ist somit kein Weg für mich.
Bleibt löschen und neu.

Trotzdem danke.

[Gaspode]

@bahnuhr
Du kannst auch einfach selbst nach sqlite und vacuum googleln.

Zur Erklärung: Die meisten Datenbanken (und auch sqlite) verkleinern ihre Dateien meist nicht direkt, wenn Daten gelöschte werden, sondern behalten den Platz, um dort zukünftig wieder Daten abzuspeichern. Manche Datenbanken haben Strategien, mit denen Speicher automatisch freigegeben werden kann, in der Regel ist das aber eher selten. Will man Dateien verkleinern, muss man das manuell machen. Datenbankadministrator (DBA) ist ein eigenständiger Beruf, der sich bei großen Datenbanken um solche Aufgaben kümmert. Will man viele Daten performant in einer Datenbank ablegen, muss man sich über kurz oder lang leider damit beschäftigen.

Hier noch ein Link mit deutscher Erklärung:
https://runebook.dev/de/docs/sqlite/lang_vacuum

Davon abgesehen: Wenn du innerhalb kürzester Zeit so viele Daten zusammen bekommst, ist sqlite wohl nicht die beste Wahl. Aus der ioBroker Doku:

SQLite ist eine Version mit reduziertem Umfang und kann gut zum Testen oder geringe Datenmengen verwendet werden. Sobald parallel Daten geschrieben und gelesen werden sollen (z.B. Flot) kann es zu Problemen kommen weil hier immer nur eins von beiden zeitgleich möglich ist.

[bahnuhr]

@gaspode sagte in SQL - Aufbewahrungsdauer:

Davon abgesehen: Wenn du innerhalb kürzester Zeit so viele Daten zusammen bekommst, ist sqlite wohl nicht die beste Wahl. Aus der ioBroker Doku:
SQLite ist eine Version mit reduziertem Umfang und kann gut zum Testen oder geringe Datenmengen verwendet werden. Sobald parallel Daten geschrieben und gelesen werden sollen (z.B. Flot) kann es zu Problemen kommen weil hier immer nur eins von beiden zeitgleich möglich ist.

Ja den Text kenn ich.

Aber die DB hatte nun ja Daten gesammelt von ca. 1 Jahr.

[Dr. Bakterius]

@bahnuhr Da ist dann noch die Frage wie viele Datenpunkte du aufzeichnen lässt, in welchem Intervall und wie lange sie gespeichert bleiben.

Ich zeichne aktuell 24 Datenpunkte mit unterschiedlichen Intervallen und Haltezeiten auf. Die Datenbank ist seit Jahren am laufen. In der Datenbank befinden sich derzeit 6.127.543 Datensätze und sie ist 391 MB groß. Eine komprimierte Sicherung hat 33,2 MB. Nur so zur Orientierung...