Aus dem beruflichen Umfeld kann ich nur zu influx oder Prometheus raten für Langzeit Daten.
Diese Datenbank sind genau für time series ausgelegt und sehr performant für diese use cases.
Nutzen seit Jahren influx mit abertausend Datensätzen, sodass wir nur den Prozess/Container über 250GB RAM geben.
Aber wir hauen da auch richtig Daten rein und haben dazu noch jede mange dashboards für viele Mitarbeiter und dazu noch Alerts.
Packt den Kram einfach in eine time series database, dafür sind die da.
Mal eine andere Frage. Wenn ich jetzt in der conig
recorder:
auto_repack: false
reinschreibe um z.B. über 3 Monate Daten zu sammeln.
Wenn ich es dann aus der config wieder entferne, wird dann ab da wieder alle 4 Wochen gelöscht oder auch Daten die sonst nicht langzeit gespeichert werden rückwirkend ?
Für mich ist auto_repack immer noch kein löschen, sondern ein „neu zusammen packen“.
Ihr verwechselt es vermutlich mit auto_purge was zusammen mit purge_keep_days zusammen spielt.
auto_repack sorgt dafuer, dass die daten gepackt oder wie frueher defragmentiert werden.
Das kommt von SQLite, die bei HA genutzt wird.
Das ist ja nur eine Datei, die staendig waechst, weil mehr Daten reingeschrieben werden.
Wenn ihr jetzt Tabllen oder Datensatze loescht, dann wird die Datei sehr wahrscheinlich noch die gleiche groesse haben. Zumindest wird das Storage da drunter die Bloecke nicht freigeben.
Das repack sorgt dafuert, dass der Platz wieder freigegeben wird.
Also loescht das auto_repack nichts. Es wird nur die Datei wieder kompakter machen und dadurch kleiner.
hallo zusammen
mein Problem war/ist, dass bei einigen Entitäten die Daten die älter waren als 10 Tage, nach dem auto_repack komplett gelöscht wurden. Das heißt sie wurden nicht in historische Werte „umgewandelt“ (historische Werte:nach meinem Verständnis der Mittelwert der letzten Stunde), sondern sie wurden ohne Vorwarnung einfach gelöscht!
@Dreckfresse hat mir erklärt, dass alle Werde die nicht alle der 3 folgende Kriterien:
1.) device_class definiert UND
2.) state_class definiert UND
3.) unit_of_measurement definiert
erfüllen NICHT als historischen Werte abgelegt werden, sondern einfach von HA beim auto_repack dann „gepappt“ werden!!! (ich habe bis heute nichts darüber in der HA Doku gefunden).
Im Moment durchforste ich alle Entitäten, welche in der Vergangenheit gepappt wurden, um diese Kriterien manuell nachzutragen.
Weiterhin habe ich auto_repack abgeschaltet und warte mal auf nächsten Sonntag (2.Sonntag im Monat), um zu schauen was passiert. (ich werde aber vorher sicherstellen, dass ich meine Daten sichere, im Falle dass ich etwas falsch verstanden habe), um ggf. die verlorenen (gepappten) Werte wieder herzustellen.
Wenn alles so läuft wie verstanden, werde ich auto_repack selbstverständlich wieder auf true setzten.
Schau mal hier - auf diesen beiden Seiten sind eigentlich alle benötigen Informationen. History Doku:History - Home Assistant
Hier befindet sich auch folgender Hinweis:
About the data sources
By default, the recorder stores the sensor data for 10 days. Older data is purged automatically. The data for the last 10 days is taken from the recorder.
If you select a time frame that exceeds 10 days, the data is taken from the long term statistics table. Long term statistics are saved for sensors with a state_class of measurement, total or total_increasing. The long term statistics data is sampled and averaged once per hour, to save storage. Therefore, the values might look different from what you see from the recorder data, which shows the measured values at the sample rate defined for that sensor. The detailed data will be shown with a darker line on graphs.
Das ist immer noch nicht so ganz richtig Sie werden nach 10 Tagen gelöscht. Das hat aber nichts direkt mir dem auto_repack und dem pappen zu tun, wie hier bereits erklärt wurde. Das hat eher was mit dem auto_purge zu tun:
Hallo zusammen
Hier eine kurze Zusammenfassung wie sich mein System nach dem auto_repack, vom vergangenen Sonntag auf meine SQL Datei, bzw. auf einigen Entitäten ausgewirkt hat. (Zur Info: auto_repack war auf „true“ und HM wurde Anfang April neu aufgesetzt) 1.) SQL Datei:
Die SQL Datei wurde prinzipiell so „bereinigt“ wie es die HA Dokumentation beschreibt. Deshalb eine Verkleinerung nach dem auto_repack um ca. 900MB, was ich nachvollziehen kann.
Was ich aber nicht verstehe, wieso die SQL Datei zwischendurch absolut konstant bleibt (als wäre sie eingefroren) und dann auf einmal wieder steigt. Habt ihr eine Erklärung für diese „Konstanz“? 2.) Entitäten die nicht als historische Werte abgelegt werden:
Entitäten die mit all den 3 notwendigen Attributen (device_class, state_class und unit_of_measurement) definiert sind, um nach dem auto_repack in die historischen Werte konvertiert zu werden.
Beispiel: „PV:Autarky Month“:
Ursprünglich waren hier Daten bis zum 18.7.25 hinterlegt und „purge_keep_days: 16“.
HM hat aber die vorherigen (älteren) Daten einfach gekappt und somit nur die Daten dieser Entität für der letzten 16Tage gespeichert sind.
Was habe ich falsch gemacht oder habe ich nur einen Denkfehler? ???
Übrigens: Diese Beispiel Entität ist nicht die einzige Entität die sich so verhält!!!
Hallo Dreckfresse!
Danke für die superschnelle Antwort mit dem Hinweis:
Ursprünglich war für diese Entität keine device_class definiert, sondern vom Gerät (in diesem Falle Kostal PV) war die unit_of_measurement mit % vorgegeben, was bei Autarkierate ja Sinn macht.
Ich habe nichts besseres für device_class als Duration gefunden, was wäre das richtige Attribut für %
Viele denken, dass SQLite nur eine Datei ist.
Das stimmt nur, wenn man Default Werte nimmt.
Für Performance Verbesserungen kann man aber ganz viele Flags setzen.
Eine davon ist der Journal Mode, der dann eine 2te Datei sich bringt: das sogenannte Write-Ahead Logging File, oder kurz WAL file. [1]
Im WAL File landen erstmal alle neuen Schreiboperationen. Nach einer Zeit oder Anzahl an Einträge oder Megabyte wird das WAL File mit der *.db gemerged.
Das ist ein Grund warum es konstant bleibt.
Der 2te könnte sein, dass bei gelöschten Elementen in der Datenbank nicht wirklich gelöscht wird.
Es wird nur der Block wo die Daten sind als frei markiert. Das ist ganz normal, denn sonst müsste die Datei neu geschrieben werden und das ist eine teure Operation.
Solange also weniger oder gleich viel geschrieben wird (WAL merging) als frei gemacht, ändert sich nichts an der DB Größe.
hallo Dreckfresse
Ich habe extra ein paar Tage gewartet, um zu sehen, wie sich diese Anpassung (dein letzter Vorschlag) auf alle Entitäten auswirkt, welche das Problem haben, dass sie nicht in historische Werte (Langzeitstatistik) konvertiert werden.
Hier meine Zusammenfassung:
Gezeigte Entität (Autarkie per day): funktioniert jetzt->die Daten werden korrekt in historischen Werte konvertiert-> perfekt !!
ABER …
diese Anpassung funktioniert nicht bei allen „Problem“-Entitäten.
Hier beispielhaft eine weitere Entität die vom Aufbau sehr ähnlich ist, wie die o.g., bei der aber keine Konvertierung erfolgt, sondern alles was älter als 16 Tage ist einfach gelöscht wird.
@ajfriesen
Vielen Dank für Deine sehr guten und plausiblen Erläuterungen.
Somit sind für mich ganz viele Fragen zum Thema SQLight Speicherverhalten beantwortet.
Sie werden nach 10 Tagen gelöscht. Das hat aber nichts direkt mir dem auto_repack und dem pappen zu tun, wie hier bereits erklärt wurde. Das hat eher was mit dem auto_purge zu tun:
