Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 5 sur 5

Discussion: Recherche de logs

  1. #1
    Invité de passage
    Homme Profil pro David
    Inscrit en
    décembre 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Nom : Homme David
    Localisation : France

    Informations forums :
    Inscription : décembre 2012
    Messages : 3
    Points : 0
    Points
    0

    Par défaut 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
    Images attachées Images attachées

  2. #2
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 633
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 633
    Points : 12 289
    Points
    12 289

    Par défaut

    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.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  3. #3
    Invité de passage
    Homme Profil pro David
    Inscrit en
    décembre 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Nom : Homme David
    Localisation : France

    Informations forums :
    Inscription : décembre 2012
    Messages : 3
    Points : 0
    Points
    0

    Par défaut

    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

  4. #4
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 633
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 633
    Points : 12 289
    Points
    12 289

    Par défaut

    Bonjour David,


    Citation Envoyé par david_69 Voir le message
    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 Voir le message
    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 Voir le message
    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).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  5. #5
    Invité de passage
    Homme Profil pro David
    Inscrit en
    décembre 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Nom : Homme David
    Localisation : France

    Informations forums :
    Inscription : décembre 2012
    Messages : 3
    Points : 0
    Points
    0

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •