Perché le query della cronologia di Home Assistant possono rallentare man mano che crescono i dati del Recorder?
Home Assistant non dispone di un unico motore di “ricerca” universale la cui velocità diminuisce a ogni entità aggiunta. Il problema di scalabilità più evidente riguarda il lavoro sulle query storiche: il pannello Cronologia, le viste simili al Registro, le statistiche e altre funzionalità basate sul database devono recuperare e organizzare i dati conservati da Recorder.
Con la crescita del dataset, il costo di una richiesta dipende dal numero di righe corrispondenti, dagli indici in grado di restringerle, dalla necessità di collegare gli attributi, dalla quantità di dati già presente in memoria e dalla velocità con cui lo storage può fornire le pagine mancanti. Le dimensioni del database contano, ma la struttura della query è altrettanto importante.
La cronologia legge da Recorder, non solo dalla macchina degli stati in tempo reale
I valori correnti dei dispositivi risiedono nel modello degli stati runtime di Home Assistant, mentre l'integrazione Cronologia legge le osservazioni archiviate da Recorder. Pertanto, una scheda del dashboard che mostra la temperatura attuale e un grafico della cronologia di cinque giorni utilizzano percorsi dati diversi.
Home Assistant documenta che la Cronologia dipende da Recorder e normalmente legge i dati grezzi di Recorder entro la finestra di conservazione configurata. Quando l'intervallo selezionato supera tale finestra per i sensori idonei, può utilizzare invece le statistiche a lungo termine orarie.
Per questo un database storico di grandi dimensioni può rendere lenta la Cronologia, mentre un'automazione locale per una luce continua a reagire istantaneamente.
Più stati conservati significano più righe, metadati e lavoro sugli indici
Ogni aggiornamento registrato aggiunge informazioni al database. Home Assistant riduce la duplicazione separando gli identificatori delle entità e gli attributi condivisi in tabelle correlate, ma un'installazione attiva può comunque accumulare grandi quantità di righe relative agli stati.
Il modello dati attuale di Home Assistant mostra che gli stati registrati fanno riferimento ai metadati delle entità e alle righe degli attributi condivisi e includono timestamp indicizzati e relazioni utilizzate dalle query storiche. Le entità che cambiano rapidamente aumentano quindi più del semplice numero di valori leggibili dall'utente.
La durata della conservazione e la frequenza degli aggiornamenti si moltiplicano a vicenda. Un sensore che cambia ogni secondo crea un insieme di dati operativo molto diverso da quello di un sensore che cambia due volte al giorno, anche se entrambi sono “una sola entità”.
Gli indici riducono il lavoro di ricerca, ma non rendono gratuito il risultato
SQLite può utilizzare gli indici per evitare la scansione di ogni riga in presenza di vincoli e ordinamenti comuni nelle query. Questo è essenziale per la Cronologia, ma un indice non elimina il costo di restituire un intervallo ampio di risultati o di collegare i dati associati.
La documentazione di SQLite sul pianificatore delle query spiega che gli indici accelerano la ricerca e l'ordinamento, mentre grandi insiemi di risultati, ricerche delle righe e ordinamenti richiedono comunque un lavoro proporzionale ai dati selezionati e al piano adottato. Il pianificatore sceglie tra i percorsi disponibili in base al costo stimato.
Ciò significa che “il database ha un indice” e “questa query rimarrà sempre a tempo costante” non sono affermazioni equivalenti. Intervalli temporali più ampi ed entità più rumorose possono comunque rendere rilevanti più pagine e righe.
La conservazione di Recorder è un controllo delle prestazioni e della capacità
Home Assistant elimina automaticamente i dati di Recorder, in modo che gli stati dettagliati non crescano indefinitamente. Aumentare la durata della conservazione offre più cronologia a piena risoluzione, ma aumenta anche l'insieme di dati storici operativo, le dimensioni dei backup e il lavoro di manutenzione.
La documentazione di Recorder avverte esplicitamente che consentire al database di diventare troppo grande consuma spazio su disco e può rallentare Home Assistant. Il comportamento predefinito di eliminazione e ricompattazione esiste in parte per mantenere sotto controllo la crescita del database.
La durata di conservazione corretta è quindi un requisito del prodotto. Conserva i dati ad alta risoluzione abbastanza a lungo da rispondere alle domande reali della casa, non semplicemente perché c'è spazio sul disco.
Lo storage e la cache determinano quanto risulta costosa la stessa query
Una richiesta ripetuta della Cronologia può essere più veloce perché le pagine del database e del file system sono già residenti in memoria. La stessa query, dopo un riavvio o in condizioni di pressione sulla memoria, potrebbe richiedere più letture fisiche. Anche un altro servizio che scrive intensamente sullo stesso SSD può aumentare la latenza senza modificare la richiesta SQL.
L'analisi di ZimaSpace sulla crescita dei metadati e della cronologia di Home Assistant spiega le cause dal lato della scrittura. Le prestazioni delle query sono la conseguenza dal lato della lettura: una maggiore quantità di stati conservati conta soprattutto quando l'intervallo selezionato o l'insieme di dati operativo li coinvolge effettivamente.
Misura il tempo delle query insieme alla latenza dello storage e alla pressione sulla memoria prima di spostare i database o acquistare hardware più veloce.
Riduci il costo delle query riducendo i dati non necessari, non la cronologia utile
- Escludi le entità i cui cambiamenti storici non hanno alcun valore decisionale.
- Riduci la frequenza degli aggiornamenti alla fonte quando i cambiamenti ad alta frequenza non sono utili.
- Mantieni la conservazione dei dati grezzi in linea con l'intervallo temporale che gli utenti consultano effettivamente.
- Utilizza le statistiche a lungo termine per gli intervalli estesi, quando sono sufficienti aggregazioni orarie.
- Mantieni Recorder su uno storage affidabile e a bassa latenza, con un margine di spazio libero.
- Confronta lo stesso intervallo della Cronologia prima e dopo ogni modifica.
La metrica utile non è costituita solo dalle dimensioni del database. È il modo in cui la latenza delle query cambia al variare delle righe conservate, dell'intervallo temporale richiesto, dello stato della cache e delle condizioni dello storage.
Domande frequenti
Un database Recorder più grande rende automaticamente più lente le automazioni locali?
No. Il controllo dei dispositivi in tempo reale e le query storiche seguono percorsi separati. Possono influenzarsi indirettamente quando il lavoro di Recorder crea contesa condivisa per CPU, memoria o storage, ma un grafico della Cronologia lento non dimostra che il motore delle automazioni sia lento.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Stato di runtime vs stato persistente in Home Assistant: cosa deve sopravvivere al riavvio?
Home Assistant non conserva ogni valore in tempo reale; la configurazione, i registri, gli stati selezionati ripristinati, la cronologia e i dati di distribuzione...
Come autentica Home Assistant le sessioni locali e remote?
Le sessioni Home Assistant locali e remote utilizzano lo stesso modello di identità lato server; l'accesso remoto modifica il percorso e il confine TLS,...
Perché Home Assistant ricostruisce uno stato diverso dopo il riavvio del container?
Il riavvio del container non equivale alla perdita dello stato: Home Assistant ricostruisce lo stato di runtime a partire dalla configurazione persistente, dalle integrazioni,...
