Frage

Okay, hier ist das Szenario.Ich habe ein Dienstprogramm, das Tonnen von Datensätzen verarbeitet und entsprechend Informationen in die Datenbank eingibt.

Es arbeitet mit diesen Datensätzen in Multithread-Batches.Jeder dieser Stapel schreibt in dieselbe Protokolldatei, um für jeden Datensatz eine Workflow-Ablaufverfolgung zu erstellen.Potenziell könnten wir an einem Tag fast eine Million Protokollschreibvorgänge durchführen.

Sollte dieses Protokoll in eine Datenbank auf einem anderen Server gespeichert werden?Überlegungen:

  1. Der offensichtliche Nachteil, wenn mehrere Threads in dieselbe Protokolldatei schreiben, besteht darin, dass die Protokollnachrichten untereinander gemischt werden.In der Datenbank können sie nach Chargen-ID gruppiert werden.
  2. Leistung – was würde die Stapelverarbeitung mehr verlangsamen?Schreiben in eine lokale Datei oder Senden von Protokolldaten an eine Datenbank auf einem anderen Server im selben Netzwerk.Theoretisch ist die Protokolldatei schneller, aber gibt es hier ein Problem?

Gibt es Optimierungen, die bei beiden Ansätzen vorgenommen werden können?

Danke.

War es hilfreich?

Lösung

Ich unterstütze die anderen Antworten hier, hängt davon ab, was Sie mit den Daten machen.

Wir haben hier zwei Szenarien:

  1. Der Großteil der Protokollierung erfolgt in einer Datenbank, da Administratorbenutzer der von uns erstellten Produkte diese in ihrer netten kleinen App mit allem Drum und Dran anzeigen können müssen.

  2. Wir protokollieren alle unsere Diagnose- und Debug-Informationen in einer Datei.Wir müssen es nicht wirklich „verschönern“ und ehrlich gesagt, wir brauchen es nicht einmal oft, also protokollieren und archivieren wir größtenteils nur.

Ich würde sagen, wenn der Benutzer etwas damit macht, melden Sie sich bei DB an. Wenn es für Sie ist, reicht wahrscheinlich eine Datei aus.

Andere Tipps

Die interessante Frage: Sollten Sie sich entscheiden, sich bei der Datenbank anzumelden, lautet die Frage: Wo protokollieren Sie Datenbankverbindungsfehler?

Wenn ich mich in einer Datenbank protokolliere, habe ich immer einen sekundären Protokollspeicherort (Datei, Ereignisprotokoll usw.) für den Fall, dass es zu Kommunikationsfehlern kommt.Es erleichtert wirklich die spätere Diagnose von Problemen.

Eine Sache, die mir in den Sinn kommt, ist, dass Sie jeden Thread in seine eigene Protokolldatei schreiben und dann einen täglichen Batch-Lauf durchführen könnten, um sie zu kombinieren.

Wenn Sie sich in einer Datenbank anmelden, müssen Sie wahrscheinlich einige Anpassungen und Optimierungen vornehmen, insbesondere wenn die Datenbank über das Netzwerk verteilt ist.Zumindest müssen Sie die DB-Verbindungen wiederverwenden.

Haben Sie darüber hinaus besondere Anforderungen an die Anmeldedatenbank?Wenn alles, was Sie brauchen, ein „grep“ ist, dann glaube ich nicht, dass Sie durch die Anmeldung bei der Datenbank viel gewinnen.

Ich bin mir nicht sicher, ob es hilft, aber es gibt auch ein Dienstprogramm namens Microsoft LogParser mit dem Sie angeblich textbasierte Protokolldateien analysieren und wie eine Datenbank verwenden können.Von der Website:

Log Parser ist ein leistungsstarkes, vielseitiges Tool, mit dem universelle Abfrageberechnung auf textbasierte Daten wie Protokolldateien, XML-Dateien und CSV-Dateien sowie wichtige Datenquellen auf dem Windows®-Betriebssystem wie dem Ereignisprotokoll, der Registrierung, zugreifen können das Dateisystem und Active Directory®.Sie mitteilen Log Parser, welche Informationen Sie benötigen und wie Sie sie verarbeiten möchten.Die Ergebnisse Ihrer Abfrage können in textbasierter Ausgabe benutzerdefiniert oder auf mehr Spezialziele wie SQL, Syslog oder ein Diagramm bestehen bleiben.Die meisten Software sind so konzipiert, dass sie eine begrenzte Anzahl spezifischer Aufgaben erledigen.Log -Parser ist anders ...Die Anzahl der verwendet werden, die es verwendet werden kann, wird nur durch die Bedürfnisse und die Vorstellungskraft des Benutzers begrenzt.Die Welt ist Ihre Datenbank mit Log -Parser.

Ich selbst habe das Programm noch nicht verwendet, aber es scheint ziemlich interessant zu sein!

Oder wie wäre es, wenn Sie sich in eine Warteschlange einloggen?Auf diese Weise können Sie die Poller jederzeit auswechseln, um sich bei anderen Dingen anzumelden.Es macht Dinge wie das Rollover und Archivieren von Protokolldateien sehr einfach.Es ist auch schön, weil Sie Poller hinzufügen können, die verschiedene Dinge protokollieren, zum Beispiel:

  • ein Poller, der nach Fehlermeldungen sucht und diese an Ihr FogBugz-Konto sendet
  • Ein Poller, der nach Zugriffsverletzungen („x hat versucht, auf /foo/y/bar.html zuzugreifen“) auf eine Datei mit „Hacking-Versuchen“ sucht
  • usw.

Datenbank – da Sie mehrere Threads erwähnt haben.Synchronisierung sowie gefilterter Abruf sind meine Gründe für meine Antwort.
Prüfen Sie, ob ein Leistungsproblem vorliegt, bevor Sie sich für den Wechsel zu Dateien entscheiden
„Knuth:„Vorzeitige Optimierung ist die Wurzel allen Übels“ Ich bin in diesem Buch nicht weitergekommen ...:) :)

Es gibt Möglichkeiten, die Einschränkungen der Dateiprotokollierung zu umgehen.

Sie können jeden Protokolleintrag jederzeit mit einer Thread-ID beginnen und die einzelnen Thread-IDs heraussuchen.Oder eine andere Protokolldatei für jeden Thread.

Ich habe mich in der Vergangenheit in einem separaten Thread mit niedrigerer Priorität bei der Datenbank angemeldet.Ich muss sagen, dass die Abfragebarkeit sehr wertvoll ist, wenn man herausfinden möchte, was schief gelaufen ist.

Wie wäre es mit der Protokollierung in einer Datenbankdatei, beispielsweise einer SQLite-Datenbank?Ich denke, dass es Multithread-Schreibvorgänge verarbeiten kann – obwohl dies möglicherweise auch eigene Leistungseinbußen mit sich bringt.

Ich denke, es hängt stark davon ab, was Sie anschließend mit den Protokolldateien machen.

Von den beiden Vorgängen wird das Schreiben in die Protokolldatei schneller sein – insbesondere, da Sie das Schreiben in eine Datenbank auf einem anderen Server vorschlagen.

Wenn Sie jedoch versuchen, die Protokolldateien regelmäßig zu verarbeiten und zu durchsuchen, ist eine Datenbank der beste Ort dafür.

Wenn Sie ein Protokollierungsframework wie log4net verwenden, bieten diese häufig einfache, auf Konfigurationsdateien basierende Möglichkeiten zum Umleiten von Eingaben in eine Datei oder Datenbank.

Ich mag Gaius' Antwort.Stellen Sie alle Protokollanweisungen in eine threadsichere Warteschlange und verarbeiten Sie sie von dort aus.Für DB könnten Sie sie bündeln, sagen wir 100 Protokollanweisungen in einem Stapel, und für Dateien könnten Sie sie einfach in die Datei streamen, sobald sie in die Warteschlange kommen.

Datei oder Datenbank?Wie viele andere sagen;es hängt davon ab, wofür Sie die Protokolldatei benötigen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top