Waarom kunnen geschiedenisquery's van Home Assistant trager worden naarmate de Recorder-gegevens groeien?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Why Can Home Assistant History Queries Slow as Recorder Data Grows?

Home Assistant heeft geen universele ‘zoekmachine’ waarvan de snelheid afneemt bij elke toegevoegde entiteit. Het duidelijkere schaalbaarheidsprobleem is historisch querywerk: het deelvenster Geschiedenis, weergaven zoals het Logboek, statistieken en andere databasefuncties moeten opgeslagen Recorder-gegevens ophalen en ordenen.

Naarmate die dataset groeit, hangt de kosten van een verzoek af van het aantal overeenkomende rijen, van de indexen die deze kunnen beperken, van de vraag of attributen moeten worden gekoppeld, van hoeveel gegevens al in het geheugen staan en van hoe snel de opslag ontbrekende pagina’s kan leveren. De databasegrootte is belangrijk, maar de queryvorm is minstens zo bepalend.

Geschiedenis leest uit Recorder, niet alleen uit de live statusmachine

De huidige apparaatwaarden staan in het runtime-statusmodel van Home Assistant, terwijl de Geschiedenis-integratie opgeslagen waarnemingen uit Recorder leest. Een dashboardkaart die de huidige temperatuur toont en een Geschiedenisgrafiek van vijf dagen gebruiken daarom verschillende gegevenspaden.

Home Assistant documenteert dat Geschiedenis afhankelijk is van Recorder en normaal gesproken onbewerkte Recorder-gegevens binnen de geconfigureerde bewaartermijn leest. Wanneer het geselecteerde bereik voor geschikte sensoren buiten die termijn valt, kan in plaats daarvan gebruik worden gemaakt van langetermijnstatistieken per uur.

Daarom kan een grote historische database Geschiedenis traag laten aanvoelen, terwijl een lokale lichtautomatisering nog steeds direct reageert.

Meer bewaarde status betekent meer rijen, metagegevens en indexwerk

Elke geregistreerde update voegt informatie toe aan de database. Home Assistant vermindert duplicatie door entiteits-id’s en gedeelde attributen in gerelateerde tabellen op te slaan, maar een drukke installatie kan nog steeds grote aantallen statusrijen verzamelen.

Het huidige gegevensmodel van Home Assistant laat zien dat geregistreerde statussen verwijzen naar entiteitsmetagegevens en gedeelde attribuutrijen en geïndexeerde tijdstempels en relaties bevatten die voor historische query’s worden gebruikt. Entiteiten die snel veranderen verhogen dus meer dan alleen het aantal leesbare waarden.

De bewaartermijn en updatefrequentie versterken elkaar. Een sensor die elke seconde verandert, creëert een heel andere werklast dan een sensor die twee keer per dag verandert, ook al zijn het allebei ‘één entiteit’.

Indexen beperken zoekwerk, maar maken de resultaatgrootte niet kosteloos

SQLite kan indexen gebruiken om voor veelvoorkomende queryvoorwaarden en sorteringen te voorkomen dat elke rij wordt gescand. Dat is essentieel voor Geschiedenis, maar een index elimineert niet de kosten van het retourneren van een groot overeenkomend bereik of het koppelen van bijbehorende gegevens.

De documentatie over de queryplanner van SQLite legt uit dat indexen zoekopdrachten en sorteringen versnellen, terwijl grote resultaatsets, het ophalen van rijen en sorteringen nog steeds werk vereisen dat evenredig is aan de geselecteerde gegevens en het gekozen plan. De planner kiest uit de beschikbare paden op basis van de geschatte kosten.

Dat betekent dat ‘de database heeft een index’ en ‘deze query blijft voor altijd constante tijd kosten’ geen gelijkwaardige beweringen zijn. Bredere tijdsbereiken en entiteiten met veel ruis kunnen er nog steeds voor zorgen dat meer pagina’s en rijen relevant zijn.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Recorder-bewaring is een regelaar voor prestaties en capaciteit

Home Assistant verwijdert automatisch Recorder-gegevens, zodat gedetailleerde statusinformatie niet onbeperkt blijft groeien. Een langere bewaartermijn biedt meer geschiedenis met volledige resolutie, maar vergroot ook de actieve historische werklast, de back-upgrootte en het onderhoudswerk.

De Recorder-documentatie waarschuwt expliciet dat een database die te groot wordt schijfruimte verbruikt en Home Assistant traag kan maken. Het standaard verwijderen en opnieuw inpakken van gegevens bestaat gedeeltelijk om de groei van de database binnen grenzen te houden.

De juiste bewaartermijn is daarom een productvereiste. Bewaar gegevens met hoge resolutie lang genoeg om echte vragen over het huishouden te beantwoorden, niet alleen omdat er schijfruimte beschikbaar is.

Opslag en cache bepalen hoe duur dezelfde query aanvoelt

Een herhaald Geschiedenisverzoek kan sneller zijn omdat database- en bestandssysteempagina’s al in het geheugen aanwezig zijn. Dezelfde query kan na een herstart of bij geheugendruk meer fysieke leesbewerkingen vereisen. Een andere service die zwaar naar dezelfde SSD schrijft, kan de latentie ook verhogen zonder de SQL-query te wijzigen.

De ZimaSpace-analyse van de groei van metagegevens en geschiedenis in Home Assistant legt de oorzaken aan de schrijfzijde uit. Queryprestaties zijn het gevolg aan de leeszijde: meer bewaarde statusinformatie is vooral van belang wanneer het geselecteerde bereik of de werklast deze daadwerkelijk raakt.

Meet de querytijd samen met opslaglatentie en geheugendruk voordat je databases verplaatst of snellere hardware aanschaft.

Verlaag querykosten door onnodige gegevens te beperken, niet door nuttige geschiedenis te verwijderen

Sluit entiteiten uit waarvan historische veranderingen geen besliswaarde hebben.
Verlaag de updatefrequentie bij de bron wanneer snelle veranderingen niet nuttig zijn.
Stem de onbewerkte bewaartermijn af op het tijdsbereik dat gebruikers daadwerkelijk bekijken.
Gebruik langetermijnstatistieken voor lange perioden waarin aggregaten per uur volstaan.
Houd Recorder op betrouwbare opslag met lage latentie en voldoende vrije ruimte.
Vergelijk hetzelfde Geschiedenisbereik voor en na elke wijziging.

De nuttige maatstaf is niet alleen de databasegrootte. Het gaat erom hoe de querylatentie verandert naarmate het aantal bewaarde rijen, het opgevraagde tijdsbereik, de cachestatus en de opslagomstandigheden veranderen.

Veelgestelde vragen

Maakt een grotere Recorder-database lokale automatiseringen automatisch trager?

Nee. Live apparaatbesturing en historische query’s zijn afzonderlijke paden. Ze kunnen elkaar indirect beïnvloeden wanneer Recorder-werk gedeeld gebruik van CPU, geheugen of opslag veroorzaakt, maar een trage Geschiedenisgrafiek bewijst niet dat de automatiseringsengine traag is.