Quando dovrebbe usare Home Assistant un database o un host di archiviazione separato?
Home Assistant dovrebbe usare un database o uno storage host separato solo quando questa separazione risolve un problema misurabile di capacità, conservazione, backup o isolamento dai guasti. Spostare i dati dal controller non è automaticamente un miglioramento.
Per molte abitazioni, un database Recorder SQLite in locale su uno storage SSD affidabile è la soluzione più semplice, perché elimina le dipendenze di rete, autenticazione, DNS e avvio del server di database. Prima di creare un altro host, individua la vera causa del problema: troppe scritture di Recorder, una lunga conservazione dei dati, query sulla cronologia lente, capacità locale limitata o la necessità di ripristinare un servizio in modo indipendente.
Ottimizza Recorder prima di aggiungere un server di database
La crescita di Recorder dipende dalle entità e dagli eventi salvati, dalla frequenza con cui cambiano e dalla durata della conservazione della cronologia. Se i sensori troppo attivi o i domini non necessari generano la maggior parte delle scritture, trasferire lo stesso carico di lavoro su un server di database più grande sposta il problema, invece di risolverlo.
Un flusso di lavoro attuale per ottimizzare Recorder mostra come la conservazione dei dati, le regole di inclusione/esclusione e il comportamento di commit influiscano sul carico di scrittura prima di valutare una migrazione del database. Dopo l’ottimizzazione, misura le dimensioni del database, il tempo delle query sulla cronologia, la latenza dello storage e l’attività di scrittura.
Mantieni il database in locale quando il carico di lavoro ottimizzato resta reattivo, i backup terminano entro la finestra di manutenzione e la capacità SSD disponibile è sufficiente. La separazione dovrebbe rispondere a un requisito non soddisfatto, non a una convinzione generica che i database client-server siano sempre più veloci.
Usa un database esterno quando offre vantaggi operativi concreti
Un host MariaDB, MySQL o PostgreSQL separato può essere una scelta sensata quando Home Assistant condivide una piattaforma di database già gestita correttamente, quando una lunga conservazione dei dati genera una pressione costante sulle query, quando l’host del controller deve rimanere leggero o sostituibile, oppure quando il backup e il monitoraggio del database richiedono un ciclo di vita indipendente.
Un esempio di migrazione da SQLite a MariaDB illustra gli elementi introdotti da questa scelta: servizio database, credenziali, indirizzo di rete, inizializzazione dello schema, procedura di migrazione, convalida e ripristino della versione precedente. Un caso reale più ampio di migrazione del database di Home Assistant mostra perché una cronologia lunga e grandi quantità di dati possono giustificare l’amministrazione aggiuntiva.
L’articolo di ZimaSpace sull’affidabilità degli aggiornamenti dei database esterni definisce il corrispondente confine di manutenzione: il database deve essere sottoposto a backup, aggiornato e ripristinato come servizio a sé, anziché essere trattato come un’infrastruttura invisibile.
Di norma, non mettere un database SQLite attivo su una condivisione di rete
Un server di database remoto e un file di database archiviato su SMB o NFS sono architetture diverse. Un database client-server gestisce i lock e le transazioni all’interno del servizio database e invia le richieste tramite rete. SQLite gestisce i lock del file di database tramite il file system, quindi la semantica del file system di rete, la disponibilità del mount, la latenza e il comportamento dei lock influiscono su ogni transazione.
L’analisi più ampia dei lock di SQLite spiega perché i file system di rete possono produrre un comportamento dei lock diverso da quello di un disco locale. Un caso di malfunzionamento su una condivisione di rete di Home Assistant mostra il rischio concreto quando il database Recorder attivo dipende da un mount remoto.
Usa liberamente un NAS per copie di backup, esportazioni, contenuti multimediali e altri dati pensati per l’archiviazione in rete. Se lo stato attivo di Recorder deve risiedere su un’altra macchina, preferisci un database client-server supportato invece di spostare il file SQLite su una condivisione.
Separa lo spazio di archiviazione di massa dallo stato attivo di Home Assistant
Non tutte le directory di Home Assistant che crescono devono appartenere allo stesso livello di archiviazione. Configurazione, stato delle integrazioni, database attivo di Recorder, contenuti multimediali, clip delle telecamere, esportazioni e backup hanno esigenze diverse in termini di latenza e ripristino. Mantieni lo stato ridotto e aggiornato di frequente su un'archiviazione locale a bassa latenza, a meno che un servizio separato non se ne occupi intenzionalmente.
Sposta i contenuti multimediali voluminosi o le generazioni di backup su una capacità NAS tramite punti di montaggio stabili. Documenta se Home Assistant può avviarsi senza quel montaggio. La mancanza di un archivio fotografico non dovrebbe impedire l'avvio delle automazioni delle luci, mentre la mancanza del database attivo dovrebbe generare uno stato degradato esplicito, non un ripiego silenzioso che nessuno nota.
| Ruolo dei dati | Posizionamento predefinito | Motivo della separazione |
|---|---|---|
| Configurazione e stato attivo | SSD locale | Bassa latenza e ripristino semplice |
| SQLite di Recorder | SSD locale | Evita dipendenze dal blocco dei file system di rete |
| Database SQL esterno | Locale o host database separato | Scalabilità, conservazione, backup e amministrazione indipendenti |
| Contenuti multimediali ed esportazioni | Locale o NAS | Spesso la capacità conta più della latenza |
| Backup | Almeno una copia su un altro host | Resistere alla perdita dell'host attivo |
Verifica l'avvio, i guasti e il ripristino prima di rendere permanente la separazione
Predisponi il nuovo ruolo di database o archiviazione senza eliminare il vecchio percorso di ripristino. Riavvia l'host database prima di Home Assistant, riavvia Home Assistant prima che il database sia pronto, interrompi la rete, cambia le credenziali, porta il filesystem di destinazione quasi alla soglia di riserva e ripristina il database su un'istanza pulita.
Misura il tempo delle query sulla cronologia al 95° percentile, la latenza delle automazioni durante un'attività intensa del Recorder, il tempo di riavvio, la durata del backup e il tempo di ripristino dopo un'interruzione dell'host database. Se la separazione migliora una metrica ma trasforma il riavvio di trenta secondi del controller in una procedura di ripristino che coinvolge più servizi, includi questo costo operativo nella decisione.
Mantieni l'archiviazione locale quando soddisfa già l'obiettivo. Usa un host database separato quando le operazioni database client-server e il ripristino indipendente offrono vantaggi concreti. Usa un host di archiviazione separato per i dati voluminosi e i backup, ma non rendere il controllo locale critico dipendente da un filesystem remoto senza un motivo verificato.
Prodotti consigliati
Configurazione NAS e server
Altre letture
Un server in dormitorio può essere abbastanza silenzioso da permettere di dormire, studiare e fare videochiamate?
Sì: un server in dormitorio può restare discreto se l’hardware consuma poco, le vibrazioni dei dischi sono controllate, le attività più impegnative vengono pianificate...
Un homelab per studenti che può trasferirsi dalla stanza del dormitorio al primo appartamento
Mantieni portatile il laboratorio domestico di uno studente separando i servizi dalla rete specifica della stanza, riducendo al minimo l’hardware, eseguendo il backup dello...
Come condividere un server domestico con i coinquilini senza condividere account o file privati
Assegna a ogni coinquilino un’identità personale e uno spazio di archiviazione privato, concedendo solo i ruoli condivisi necessari; mantieni separate l’amministrazione, i backup e...
