2016-04-27 12 views
6

Ich habe eine Java-Webanwendung erhalten, die einige Echtzeitereignisse empfängt und sie an die Benutzeroberflächenebene weiterleitet. Ich möchte alle wahrgenommenen Ereignisse protokollieren und da die Informationsmenge sehr groß sein wird, bevorzuge ich die Verwendung einer NoSQL-Datenbank.Bewährte Verfahren zum Protokollieren von Echtzeitdaten in eine NoSQL-DB

Ich habe für diesen Zweck einen Mongodb eingerichtet, der ein Dokument pro Ereignis einfügt. Das Problem ist, dass dieser Ansatz (ein Festplattenzugriff pro Ereignis) den gesamten Prozess dramatisch verlangsamt.

Also, welche Ansätze kann ich in dieser Situation nehmen? Welche Optionen sind dafür in mongodb verfügbar (z. B. Masseneinfügung, asynchrone Einfügung, Zwischenspeicherung, ...)? würde der Wechsel zu einer anderen NoSQL db-Implementierung einen Unterschied machen? Was sind die besten Praktiken hier?

+1

Es wäre gut, verkürzt sich einige weitere Details zu den erwarteten Leistungsbeschränkungen zu kennen. Wie groß ist der erwartete Durchsatz? 100/s? 10k/s? 1M/s? Durchschnittliche und mögliche Spitzen? Was ist die ungefähre Größe Ihrer Ereignisse bei der Serialisierung? 100 Bytes? 1 Megabyte? Müssen Sie Ihre vergangenen Ereignisse nur selten überprüfen, indem Sie sie möglicherweise für ein gegebenes Zeitfenster erneut wiedergeben, oder müssen Sie Ad-hoc-Abfragen zu ihnen durchführen? Wie lange brauchen Sie, um sie zu speichern - wird diese Datenbank zu Daten mit Jahren anwachsen, oder können Sie irgendeine Art von Säuberung/Archivierung zu Sekundärspeicher jede Woche oder so machen? –

Antwort

3

Ich habe einige Zeit gewartet, um andere Antworten zu sehen, aber meine Geduld verlieren. Ich habe MongoDB als Protokollspeicher für 3 Projekte verwendet (zwei für Java und eins für C#). Basierend darauf kann ich folgende wichtige Regeln zur Organisation der Protokollierung herausfinden:

  1. Verwenden Sie keine Indizes. Wenn Sie hauptsächlich schreiben, führen Indizes zu Leistungseinbußen. Wenn Sie Protokollanalysen nach dem Prozess benötigen, kopieren Sie Informationen in eine andere Datenbank oder Sammlung. Leider können Sie den Primärschlüssel _id nicht loswerden - lassen Sie ihn einfach so (GUID) oder ersetzen Sie ihn durch Auto-Inkrement NumberLong.

  2. Niedrigere Schreibprobleme. MongoDB verfügt über umfangreiche Optionen, um das Bewusstsein für Schreibvorgänge zu steuern. Sie können eine Übereinstimmung zwischen LogLevel und Schreibregeln festlegen. Zum Beispiel DEBUG, INFO, WARN kann mit WriteConcern.UNACKNOWLEDGED und gehen, FATAL kann mit WriteConcern.ACKNOWLEDGED gespeichert werden. Auf diese Weise verbessern Sie die Anwendungsleistung, indem Sie das Schreiben von Nachrichten mit niedriger Priorität vermeiden. Gleichzeitig sind Sie sicher, dass wichtige Nachrichten (die selten sind) im Speicher abgelegt werden.

  3. Zwischenspeicher für die Sammlungsinstanz. Ich meine, vermeiden Mongo Objekte über getDB oder getCollection jedes Mal zu lösen, wenn die Nachricht ankommt.

  4. Die Menge der vom Netzwerk übergebenen Daten verringern. Beschränken Sie Ihre Nachricht auf eine minimale Anzahl von Feldern. Zu lange Stack-Trace abschneiden. Schauen Sie, wie Spring 3.x vollständigen Namen der Klasse s.w.s.m.m.a.RequestMappingHandlerMapping statt some.whatever.sub.main.minimal.agent.RequestMappingHandlerMapping

Verwandte Themen