Pourquoi les requêtes d’historique de Home Assistant peuvent-elles ralentir à mesure que les données de l’enregistreur augmentent ?

Home Assistant ne dispose pas d’un moteur de recherche universel dont la vitesse diminuerait à chaque entité ajoutée. Le problème de mise à l’échelle le plus évident concerne le travail historique lié aux requêtes : le panneau Historique, les vues de type journal, les statistiques et les autres fonctionnalités reposant sur une base de données doivent récupérer et organiser les données conservées par Recorder.

À mesure que ce jeu de données augmente, le coût d’une requête dépend du nombre de lignes correspondantes, des index capables de les filtrer, de la nécessité ou non de joindre des attributs, de la quantité de données déjà en mémoire et de la rapidité avec laquelle le stockage peut fournir les pages manquantes. La taille de la base de données compte, mais la structure de la requête est tout aussi importante.

L’historique lit les données de Recorder, pas uniquement celles de la machine d’état active

Les valeurs actuelles des appareils résident dans le modèle d’état d’exécution de Home Assistant, tandis que l’intégration Historique lit les observations stockées par Recorder. Ainsi, une carte de tableau de bord affichant la température actuelle et un graphique historique sur cinq jours empruntent des chemins de données différents.

Home Assistant indique que l’historique dépend de Recorder et lit normalement les données brutes de Recorder dans la fenêtre de conservation configurée. Lorsque la période sélectionnée dépasse cette fenêtre pour les capteurs admissibles, il peut utiliser les statistiques à long terme horaires.

C’est pourquoi une vaste base de données historique peut donner l’impression que l’historique est lent, alors qu’une automatisation locale contrôlant une lampe réagit toujours instantanément.

Davantage d’états conservés signifie davantage de lignes, de métadonnées et de travail sur les index

Chaque mise à jour enregistrée ajoute des informations à la base de données. Home Assistant réduit les doublons en séparant les identifiants d’entités et les attributs partagés dans des tables associées, mais une installation très active peut tout de même accumuler un grand nombre de lignes d’état.

Le modèle de données actuel de Home Assistant montre que les états enregistrés référencent les métadonnées des entités et les lignes d’attributs partagés, et incluent des horodatages indexés ainsi que des relations utilisées par les requêtes historiques. Les entités qui changent fréquemment augmentent donc davantage que le simple nombre de valeurs lisibles par l’utilisateur.

La durée de conservation et la fréquence des mises à jour se multiplient. Un capteur qui change chaque seconde crée un ensemble de travail très différent de celui d’un capteur qui change deux fois par jour, même s’il s’agit dans les deux cas d’une seule entité.

Les index réduisent le travail de recherche, mais ne rendent pas gratuite la taille des résultats

SQLite peut utiliser des index pour éviter de parcourir chaque ligne lors des contraintes et tris courants des requêtes. C’est essentiel pour l’historique, mais un index n’élimine pas le coût du renvoi d’une vaste plage de résultats ni celui de la jointure des données associées.

La documentation du planificateur de requêtes SQLite explique que les index accélèrent la recherche et le tri, tandis que les grands ensembles de résultats, les recherches de lignes et les tris nécessitent toujours un travail proportionnel aux données sélectionnées et au plan d’exécution. Le planificateur choisit parmi les chemins disponibles en fonction du coût estimé.

Ainsi, « la base de données possède un index » et « cette requête conservera éternellement un temps d’exécution constant » ne sont pas des affirmations équivalentes. Des périodes plus longues et des entités plus bruyantes peuvent toujours rendre davantage de pages et de lignes pertinentes.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La conservation par Recorder contrôle les performances et la capacité

Home Assistant purge automatiquement les données de Recorder afin que les états détaillés ne croissent pas indéfiniment. Une conservation plus longue fournit davantage d’historique en pleine résolution, mais augmente également l’ensemble de travail historique actif, la taille des sauvegardes et le travail de maintenance.

La documentation de Recorder avertit explicitement que laisser la base de données devenir trop volumineuse consomme de l’espace disque et peut ralentir Home Assistant. Son comportement par défaut de purge et de réorganisation vise notamment à limiter la croissance de la base de données.

La durée de conservation appropriée est donc une exigence fonctionnelle. Conservez les données haute résolution assez longtemps pour répondre aux vraies questions du foyer, et pas simplement parce que le disque dispose d’espace libre.

Le stockage et le cache déterminent le coût ressenti d’une même requête

Une requête Historique répétée peut être plus rapide parce que les pages de la base de données et du système de fichiers résident déjà en mémoire. Après un redémarrage ou en cas de pression mémoire, la même requête peut nécessiter davantage de lectures physiques. Un autre service qui écrit intensivement sur le même SSD peut également augmenter la latence sans modifier la requête SQL.

L’analyse de ZimaSpace sur l’augmentation des métadonnées et de l’historique de Home Assistant explique les causes liées aux écritures. Les performances des requêtes en sont la conséquence côté lecture : la quantité d’états conservés importe surtout lorsque la période sélectionnée ou l’ensemble de travail les touche réellement.

Mesurez le temps d’exécution des requêtes en parallèle de la latence du stockage et de la pression mémoire avant de déplacer les bases de données ou d’acheter du matériel plus rapide.

Réduisez le coût des requêtes en limitant les données inutiles, pas l’historique utile

• Excluez les entités dont les changements historiques n’apportent aucune valeur décisionnelle.
• Réduisez la fréquence des mises à jour à la source lorsque les changements fréquents ne sont pas utiles.
• Adaptez la conservation des données brutes à la période que les utilisateurs consultent réellement.
• Utilisez les statistiques à long terme pour les périodes étendues lorsque des agrégats horaires suffisent.
• Conservez Recorder sur un stockage fiable et à faible latence, avec une marge d’espace libre.
• Comparez la même période Historique avant et après chaque modification.

L’indicateur utile n’est pas uniquement la taille de la base de données. Il s’agit de l’évolution de la latence des requêtes en fonction du nombre de lignes conservées, de la période demandée, de l’état du cache et des conditions de stockage.

FAQ

Une base de données Recorder plus volumineuse ralentit-elle automatiquement les automatisations locales ?

Non. Le contrôle en direct des appareils et les requêtes historiques empruntent des chemins distincts. Ils peuvent s’influencer indirectement lorsque le travail de Recorder crée une contention partagée au niveau du processeur, de la mémoire ou du stockage, mais un graphique Historique lent ne prouve pas que le moteur d’automatisation est lent.