Discussion :

[kheops37]

Bonjour à tous,

Pour mon application, j'analyse des trames réseaux que je décortique puis je stocke les données dans une table. De temps en temps il y a des "évènements" qui sont stockés dans une autre table.
La première table compte environ 4 millions de lignes et la secondes 100 000. Il y a une purge automatique qui permet de ne garder les données que sur 20 jours mais la base fait quand même 2Go avec seulement ces 2 tables !

Lorsque je fais des requêtes sur la base c'est très long. Certaines requêtes mettent plus de 5 min à s'éxecuter (il y a parfois des jointures entre les deux tables aussi...).

J'ai tenté d'optimiser un peu les choses en mettant des index mais ça na pas changer fondamentalement les temps d'exécution (surement qu'il y a mieux à faire mais ma question n'est pas là).

En fait j'aimerai vous demander si pour ce genre d'application il n'y a pas mieux pour stocker les données qu'une base de données. Les requêtes sont simples et je me demande s'il n'y a pas une manière plus efficace de stocker les donner.

J'utilise une base SQL Server Express 2005. Je tiens à vous préciser que ce n'est pas moi qui ai fais les choix de conception, de SGBD, etc. Et les gens qui l'on fait, non pas calculé ni testé l'application avec une base pleine.... et donc maintenant que c'est en production on a des timeout partout parce que les requêtes sont super longues...

Merci d'avance

Matthieu

[CinePhil]

Un article qui peut t'aider à optimiser... ou à argumenter auprès de ta hiérarchie pour améliorer la situation.

[kheops37]

J'ai un peu commencé à lire ces articles. Mais ma question n'est pas là.

La question c'est : est ce qu'une base est bien le bon model de stockage de données?

Merci quand même

Matthieu

[CinePhil]

Tu disais au départ :

j'analyse des trames réseaux que je décortique puis je stocke les données dans une table. De temps en temps il y a des "évènements" qui sont stockés dans une autre table.

Si je comprends bien, tu n'enregistres pas la trame mais le résultat du décorticage pour en faire des données utilisables.

Tout dépend de l'utilisation que tu fais des données générées à partir des trames.
- Si tu utilises ensuite les données générées au niveau de chaque colonne, la base de données me semble un bon outil. Si c'est pour ensuite rassembler les trames la base de donnes ne sert effectivement pas à grand chose.
- Si tu veux faire des statistiques sur le nombre de morceaux de tel type ==> BDD
- Si tu veux pister, parmi les trames, les intrusions inopinées sur ton réseau ==> Pas BDD, ou alors seulement pour enregistrer les incidents (objet de la deuxième table peut-être ?)

Pour visser une vis, on prend un tournevis. Pour en visser 2000, on a peut-être intérêt à sortir la visseuse électrique. Dans les deux cas, on n'utilise pas un marteau !

[kheops37]

Oui c'est ça ! j'enregistre le décorticage des trames dans une table qui s'allonge très vite...

je me demandais donc juste s'il existait une structure de données différente d'une BDD pour stocker ça parce que les traitements sont très (trop) long. Donc je crois qu'il va falloir remanier la base et les requêtes.... aie !

Donc voilà je voulais éviter tout ça sachant qu'en plus (évidemment) l'usine à gaz est en production (euh venait pas faire un braquage, y a même pas de dérivé pétrochimique qui en sort de là )

Merci !

Matthieu

[SQLpro]

Si vous ne respectez pas les règles d'utilisation d'un SGBD relationnel, n'attendez pas de performances !

En effet les SGBD relationnels sont fait, comme leur nom indique, pour stocker des informations sous forme relationnelle, c'est à dire dans des tables liées les unes aux autres par un modèle relationnel.

Tout ce que vous ferez qui ne respecte pas la modélisation de données, et notamment le fait de ne pas respecter des formes normales, ne fera que pourrir les perfoamnces de votre système. Même avec des index cela ne servira à rien.

En revanche, bien modélisé et avec des index, des bases contenant des centaines de Go répondent rapidement !

Lisez les articles que j'ai écrit à ce sujet :
1) http://blog.developpez.com/sqlpro?ti...s_sur_ms_sql_s
2) http://sqlpro.developpez.com/optimisation/1/
3) http://sqlpro.developpez.com/optimisation/3/

A +

[kheops37]

Bonjour,

Je suis d'accord avec ce que vous dites.

Mais voici le format de ma table (exprimé de manière générique):

ID Date ID2 Val1 Val2 Val3 Val4 Val5

ID : clé de la table
Date : date de création de la ligne
ID2 : clé étrangère qui permet d'indiquer quel noeud à généré cette trame
Val1 .. Val5 : valeurs numériques décortiquées des trames

Pensez-vous qu'il y ait une quelconque relation à ajouter ?
Peut-être que je me trompe mais je ne crois pas que ce soit possible.
En ce qui concerne les index et les optimisations des requêtes, il y a assurément des choses à faire mais ce n'était pas l'objet de ma question : cela fait donc remanier une bonne partie de la base et du code qui va avec.

Merci

Matthieu

[CinePhil]

2 millions de lignes avec uniquement des colonnes numériques + une de date, ce n'est pas si énorme que ça !

Peut-être y a t-il aussi un problème de dimensionnement du serveur ?

On peut avoir la requête qui dure 5 minutes et que vous trouvez trop longue ?