Discussion :

[bouliz]

Bonjour à tous, je sollicite votre aide pour un petit probleme de conception de base de données.

Avant je vous précise un peu le contexte. Je viens de commencer un stage dans une grosse boite et je suis chargé de mettre en oeuvre un outil qui permet de suivre les statistiques de fonctionnement des serveurs UNIX. Pour ça j'ai à ma disposition un outil qui me permet de collecter des indicateurs techniques (% CPU utilisé, memoire, etc, ...) toutes les 5 minutes.

Le but c'est de creer des tableaux de bords pour les equipes techniques qui leur permet de suivre le fonctionnement des serveurs en temps réel mais aussi sur plusieurs mois.

Mon problème, c'est de creer une base de données qui permet d'avoir des donnees precises sur les derniers jours en cours (toutes les 5 minutes) mais plus generales sur les semaines ou mois qui precedent (toutes les heures voir tous les jours).

Pour ça, je pensais faire 3 tables, une contenant les données en temps réel (stats toute les 5 minutes), une contenant une moyenne par heure que je remplirai toutes les heures à partir de la premiere table, et une derniere contenant une moyenne par jour que je remplirai à partir de la seconde table.

Il y a 36 serveurs à surveiller et à peu près 10 indicateurs à surveiller, la base grossit donc vite. Avec cette methode, je peux ainsi garder la table contenant les données toutes les 5 minutes quelques jours, celle contenant les données toutes le heures quelques semaines, et la derniere quelques mois.

Que pensez vous de cette solution ?, ya t'il d'apres vous et d'après votre experience (la mienne etant plutôt maigre) un moyen plus intelligent de resoudre mon probleme ?

edit : je suis sous sql server

Je vous remercie par avance pour l'aide que vous pourrez m'apporter

[RV80]

Vu que tu ne précises pas le schéma de table, pour l'instant ça a l'air correct(en même temps ta question ne concerner ce point). Car un enregistrement toute les 5 minutes ça ne fait que 288 enregistrements par jour ce n'est pas si énorme que ça sachant que cette table sera régulièrement effacé d'après ce que tu dis.

[bouliz]

Deja merci pour ta reponse RV80. Par contre ça ne fait pas seulement 288 enregistrements par jour mais bien 36 * 10 * 12 *24 = 100 000

Il y a 36 serveurs et pour chaque serveur 10 indicateurs techniques à stocker (cosommation CPU, memoire, etc, ...).

Mais oui cette table n'aura un historique de quelques jours donc ça devrait aller.
Sinon justement j'avoue avoir quelques problemes pour la modelisation. Est t'il bien rigoureux d'avoir 3 tables differentes qui ont exactement les mêmes données ?

[bouliz]

voila un schema simplifié de la base. Un type de metrique est en fait un indicateur (%CPU consommé, activite disque dur,..).

Dans la table temps réel je stockerai les donnees toutes les 5 minutes.
Dans la table horaire, je stockerai une moyenne sur l'heure à partir de la premiere table.
Dans la table journaliere, je ferai une moyenne sur un jour pour pouvoir réaliser des graphes sur plusieurs mois.

Ma modelisation vous parait t'ellle bonne ? j'ai des doutes sur l'heritage.

[mathieu]

déjà on ne parle pas trop d'héritage dans les basse de données mais surtout de relations entre les données
ensuite les tables avec les moyennes horaires et journalières contiennent des données redondantes avec la table des données en temps réel donc elles ne font pas partie de ta structure de données. par contre tu peux garder ces 2 tables pour accélérer la lecture des données

pour aller plus loin dans ton application, tu peux supprimer de la table "temps réel" les données que tu as utilisé pour les statistiques horaires si tu n'en a plus besoin ensuite

[bouliz]

Merci mathieu. J'ai tenu compte de tes remarques pour la modelisation. Effectivement, mon probleme, c'etait la redondance des données mais je crois que je n'ai pas le choix puisque je ne garde les donnees temps reel que quelques jours. J'ai besoin de données precises en temps reel mais moins precises a l'echelle du mois.

Une question à ce propos, je travaille sous sql server, sans aller dans les details technique evidemment, comment peut t'on supprimer automatiquement des données vieilles d'un mois par exemple ?

[mathieu]

Une question à ce propos, je travaille sous sql server, sans aller dans les details technique evidemment, comment peut t'on supprimer automatiquement des données vieilles d'un mois par exemple ?

tu peux par exemple lancer une requête SQL "DELETE"
oui je sais que ce n'est pas très automatique de ton point de vue mais si tu as besoin de plus de détails je t'invite à aller sur le forum MS SQL-Server

[souviron34]

je n'utilise pas de SGBD tout fait, mais dans mon domaine les bases sont très grosses et temps réel (250 000 lignes / heure) à conserver pendant des années.

Le moyen le plus rapide et efficace que nous ayons trouvé est tout simplement un "flat file", dont le nom contient (en fonction du volume des données et de leur fréquence) soit l'année, le mois, ou le jour.

Tout est stocké chronologiquement dans ce fichier. Du coup, une recherche dychotomique temporelle se fait en moins d'une 1/2 seconde pour 2 gigs.

La maintenance est simple, les sauvegardes aussi, les corrections, si erreur il y a , aussi.

Et , mais là cela dépend de la demande du point de vue des données archivées, je ne réduirais pas la fréquence temporelle (exemple : reproduire une situaton qui s'est produite... (contestation, erreur, etc..) Beaucoup mieux de pouvoir la reproduire à l'identique.

Donc pour moi, si les données arrivent aux 5 minutes, eh bien que ce soit 1 jour, un mois, un an, ça comptient toujours toutes les données....

[SQLpro]

Contrairement a ce aue dit mathieu l'heritage des donnees existe bien dans la modelisation et cela il y a fort longtemps...
Lisez l'article aue j'ai ecrit a ce sujet :
http://sqlpro.developpez.com/cours/m...tion/heritage/

Mais il est vrai aue le formation en France est assez nulle en matiere de SGBDR !

A +

[overider]

je te conseillerais d'utiliser cacti.

[souviron34]

Si tu connais le C, voici l'exemple dont je parlais plus haut

http://www.developpez.net/forums/sho...d.php?t=297408

Fichier d'environ 1 à 6 Gigs d'enregistrements par an...