framboise314.fr

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 ?

estelle a écrit : Il y avait une erreur dans la requete

Et oui ...
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.

Merci pour tes conseils
A+
Estelle

Salut,

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
);

avec les indexes suivants :

Code : Tout sélectionner

CREATE INDEX dmkpcplh ON Domestik.probe_cpuload (host);
CREATE INDEX dmkpcplhs ON Domestik.probe_cpuload (host, sample_time);

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

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

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 :

: cpu.png (59.94 Kio) Vu 7248 fois

A+

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
);

Ce qui structurellement revient exactement au même que ce qu'elle avait fait.

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

Et toi, comment tu fais avec ta structure si tu as ajouter ou supprimer une charge ?

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.

Bon, aller pour ne pas laisser Estelle dans la confusion.

Bud Spencer a écrit :
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
);
Ce qui structurellement revient exactement au même que ce qu'elle avait fait.

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.
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
);

Bud 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 timestamp : 8 octets
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 :

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.

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).
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.

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 ...).

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.

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.

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.

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.

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.

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).

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).

Tout a fait, c'est pour ca que dans ce genre de système, il y a 3 passes :

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 mon exemple de supervision de serveurs où chacun d'entre eux envoie les données toutes les 5', les infos live sont conservées sur 2 jours, ensuite agrégées par heures en gardant la moyenne, le min et le max, et la purge à lieu après 2 mois.

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).

framboise314.fr

[RESOLU]ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI [RESOLU]

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI

Re: ecrire dans une BDD distante depuis mon PI