Recherche de logs

Bonjour à tous,

Je souhaite mettre un place un système permettant de consulter des logs qui seront stockés dans une base de données.

Ma base de données va être simpliste , mais j'aurais besoin de conseils pour l'optimisée car j'ai une volumétrie potentielle de 300Go de logs bruts.

En pièce jointe un modèle de base de données que j'ai fait, qu'en pensez-vous? Particulièrement au niveau de la gestion des dates ... serait-il plus efficace de faire des tables liées aux jour,mois,année pour accélérer la recherche ?
D'autre part quel SGBD me conseillez-vous? Oracle ou MySQL pour ce type de traitement. Sachant que j'aurais une importation quotidienne dans la base d'environ 750Mo.

Merci d'avance,
David

Bonjour David,


Où sont les règles de gestion ?

Qu’est-ce qu’un NE ? Un SGTQS ? Etc.

On ne fit pas un Type, mais un Homme... (à moins que vous n’expliquiez la signification réelle que vous avez en tête de ce mot).

A reformuler.

Bonjour fsmrel,

En effet je vais vous fournir quelques précisions :).

Je traite ici de logs de certains d'équipements du réseau (les Network Equipment ou NE), tous sont identifiés par un code 2 lettres et 2 chiffres appelé code SGTQS et un libellé concernant leur position géographique.

D'autres part chaque NE à 2 types de logs ici identifiés par la table Type, nous parlons de logs spontanés et de logs de commandes.

Donc pour résumé j'ai un ensemble d'équipements qui me remontent chacun 2 types de logs, tous les logs seront stockés dans la même table ici.

Ou bien faut-il préférer une table par type de logs pour avoir des tables avec moins d'enregistrements et ainsi optimiser la recherche?
(L'utilisateur fait une recherche en selectionnant le type de logs qu'il souhaite consulter)

Que pensez vous de la gestion des dates? Peut-elle être améliorée en l'externalisant dans des tables séparées?

Merci pour votre réponse :)

Bonjour David,

Citation:

---

Envoyé par david_69

un libellé concernant leur position géographique

---

A moins que l’utilisateur n’en ait vraiment cure, je suppose qu’une position géographique vaut plus qu’un simple libellé et mérite d’être décrite structurellement parlant, c'est-à-dire modélisée en tant que telle, sous forme de classe (UML) ou de type d’entité (Merise).

Citation:

---

Envoyé par david_69

Que pensez vous de la gestion des dates

---

A l’inverse, sans plus ample informé de votre part, une date prend ses valeurs dans le domaine (type) DATE, et a priori n’a pas à faire l’objet d’une classe ou d’un type d’entité. Soyez plus explicite quant à votre souci d’accélération ès matière.

Citation:

---

Envoyé par david_69

j'ai un ensemble d'équipements qui me remontent chacun 2 types de logs, tous les logs seront stockés dans la même table ici.
Ou bien faut-il préférer une table par type de logs

---

Il y a là matière à réflexion...
Supposons qu’un jour vous ayez un 3e type de log puis un 4e, puis un nième, alors que fait-on ?
Si vous choisissez d’avoir une table par type de log, si vous avez des traitements portant sur l’ensemble des logs, tous types confondus, vous pourrez vous poser la question de passer par la mise en œuvre d’une vue d’union des tables, au moins en consultation, sachant que mettre à jour la vue, en 2012, les SGBD ne le permettent pas, sauf à passer par un trigger encapsulant le traitement table par table. Je signale à cette occasion que MySQL ne permet pas les triggers sur vue (si ma mémoire est bonne).

Si vous choisissez d’avoir une seule table, je dirais qu’avec un SGBD comme DB2 ça n’est pas un problème, vous pouvez partitionner (séparer physiquement) sur le type de logs : sous le capot c’est comme si vous aviez deux tables, autrement dit, pour faire court, en termes de performance c’est blanc bonnet et bonnet blanc. De même, avec une machine base de données comme Teradata, vous pouvez paralléliser à fond, elle est faite pour ça (mais elle est peut-être un peu chère : en 1993, une machine à N processeurs coûtait N millions de francs...)

Concernant le choix du SGBD, évitez MySQL. Pour le reste, posez la question du partitionnement et plus généralement de l’indépendance des structures logique/physique dans les forums Oracle, SQL Server, PostGreSQL, etc. (pour DB2 et Teradata, je rappelle que tout va bien en l’occurrence).

Bonjour fsmrel,

Merci de votre réponse appliquée détaillée et claire, et désolé du retard de cette réponse, j'ai eu quelques empêchements.

En ce qui concerne les dates je me demandais si un champ de type DATE est suffisamment efficace lorsque les recherches peuvent portées sur plusieurs mois et être de l'ordre de la seconde près. Je demande donc un découpage fin sur un gros volume de données.

D'autres part je n'aurais pas d'autre type de logs que les 2 mentionnés et aucune consultation nécessitant d'union (question que je ne m'était même pas posée en effet :) ). Je pense donc qu'une dissociation en deux tables pourrait être de vigueur.

En ce qui concerne les SGBD mis à ma dispostion, il s'agirait de MySQL ou PosteGreSQL (voire Oracle, et encore). Si j'ai bien compris je ne disposerais pas vraiment d'une parallélisation avec ces SGBD, ce qui irait en faveur de deux tables physiques. Suis-je correct?

Dans ce cas où je dissocie une table par type de logs, dois-je toujours éviter MySQL et plutôt choisir PosteGreSQL?

Merci encore.

PS : le libellé sur la position géographique d'un NE est vraiment facultatif, seul le code importe en pratique... pensez-vous qu'une entité à part entière est nécessaire? De plus chaque site à une position différente, une table dissociée aurait donc autant d'entrée que de site.