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

En faisant çà tu vas perdre des données puisque tu vas stocker des stats.
Moi je suis partisan de stocker le maximum de détail et de faire les stats en requête.
Si la table est bien conçue et bien indexée çà tiendra la route.
On gére actuellement une table avec 257 000 000 d'enregistrements, et çà ne rame pas plus que çà
 
1 enregistrement toutes les 5mn sur 36 serveurs, çà fait
24h * 60mn / 5mn * 36serveurs = 10368 enregistrements par 24h !!!  
Ce qui fait un peu moins de 3 800 000 enregistrements par an ...
Donc c'est pas la mort
 

En partie d'accord avec WhyMe.
 
Je pense que les données toutes les 5 minutes doivent être archivées le plus longtemps possible.
 
Par contre, l'idée de faire des tables de statistiques évitera effectivement de perdre du temps lors de la consultation des stats en question.
 
Ceci dit, je doute que les équipes réseau passent leur temps sur la base (à moins que tu ne leur fasse une sorte de "Widget" sur le bureau ?). Du coup, l'intérêt de ces tables de statistiques est relativement faible : si ça ne doit prendre que 5 secondes pour les recalculer, ce n'est pas forcément utile de faire ce calcul sans arrêt.
 
Pour cette raison, je t'encourage à utiliser des vues pour simuler tes tables de statistiques. Ainsi, à partir des données brutes, tu peux récupérer les informations correctement regroupées.
 
Mieux, avec SQL Server 2005, tu peux créer des vues matérialisées. C'est à dire qu'elles stockent les valeurs déjà calculées plutôt que de les recalculer à chaque requête. L'intérêt principal, c'est que si pour une raison ou une autre, tu dois modifier la table des relevés de compteurs à une date passée (genre, suite à une action particulière, il y a eu une utilisation anormale et exceptionnelle des serveurs, qui vient polluer les stats globales) le simple fait de modifier les données de base sera propagé dans les vues matérialisées immédiatement, alors que l'interrogation de la vue ne déclenchera pas de charge. En plus, une vue matérialisée est indexable, ce qui peut être très utile si tu as un réel besoin de performances.

C'est quoi donc une vue matérialisée ???
Cà m'interesse fortement ce concept pour justement 'stocker' des stats !

une vue matérialisée, c'est une simple vue, mais dont les donnée sont stockée. par contre, lorsque les données originales sont modifiée, elle se rafraîchit automatiquement à l'exécution suivante.

en gros une vue = un select  
une vue matérialisée = un select sauvegardé dans une table
 
 

oui, c'est ça, à la différence près que la vue matérialisée n'est pas figée : à chaque select dedans, tu es tout de même sûr que les données sont bien à jour.

Cà me parait pas mal comme principe je vais tester çà sur des vues plutôt costaud pour voir la différence