[RESOLU]ecrire dans une BDD distante depuis mon PI
Modérateurs : Francois, maxty01
Re: ecrire dans une BDD distante depuis mon PI
C'est ce que je viens de faire
Il y avait une erreur dans la requete
Tout est ok
Je peux mettre se post en résolu
Comment faire ?
Il y avait une erreur dans la requete
Tout est ok
Je peux mettre se post en résolu
Comment faire ?
-
- Raspinaute
- Messages : 1089
- Enregistré le : lun. 15 août 2016 21:38
Re: ecrire dans une BDD distante depuis mon PI
Et oui ...estelle a écrit : Il y avait une erreur dans la requete
Quand une requête ne passe pas, la première chose a faire c'est de la visualiser après sa construction. Les erreurs y apparaissent plus facilement et ca évite de passer trop de temps à chercher ailleurs.
Dans ton modèle ou tu places toute tes ruches dans un seul enregistrement, tu n'es pas obligé de faire l'insert à 0 des ruches inutilisées. Il suffit de paramétrer tes champs en non null avec 0 comme valeur par défaut.
Le modèle d'utilisation d'une table contenant un seul enregistrement par ruche peut sembler plus cohérant d'un point de vue relationnel, mais pour bien faire il te faut 2 tables. Une pour stocker les éphémérides (date tension température ...) et une pour le poids des ruches ou chaque enregistrement serait lié a son éphéméride par un id. l'Inconvénient, c'est que ca te fais multiplier les requêtes d'insert et ca va te compliquer les sélections. En apparence, ca peut sembler plus économique en data que ta solution de créer des ruches inutilisées en attente, mais ce n'est pas si évident que ca puisque tu vas multiplier les index (au minimum 1 par éphéméride + 2 par ruche et par enregistrement) alors qu'avec une seul table, c'est 1 seul index par lignes.
Un autre solution aurait été de ne créer que les champs des ruches existantes et d'automatiser la création de champ supplémentaire en cas nouvelle ruche.
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).
Re: ecrire dans une BDD distante depuis mon PI [RESOLU]
Merci pour tes conseils
A+
Estelle
A+
Estelle
-
- Raspinaute
- Messages : 1589
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: ecrire dans une BDD distante depuis mon PI
Salut,
Ainsi que je le disais, une seule table suffit : par exemple
avec les indexes suivants :
Ici, il s'agit de la charge de serveurs, tant ton cas, une seule valeur est nécessaire.
De plus, comme les ruches ont de simple numéro, il sera plus efficace d'avoir un INTEGER plutot qu'un TEXT.
Ensuite, avoir la liste des valeurs par exemple depuis minuit se fait par un
En jouant sur le formatage de la date, tu peux facilement sélectionner les plages de temps par jour, mois, semaine, ...
Il est conseillé de vérifier que les indexes sont bien pris en compte lors des requêtes par la commande EXPLAIN.
Il ne reste plus alors qu'a formater le résultat pour l'envoyer à Highchart ce qui donnera : A+
Ainsi que je le disais, une seule table suffit : par exemple
Code : Tout sélectionner
CREATE TABLE Domestik.probe_cpuload (
host TEXT NOT NULL,
load1 REAL,
load5 REAL,
load10 REAL,
sample_time TIMESTAMP WITH TIME ZONE
);
Code : Tout sélectionner
CREATE INDEX dmkpcplh ON Domestik.probe_cpuload (host);
CREATE INDEX dmkpcplhs ON Domestik.probe_cpuload (host, sample_time);
De plus, comme les ruches ont de simple numéro, il sera plus efficace d'avoir un INTEGER plutot qu'un TEXT.
Ensuite, avoir la liste des valeurs par exemple depuis minuit se fait par un
Code : Tout sélectionner
select sample_time, load1 from domestik.probe_cpuload where host='bPI' and sample_time > 'today' order by sample_time;
sample_time | load1
------------------------+-------
2016-12-03 00:03:16+01 | 0.05
2016-12-03 00:08:30+01 | 0.07
2016-12-03 00:13:43+01 | 0.03
2016-12-03 00:18:56+01 | 0.18
2016-12-03 00:24:10+01 | 0.05
2016-12-03 00:29:23+01 | 0.11
2016-12-03 00:34:35+01 | 0.13
2016-12-03 00:39:52+01 | 0.11
2016-12-03 00:45:05+01 | 0.16
2016-12-03 00:50:18+01 | 0.08
Il est conseillé de vérifier que les indexes sont bien pris en compte lors des requêtes par la commande EXPLAIN.
Il ne reste plus alors qu'a formater le résultat pour l'envoyer à Highchart ce qui donnera : A+
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 1089
- Enregistré le : lun. 15 août 2016 21:38
Re: ecrire dans une BDD distante depuis mon PI
Ce qui structurellement revient exactement au même que ce qu'elle avait fait.destroyedlolo a écrit :Code : Tout sélectionner
CREATE TABLE Domestik.probe_cpuload ( host TEXT NOT NULL, load1 REAL, load5 REAL, load10 REAL, sample_time TIMESTAMP WITH TIME ZONE );
Et toi, comment tu fais avec ta structure si tu as ajouter ou supprimer une charge ?destroyedlolo a écrit : Tu insères les poids de toutes tes ruches dans un unique enregistrement. Ce n'est pas une bonne idée car va falloir que tu modifie ton schema si rajoute une ruche
Si par contre dans ton modèle tu ne compares pas une ruche à une charge mais à un host, c'est encore pire parce que tu vas stocker à chaque enregistrement tous le éphémérides en plus de la mesure de poids individuelle et la, ca explose en terme de quantité de données. Dans ce cas sa méthode de stockage de toute les ruches en même temps dans un même enregistrement est beaucoup plus simple et beaucoup moins gourmande.
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).
-
- Raspinaute
- Messages : 1589
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: ecrire dans une BDD distante depuis mon PI
Bon, aller pour ne pas laisser Estelle dans la confusion.
Dans le cas des ruches, il est évident qu'il n'y aura qu'une seule valeur stockée.
Bref, le schema pour des ruches serait
Un small int : 2 octets
Un real : 4 octets
Soit un peu plus de 120k de données pures sur une année pour 24 ruches, soit environs 150k sur l'année si on tient compte d'un surpoids de 25% pour la soupe interne de la bdd.
sauf que :
Et quand on prend cet aspect en compte, ca n'a rien de simple. Et encore plus, si les balances des ruches sont intelligentes et poussent elles-mêmes les données.
C'est un EXEMPLE, et dans cette exemple, je stocke la charge CPU d'un serveur et, comme chaque admin le sait (la cible de la table que je donne en exemple), cette charge est donnée pour 1, 5 et 10 minutes, d'où 3 valeurs pour un même host.Bud Spencer a écrit :Ce qui structurellement revient exactement au même que ce qu'elle avait fait.destroyedlolo a écrit :Code : Tout sélectionner
CREATE TABLE Domestik.probe_cpuload ( host TEXT NOT NULL, load1 REAL, load5 REAL, load10 REAL, sample_time TIMESTAMP WITH TIME ZONE );
Dans le cas des ruches, il est évident qu'il n'y aura qu'une seule valeur stockée.
Bref, le schema pour des ruches serait
Code : Tout sélectionner
CREATE TABLE ruches (
id SMALLINT NOT NULL,
poids REAL,
sample_time TIMESTAMP WITH TIME ZONE
);
Un timestamp : 8 octetsBud Spencer a écrit :Si par contre dans ton modèle tu ne compares pas une ruche à une charge mais à un host, c'est encore pire parce que tu vas stocker à chaque enregistrement tous le éphémérides en plus de la mesure de poids individuelle et la, ca explose en terme de quantité de données.
Un small int : 2 octets
Un real : 4 octets
Soit un peu plus de 120k de données pures sur une année pour 24 ruches, soit environs 150k sur l'année si on tient compte d'un surpoids de 25% pour la soupe interne de la bdd.
sauf que :
sauf que donc, ce genre de méthode, en plus de demander de modifier son schéma à chaque ajout/suppression d'une ruche, à l'inconvénient de nécessiter que toutes les données soient présentent au même moment pour être stocké en base, ce qui est le pire SPOF qu'on puisse trouver dans un Scada (car c'est grosso modo ce qu'Estelle met en place).Bud Spencer a écrit :Dans ce cas sa méthode de stockage de toute les ruches en même temps dans un même enregistrement est beaucoup plus simple et beaucoup moins gourmande.
Et quand on prend cet aspect en compte, ca n'a rien de simple. Et encore plus, si les balances des ruches sont intelligentes et poussent elles-mêmes les données.
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 1089
- Enregistré le : lun. 15 août 2016 21:38
Re: ecrire dans une BDD distante depuis mon PI
Sauf que dans son procédé c'est 25 ruches, un date time, une température et une tension par cylcle.
Avec ta méthode, c'est 25 fois la date, 25 fois la température, 25 fois la tension et 25 requêtes d'insert par cycle. Si tu veux faire propre (et traiter 25 fois plus d'enregistrement) il faut aussi ajouter le poids des index sur les date time et sur les id de ruche. Penser aussi au besoin d'afficher les données de 25 ruches sur même graph. Une seule requête obligera un gros triage coté client en comptabilisant sur les ruches présentent dans le recordset pour ensuite distribuer les points graphiques en prenant en compte l'ajout de valeur nulle sur un axe de période pour les ruches n'ayant pas communiquées.
Avec des cycles d'enregistrement comme elle l'a fait, elle n'a pas toutes ces contraintes, elle fera beaucoup moins de requête, le traitement des données sera beaucoup plus simple et elle utilisera et transfèrera beaucoup moins de donnée. En plus elle a pensé a un id unique par enregistrement, ce qui j'imagine est la clé primaire de sa table et pour une débutante c'est très bien (tout le monde n'y pense pas ...).
Avec ta méthode, c'est 25 fois la date, 25 fois la température, 25 fois la tension et 25 requêtes d'insert par cycle. Si tu veux faire propre (et traiter 25 fois plus d'enregistrement) il faut aussi ajouter le poids des index sur les date time et sur les id de ruche. Penser aussi au besoin d'afficher les données de 25 ruches sur même graph. Une seule requête obligera un gros triage coté client en comptabilisant sur les ruches présentent dans le recordset pour ensuite distribuer les points graphiques en prenant en compte l'ajout de valeur nulle sur un axe de période pour les ruches n'ayant pas communiquées.
Avec des cycles d'enregistrement comme elle l'a fait, elle n'a pas toutes ces contraintes, elle fera beaucoup moins de requête, le traitement des données sera beaucoup plus simple et elle utilisera et transfèrera beaucoup moins de donnée. En plus elle a pensé a un id unique par enregistrement, ce qui j'imagine est la clé primaire de sa table et pour une débutante c'est très bien (tout le monde n'y pense pas ...).
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).
-
- Raspinaute
- Messages : 1589
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: ecrire dans une BDD distante depuis mon PI
Il faudrait détaillée l'archi utilisée : S'il y a un appareil central qui commande l’acquisition des valeurs et qui est capable de prendre en compte les esclaves absents, dans ce cas, oui, un record unique est la solution la plus simple.
Si par contre chaque ruche envoie ses données quand bon lui semble, il reste préférable de traiter les ruches indépendamment et les tension/température dans une table dédiée.
Si par contre chaque ruche envoie ses données quand bon lui semble, il reste préférable de traiter les ruches indépendamment et les tension/température dans une table dédiée.
Ben non, HighChart s'en charge très bien tout seul, nous n'avons qu'a lui fournir les séries de données brutes. Par contre, en effet, ca fait plus de données a transférer ... mais vu la faible volumétrie, ca ne posera pas de problème.Bud Spencer a écrit :Penser aussi au besoin d'afficher les données de 25 ruches sur même graph. Une seule requête obligera un gros triage coté client en comptabilisant sur les ruches présentent dans le recordset pour ensuite distribuer les points graphiques en prenant en compte l'ajout de valeur nulle sur un axe de période pour les ruches n'ayant pas communiquées.
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 1089
- Enregistré le : lun. 15 août 2016 21:38
Re: ecrire dans une BDD distante depuis mon PI
C'est exactement ca. En fait il est bien difficile de dire quelle méthode est la mieux adaptée sans avoir le avoir les 2 bouts du problèmes. En regardant le peu de code et explications données, cela sous entend qu'elle relève toute ses ruches puis les éphémérides globales (tension, température ...) et enregistre le cycle complet. La méthode est bonne et dans ce cas l'enregistrement par ligne est la solution la plus adaptée. Maintenant, si chaque ruche est indépendante et responsable du stockage de ses propres données sans respect d'un timing global, cela change tout.destroyedlolo a écrit :Il faudrait détaillée l'archi utilisée : S'il y a un appareil central qui commande l’acquisition des valeurs et qui est capable de prendre en compte les esclaves absents, dans ce cas, oui, un record unique est la solution la plus simple.
Si par contre chaque ruche envoie ses données quand bon lui semble, il reste préférable de traiter les ruches indépendamment et les tension/température dans une table dédiée.
Le choix de la méthode doit être fait en fonction du besoin de persistance des données. Si le but est un suivi sur du court terme ou si c'est de l'archivage de donnée pour de l'analyse sur du long terme. Si on suppose 25 ruches qui enregistrent leur donnée toute les heures, un enregistrement en ligne donnera ~8800 (24*365) enregistrement/an alors qu'avec la même périodicité en enregistrement indépendant, ca passe à plus de 200 000 (25*24*365).
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).
-
- Raspinaute
- Messages : 1589
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: ecrire dans une BDD distante depuis mon PI
Tout a fait, c'est pour ca que dans ce genre de système, il y a 3 passes :Bud Spencer a écrit :Le choix de la méthode doit être fait en fonction du besoin de persistance des données. Si le but est un suivi sur du court terme ou si c'est de l'archivage de donnée pour de l'analyse sur du long terme. Si on suppose 25 ruches qui enregistrent leur donnée toute les heures, un enregistrement en ligne donnera ~8800 (24*365) enregistrement/an alors qu'avec la même périodicité en enregistrement indépendant, ca passe à plus de 200 000 (25*24*365).
- la première avec les données récentes (lives) pour une analyses fine
- ensuite, les données plus anciennes sont agrégées pour à la fois réduire le besoin en stockage et surtout les rendre plus facilement manipulable
- si besoin, les données plus anciennes sont purgées lorsqu'elles n'ont plus aucun intérêts
Dans un autre cas sur lequel j'ai bossé, le scada d'un réseau gazier, les infos lives arrivent de manière totalement anarchiques (tant en fréquence qu'en qualité) sont gardées 10j, puis agrégée géographiquement / temporellement et purgées après 10 ans (contraintes légales) ... ce qui évidement implique une archi toute autre vu les volumétries engagées.
Mais, comme tu le dis, tout ceci dépend principalement des besoins utilisateurs (et des limites techniques imposées par le budget du projet).
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.