Journal programmation : fichiers logs ou dans la base de donnée

Posté par  .
Étiquettes : aucune
0
23
juin
2004
Bonjour

J'aurais une petite question de programmation.
J'ai un démon qui recueille des informations réseaux périodiquement, genre tous les 5 minutes par exemple. Je me demandais si il fallait mieux stocker ces données brutes dans un fichier de log ou directement dans la base de donnée.
Le truc à savoir, c'est que ces données brutes seront examinées puis retraduit en graphique en agrégant certaines données, de facon périodique aussi.
J'ai un peu peur de claquer la base avec mes milliers d'entrées journalières. (C'est une base MYSQL).


Qu'en pensez-vous ?

  • # Je dirai ...

    Posté par  . Évalué à 2.

    qu'il ne faut pas avoir peur, ta base ne claquera pas. Simplement, si tu utilises une base, il te faudra implémenter des fonctions de log_rotate, qui pourrait AMHA être plus chiantes à faire que si tu utilises de simples fichiers.

    Tu fais la traduction log->graphique tous les combien par jour à peu près ?

    Personnellement, j'opterai pour une BDD. Maintenant, il faut savoir aussi une chose qui à mon avis est assez juste : tu as un objectif, pour le faire, utilise le moyen le plus simple, c'est souvent le meilleur compromis. Donc tout dépend de la simplicité que tu donnes à chacun des problèmes, selon un langage donné.

    Personnellement, je trouve plus simple en perl de faire ça avec une BDD qu'avec des fichiers. A toi de voir.

    PS : tu as à peu près combien de lignes/heures d'écrites dans un fichier, et tu compterais à à peu près combien le nombre de requêtes ?

    • [^] # Re: Je dirai ...

      Posté par  (site web personnel) . Évalué à 2.

      Simplement, si tu utilises une base, il te faudra implémenter des fonctions de log_rotate, qui pourrait AMHA être plus chiantes à faire que si tu utilises de simples fichiers.

      Au contraire, un simple "delete from mes_logs where ma_date < hier" (en gros...) suffira...

      • [^] # Re: Je dirai ...

        Posté par  . Évalué à 1.

        Ce n'est pas ce que j'appelle un log_rotate. Pour moi un log_rotate c'est plutot : hier -> archive ; archives du meme jour au mois dernier -> poubelle

        en gros hein

        • [^] # Re: Je dirai ...

          Posté par  (site web personnel) . Évalué à 0.

          Pour moi un log_rotate c'est plutot : hier -> archive ; archives du meme jour au mois dernier -> poubelle

          Ben le hier -> archive est automatique (ou implicite).
          et le -> poubelle est implementé par la requete de Colin.

          • [^] # Re: Je dirai ...

            Posté par  (site web personnel) . Évalué à 3.

            je pense que "archive", signifiait "archive compressée". Mais est-ce bien nécessaire ? Si c'est le cas on fait toujours faire un dump de "where date < hier" et le compresser et effacer le dump-.gz plus vieux régulièrement. Mais on perd pas mal de l'intérêt de la base.

            • [^] # Re: Je dirai ...

              Posté par  . Évalué à 0.

              Ben sinon tu fais un table par jour/mois pour faire ton logrotate. Pour les archives tu dump la table et tu compresse.....

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Base de données

    Posté par  (site web personnel) . Évalué à 2.

    Je pense que tu n'as pas à avoir peur de claquer la base de données, elle est faite pour ça!

    Moi, j'opterais pour la BD s'il y a des manipulations à effectuer sur les données. Car effectuer des opérations sur un fichier log peut s'avérer lourd et compliqué.

    Jeff Saucier

  • # Les deux mon capitan,

    Posté par  (site web personnel) . Évalué à 5.

    ou plutot, utilise syslog pour faire le log dans ton programme, et ensuite
    laisse au systeme logger le choix du stockage. (ex msyslog permet l'utilisation de bdd)
    Ca permet de deplacer le probleme, de beneficier des fonctions du syslog (deportation des logs sur d'autres machines, timestamp automatique, ...)

  • # DESIGN DE TABLE

    Posté par  . Évalué à 1.

    OK, je vais mettre tout ca dans une table.
    Par contre, est ce que ca va faire baisser les perfs si je mets toutes les logs dans une seule table (ce qui m'arrangerait) ou vaut mieux que j'essaie au possible de séparer dans plusieurs. Je veux dire par là, est ce que la commande SELECT ... WHERE prendra plus de temps sur une grosse table, ou sait il se débrouiller avec ses index ou autre chose ?

    • [^] # Re: DESIGN DE TABLE

      Posté par  . Évalué à 3.

      Ben pour savoir faudrait déjà avoir une idée de la taille de ta base. Mais bon, avec MySQL tu as le temps de voir venir à mon avis avant d'avoir des problèmes de perf.

    • [^] # Re: DESIGN DE TABLE

      Posté par  . Évalué à 2.

      ou sait il se débrouiller avec ses index
      Dans l'histoire, ce sera plutôt tes indexes. Je n'ai pas encore vu de BDD qui crée tout seul des indexes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.