Quelle surcharge de stockage Home Assistant ajoute-t-il au-delà des données sources ?

Home Assistant n’ajoute aucun multiplicateur de stockage universel ; la surcharge dépend de la fréquence des événements, de l’historique conservé, des statistiques, des index, des journaux, des sauvegardes, des modules complémentaires et de l’espace de travail temporaire.

Un capteur de température peut émettre de minuscules valeurs, mais leurs changements peuvent devenir des états horodatés, des attributs, des entrées d’index, des agrégats, des copies de sauvegarde et des métadonnées du système de fichiers. Les clips vidéo ou les données des modules complémentaires peuvent dominer pour des raisons totalement différentes. Une estimation utile sépare donc chaque rôle de stockage et mesure sa croissance quotidienne en fonction du nombre réel d’entités du foyer, de leur fréquence de mise à jour, de la durée de conservation, du niveau de journalisation et de la politique de sauvegarde.

Les valeurs sources deviennent des données structurées de Recorder

Les données sources correspondent uniquement à la valeur reçue d’un appareil ou d’une intégration. Recorder conserve les changements d’état et les événements sélectionnés avec leurs horodatages, références d’entités, attributs et structures relationnelles, afin que l’historique et les autres fonctionnalités puissent les interroger. Ainsi, une courte mesure telle que 21,4 occupe davantage d’espace que ses seuls caractères visibles une fois les pages de base de données et les relations prises en compte.

Home Assistant conserve les états bruts ainsi que des formes statistiques à court et à long terme. Cette explication détaillée du modèle de base de données et de statistiques montre pourquoi l’empreinte conservée dépend de la fréquence des changements et des règles d’agrégation, plutôt que de la taille nominale des données transmises par un capteur.

Cette première couche dépend généralement du débit : les entités qui changent souvent génèrent davantage de lignes que les entités stables, et des attributs détaillés peuvent amplifier l’écart. Un millier d’entités n’implique pas la même consommation de stockage dans tous les foyers. La prévision de la surcharge doit prendre en compte le nombre de changements quotidiens, le nombre de jours conservés et l’impact moyen du stockage par ligne, pas uniquement le nombre d’entités.

Les index et les pages de base de données ajoutent de l’espace structurel

Une base de données relationnelle a besoin de structures qui rendent les lignes durables et consultables. Les pages de tables, les index, les pages libres, les journaux et les journaux d’écriture anticipée peuvent occuper de l’espace au-delà du contenu logique des lignes. Ces structures améliorent la cohérence et les performances des requêtes, mais leur taille sur le disque ne diminue pas toujours immédiatement lorsque l’ancien historique est supprimé.

SQLite stocke les tables et les index dans des pages de taille fixe ; la taille physique reflète donc l’allocation des pages plutôt qu’une simple somme de la longueur des champs. Un guide accessible sur la disposition des pages SQLite explique comment les enregistrements, les index et l’espace libre coexistent dans le fichier de base de données.

Il faut donc distinguer deux mesures : les données logiquement conservées et l’espace physique alloué. Un nettoyage peut réduire la première sans diminuer immédiatement la seconde, tandis qu’une opération de maintenance peut nécessiter de l’espace temporaire supplémentaire avant de restituer de l’espace. La planification de capacité doit conserver une marge de fonctionnement, plutôt que de considérer la taille actuelle du fichier de base de données comme le besoin maximal possible.

Les statistiques échangent du détail contre une conservation à long terme

L’historique à court terme conserve les changements détaillés pendant une période limitée, tandis que les statistiques à long terme gardent des agrégats compacts pour les entités numériques compatibles. L’agrégation réduit le taux de croissance par entité par rapport à la conservation permanente de chaque état brut, mais elle crée un autre jeu de données durable dont la durée de vie diffère de celle de l’historique ordinaire.

Le modèle de données de Home Assistant peut donc contenir simultanément les états bruts, les échantillons statistiques à court terme et les résumés horaires à long terme. La présentation pratique de cet article sur les intégrations de séries temporelles montre pourquoi l’analyse historique introduit souvent un rôle de stockage supplémentaire par rapport aux seuls besoins d’état courant du contrôleur.

Le résultat dépend du contexte : un foyer comptant de nombreuses entités binaires stables peut avoir une surcharge statistique modeste, tandis que les capteurs d’énergie et d’environnement peuvent accumuler des agrégats conservés pendant longtemps. Les statistiques à long terme ne sont pas un doublon de l’historique brut ; elles préservent une valeur analytique à plus faible résolution. Estimez-les comme un taux quotidien distinct, plutôt que de les intégrer à un multiplicateur global inexpliqué pour la base de données.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Les journaux, les sauvegardes et les couches de conteneurs multiplient l’empreinte

Le stockage de Home Assistant ne se limite pas à Recorder. Les journaux peuvent grossir en cas d’erreurs répétées ou de sessions de débogage. Les sauvegardes peuvent copier la base de données, la configuration, l’état des modules complémentaires et certains dossiers partagés. Les déploiements en conteneurs conservent également des images, des couches inscriptibles, des volumes et parfois d’anciennes versions ou un cache de compilation sur le même disque système.

L’utilisation du disque par Docker est répartie entre plusieurs espaces de stockage plutôt que dans un seul dossier d’application. Ce guide de l’espace disque Docker distingue les images, les conteneurs, les volumes et le cache, ce qui explique pourquoi la croissance du système de fichiers peut dépasser celle du dossier de données visible de Home Assistant.

La conservation des sauvegardes multiplie certaines données par le nombre de copies, mais la compression et le comportement incrémentiel peuvent modifier le ratio exact. Une base de données active de 2 Go ne signifie pas que chaque sauvegarde ajoutera exactement 2 Go, pas plus qu’un petit dossier de configuration ne garantit que les sauvegardes resteront peu volumineuses. Mesurez séparément le contenu des archives et le nombre de générations conservées.

L’espace temporaire crée un pic supérieur à l’état stable

La maintenance de la base de données, la création de sauvegardes, la décompression, les mises à jour, le téléchargement d’images et les migrations peuvent nécessiter de l’espace temporaire pendant que les anciennes et les nouvelles versions coexistent. Ce pic est facile à manquer, car il disparaît une fois l’opération terminée. Il devient un problème de fiabilité lorsqu’une tâche a besoin de blocs libres pour s’achever alors que l’ensemble de données en régime stable occupe déjà la majeure partie du disque.

La base de données principale et le WAL de SQLite peuvent conserver de l’espace alloué jusqu’à ce que les conditions de point de contrôle ou de compactage soient réunies. Une analyse des performances sur la croissance des fichiers SQLite explique pourquoi la base de données et le journal d’écriture anticipée peuvent augmenter différemment des données logiques visibles par l’application.

Le pic requis dépend de l’opération. La réécriture d’une base de données peut nécessiter un espace lié à sa taille, tandis qu’une mise à jour d’image peut conserver temporairement les anciennes et les nouvelles couches. Les recommandations de ZimaSpace sur l’espace libre pour les tâches Home Assistant fournissent des seuils opérationnels une fois les différents éléments de surcharge identifiés.

Pourquoi un ratio de surcharge unique échoue

Un pourcentage fixe échoue lorsqu’un composant domine. La journalisation de débogage peut dépasser Recorder pendant une boucle d’erreurs ; les médias vidéo locaux peuvent éclipser toutes les tables de la base de données ; un module complémentaire volumineux peut faire croître son propre volume ; ou une longue politique de conservation des sauvegardes peut rendre les copies plus volumineuses que l’état actif. Les changements de charge de travail rendent également le ratio d’hier obsolète.

Les guides sur l’épuisement de l’espace disque des conteneurs distinguent précisément les images, les couches inscriptibles, les journaux, les volumes et le cache de compilation, car chacun possède un mécanisme de croissance différent. L’inventaire en cinq parties de cette analyse du stockage Docker montre pourquoi un total global unique ne peut pas identifier la source déterminante.

Le ratio est également trompeur selon le type d’installation. Home Assistant OS, un conteneur, une machine virtuelle et un paquet installé sur un hôte supervisé gèrent différemment les données système. Comparez des configurations similaires et excluez du calcul les médias ou les données d’applications sans rapport, sauf si la sauvegarde ou l’environnement d’exécution de Home Assistant les gère réellement.

Construire un modèle de croissance du stockage sur sept jours

Établissez une mesure de référence pour les fichiers de base de données, la configuration, les journaux, les sauvegardes, les volumes des modules complémentaires, les images et couches de conteneurs, les médias et l’espace libre. Maintenez les paramètres de conservation et de journalisation constants pendant sept jours représentatifs. Relevez chaque composant quotidiennement à la même heure et notez les mises à jour, redémarrages, tâches de sauvegarde, erreurs inhabituelles ou ajouts d’appareils.

La gestion du stockage commence par la visibilité, car les volumes, les images, les couches inscriptibles et le cache ont des cycles de vie distincts. Cet article sur les mécanismes internes du stockage Docker aide à attribuer les octets mesurés aux données d’application persistantes plutôt qu’à la surcharge liée à l’empaquetage de l’environnement d’exécution.

Calculez la croissance quotidienne de chaque rôle, multipliez-la par sa propre durée de conservation, puis ajoutez le pic temporaire observé le plus important ainsi qu’une réserve de récupération. Réévaluez le modèle après l’ajout d’intégrations ou la modification de la journalisation, des médias ou des sauvegardes. Ce modèle par composant produit une plage de capacité défendable ; un multiplicateur universel ne le peut pas.