Varför kan historikfrågor i Home Assistant bli långsammare när Recorder-data växer?

Home Assistant har ingen universell ”sökmotor” vars hastighet minskar för varje tillagd entitet. Det tydligare skalningsproblemet är historiska frågeoperationer: historikpanelen, loggboksliknande vyer, statistik och andra databasbaserade funktioner måste hämta och organisera sparade Recorder-data.

När datamängden växer beror kostnaden för en förfrågan på hur många rader som matchar, vilka index som kan begränsa urvalet, om attribut måste kopplas samman, hur mycket data som redan finns i minnet och hur snabbt lagringen kan leverera sidor som saknas. Databasens storlek spelar roll, men frågans utformning är minst lika viktig.

Historik läser från Recorder, inte enbart från den aktiva tillståndsmaskinen

Aktuella enhetsvärden finns i Home Assistants körningsmodell för tillstånd, medan integrationen Historik läser sparade observationer från Recorder. Ett dashboardkort som visar den aktuella temperaturen och ett femdagarsdiagram över historiken använder därför olika dataströmmar.

Home Assistant dokumenterar att Historik är beroende av Recorder och normalt läser rådata från Recorder inom det konfigurerade lagringsintervallet. När det valda intervallet sträcker sig längre än detta intervall för sensorer som stöds kan den i stället använda långsiktig statistik per timme.

Det är därför en stor historikdatabas kan få Historik att kännas långsam, medan en lokal belysningsautomation fortfarande reagerar direkt.

Mer sparat tillstånd innebär fler rader, mer metadata och mer indexarbete

Varje registrerad uppdatering lägger till information i databasen. Home Assistant minskar dupliceringen genom att separera entitetsidentifierare och gemensamma attribut i relaterade tabeller, men en aktiv installation kan ändå samla på sig stora mängder tillståndsrader.

Den aktuella datamodellen i Home Assistant visar att registrerade tillstånd hänvisar till entitetsmetadata och gemensamma attributrader samt innehåller indexerade tidsstämplar och relationer som används av historiska frågor. Entiteter som ändras ofta ökar därför mer än bara antalet läsbara värden.

Lagringsperiod och uppdateringsfrekvens multiplicerar varandra. En sensor som ändras varje sekund skapar en helt annan arbetsmängd än en som ändras två gånger per dag, även om båda är ”en entitet”.

Index minskar sökarbetet, men gör inte resultatets storlek kostnadsfri

SQLite kan använda index för att undvika att genomsöka varje rad vid vanliga frågevillkor och sorteringar. Det är avgörande för Historik, men ett index eliminerar inte kostnaden för att returnera ett stort matchande intervall eller koppla samman tillhörande data.

Dokumentationen om SQLite:s frågeplanerare förklarar att index påskyndar uppslagning och sortering, medan stora resultatmängder, raduppslagningar och sorteringar fortfarande kräver arbete som står i proportion till den valda datamängden och planen. Planeraren väljer mellan tillgängliga vägar utifrån uppskattad kostnad.

Det innebär att ”databasen har ett index” och ”den här frågan förblir konstant snabb för alltid” inte är likvärdiga påståenden. Bredare tidsintervall och brusigare entiteter kan fortfarande göra fler sidor och rader relevanta.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recorders lagringsperiod styr både prestanda och kapacitet

Home Assistant rensar automatiskt Recorder-data så att detaljerade tillstånd inte växer utan begränsning. En längre lagringsperiod ger mer historik i full upplösning, men ökar också den aktiva historiska arbetsmängden, storleken på säkerhetskopior och underhållsarbetet.

Recorder-dokumentationen varnar uttryckligen för att en databas som tillåts bli för stor förbrukar diskutrymme och kan göra Home Assistant långsam. Standardbeteendet för rensning och ompackning finns delvis för att hålla databasens tillväxt under kontroll.

Rätt lagringsperiod är därför ett krav från verksamheten. Spara data i hög upplösning tillräckligt länge för att besvara verkliga frågor i hemmet, inte bara för att det finns ledigt diskutrymme.

Lagring och cache avgör hur dyr samma fråga känns

En upprepad historikförfrågan kan gå snabbare eftersom databas- och filsystemssidor redan finns i minnet. Samma fråga efter en omstart eller under minnesbrist kan behöva fler fysiska läsningar. En annan tjänst som skriver intensivt till samma SSD kan också öka fördröjningen utan att SQL-förfrågan ändras.

ZimaSpaces analys av tillväxten av Home Assistants metadata och historik förklarar orsakerna på skrivsidan. Frågeprestanda är konsekvensen på lässidan: mer sparat tillstånd spelar störst roll när det valda intervallet eller arbetsmängden faktiskt berör det.

Mät frågetiden tillsammans med lagringens fördröjning och minnesbelastningen innan du flyttar databaser eller köper snabbare hårdvara.

Minska frågekostnaden genom att minska onödiga data, inte användbar historik

• Uteslut entiteter vars historiska förändringar inte har något beslutsvärde.
• Minska uppdateringsfrekvensen vid källan när förändringar med hög frekvens inte är användbara.
• Anpassa lagringen av rådata efter det tidsintervall som användarna faktiskt granskar.
• Använd långsiktig statistik för långa tidsperioder när timvisa sammanställningar räcker.
• Ha Recorder på tillförlitlig lagring med låg fördröjning och god marginal av ledigt utrymme.
• Jämför samma historikintervall före och efter varje ändring.

Det användbara måttet är inte enbart databasens storlek. Det är hur frågefördröjningen förändras när antalet sparade rader, det begärda tidsintervallet, cachens tillstånd och lagringsförhållandena ändras.

Vanliga frågor

Gör en större Recorder-databas automatiskt lokala automationer långsammare?

Nej. Styrning av enheter i realtid och historiska frågor följer separata vägar. De kan påverka varandra indirekt när Recorder-arbete skapar konkurrens om processor, minne eller lagring, men ett långsamt historikdiagram bevisar inte att automationsmotorn är långsam.