Petit message pour récapituler notre call @Terdious 
C’était chouette de s’appeler pour clarifier un peu tout ça !
- Je pense que c’est aux développeurs d’intégrations de mettre en place les bons mécanismes pour que leurs intégrations ne soient pas « trop agressives » sur la quantité de donnée qu’elles envoient à Gladys.
Dans le cas de Netatmo, je suis pour faire du cas par cas dans le code.
Exemple: Feature « batterie »: max 1 point par 30 minutes si pas de changement de valeur.
L’objectif est que nous trouvions les bonnes limites qui soient les plus précises sans compromettre la taille de la DB, ni les performances de Gladys.
Pour l’utilisateur, c’est transparent et ça fonctionne automatiquement, dans la philosophie du projet.
- Sur le moyen terme, je suis de très près DuckDB, une base de donnée fichier (comme SQLite) mais adaptée aux données time-series. L’idée ne serait pas de remplacer le SQLite de Gladys ( qui est tout à fait adapté au reste de Gladys ), mais uniquement de transférer nos données time-serie sur un fichier dédié. D’après mes tests, la réduction en taille de DB pour des performances supérieures à ce qu’on fait actuellement est assez phénoménales ( Cf : Gestion plus fine de l'historique des états - #18 par pierre-gilles )
Pour l’instant je suis en stand-by sur ce développement car ils sont encore en beta (0.10.0), à voir si eux se considèrent comme « production-ready » ou pas.