Quelle est la meilleure approche en matière de journalisation : fichiers ou base de données ?

Question

Bon, voici le scénario.J'ai un utilitaire qui traite des tonnes d'enregistrements et saisit les informations dans la base de données en conséquence.

Il fonctionne sur ces enregistrements par lots multithread.Chacun de ces lots écrit dans le même fichier journal pour créer une trace de flux de travail pour chaque enregistrement.Potentiellement, nous pourrions créer près d’un million d’écritures de journaux par jour.

Ce journal doit-il être transformé en une base de données résidant sur un autre serveur ?Considérations :

1. L'inconvénient évident de l'écriture de plusieurs threads dans le même fichier journal est que les messages du journal sont mélangés les uns aux autres.Dans la base de données, ils peuvent être regroupés par identifiant de lot.
2. Performances : qu'est-ce qui ralentirait davantage le traitement par lots ?écrire dans un fichier local ou envoyer des données de journal à une base de données sur un autre serveur du même réseau.Théoriquement, le fichier journal est plus rapide, mais y a-t-il un piège ici ?

Y a-t-il des optimisations qui peuvent être effectuées dans l’une ou l’autre approche ?

Merci.

Answer 1

J'appuie les autres réponses ici, cela dépend de ce que vous faites avec les données.

Nous avons ici deux scénarios :

1. La majorité de la journalisation se fait dans une base de données, car les utilisateurs administrateurs des produits que nous construisons doivent pouvoir les visualiser dans leur jolie petite application avec toutes les fonctionnalités.

2. Nous enregistrons tous nos diagnostics et informations de débogage dans un fichier.Nous n'avons pas besoin de vraiment "l'embellir" et TBH, nous n'en avons même pas souvent besoin, donc nous nous contentons d'enregistrer et d'archiver pour la plupart.

Je dirais que si l'utilisateur fait quelque chose avec, connectez-vous à la base de données, si c'est pour vous, alors un fichier suffira probablement.

Answer 2

La question intéressante, si vous décidez de vous connecter à la base de données, est de savoir où enregistrer les erreurs de connexion à la base de données ?

Si je me connecte à une base de données, j'ai toujours un emplacement de journal secondaire (fichier, journal des événements, etc.) au cas où il y aurait des erreurs de communication.Cela facilite vraiment le diagnostic ultérieur des problèmes.

Answer 3

Une chose qui me vient à l'esprit est que vous pouvez demander à chaque thread d'écrire dans son propre fichier journal, puis d'effectuer une exécution par lots quotidienne pour les combiner.

Si vous vous connectez à la base de données, vous devrez probablement effectuer quelques réglages et optimisations, surtout si la base de données se trouve sur le réseau.Au moins, vous devrez réutiliser les connexions DB.

Par ailleurs, avez-vous des besoins spécifiques concernant la base de données de connexion ?Si tout ce dont vous avez besoin est un "grep", alors je ne pense pas que vous gagniez grand-chose en vous connectant à la base de données.

Answer 4

Je ne sais pas si cela aide, mais il existe également un utilitaire appelé Microsoft LogParser que vous pouvez soi-disant utiliser pour analyser des fichiers journaux textuels et les utiliser comme s'il s'agissait d'une base de données.Depuis le site Web :

Le journal de journal est un outil puissant et polyvalent qui fournit un accès à la requête universel aux données basées sur le texte telles que les fichiers journaux, les fichiers XML et les fichiers CSV, ainsi que les sources de données clés du système d'exploitation Windows® telles que le journal des événements, le registre, Le système de fichiers et Active Directory®.Vous indiquez à Log Parser quelles informations vous avez besoin et comment vous le souhaitez.Les résultats de votre requête peuvent être formés sur mesure dans la sortie basée sur le texte, ou ils peuvent être persistés à des cibles plus spécialisées comme SQL, Syslog ou un graphique.La plupart des logiciels sont conçus pour accomplir un nombre limité de tâches spécifiques.L'analyseur de journal est différent ...Le nombre de façons dont il peut être utilisé est limité uniquement par les besoins et l'imagination de l'utilisateur.Le world est votre base de données avec Log Analyseur.

Je n'ai pas utilisé le programme moi-même, mais il semble assez intéressant !

Answer 5

Ou que diriez-vous de vous connecter à une file d’attente ?De cette façon, vous pouvez désactiver les interrogeurs chaque fois que vous souhaitez vous connecter à différentes choses.Cela rend les choses comme le roulement et l'archivage des fichiers journaux très faciles.C'est également bien car vous pouvez ajouter des interrogeurs qui se connectent à différentes choses, par exemple :

• un sondeur qui recherche les messages d'erreur et les publie sur votre compte FogBugz
• un interrogeur qui recherche les violations d'accès (« x a essayé d'accéder à /foo/y/bar.html ») à un fichier « tentatives de piratage »
• etc.

Answer 6

Base de données - puisque vous avez mentionné plusieurs threads.La synchronisation ainsi que la récupération filtrée sont les raisons de ma réponse.
Vérifiez si vous avez un problème de performances avant de décider de passer aux fichiers
« Knuth :L'optimisation prématurée est la racine de tous les maux. " Je ne suis pas allé plus loin dans ce livre...:)

Answer 7

Il existe des moyens de contourner les limitations de la journalisation des fichiers.

Vous pouvez toujours démarrer chaque entrée de journal avec un identifiant de thread quelconque et récupérer les identifiants de thread individuels.Ou un fichier journal différent pour chaque thread.

Je me suis déjà connecté à la base de données dans le passé, dans un fil de discussion séparé avec une priorité inférieure.Je dois dire que la possibilité d'interroger est très utile lorsque vous essayez de comprendre ce qui n'a pas fonctionné.

Answer 8

Que diriez-vous de vous connecter à un fichier de base de données, par exemple une base de données SQLite ?Je pense qu'il peut gérer les écritures multithread - bien que cela puisse également entraîner ses propres frais généraux de performances.

Answer 9

Je pense que cela dépend grandement de ce que vous faites ensuite avec les fichiers journaux.

Des deux opérations, l'écriture dans le fichier journal sera plus rapide, d'autant plus que vous suggérez d'écrire dans une base de données sur un autre serveur.

Cependant, si vous essayez ensuite de traiter et de rechercher régulièrement les fichiers journaux, le meilleur endroit pour le faire serait une base de données.

Si vous utilisez un framework de journalisation comme log4net, ils fournissent souvent des moyens simples basés sur des fichiers de configuration pour rediriger les entrées vers un fichier ou une base de données.

Answer 10

J'aime la réponse de Gaius.Placez toutes les instructions de journal dans une file d'attente threadsafe, puis traitez-les à partir de là.Pour DB, vous pouvez les regrouper par lots, disons 100 instructions de journal en un seul lot et pour les fichiers, vous pouvez simplement les diffuser dans le fichier au fur et à mesure qu'elles arrivent dans la file d'attente.

Fichier ou base de données ?Comme beaucoup d’autres le disent ;cela dépend de la raison pour laquelle vous avez besoin du fichier journal.