Effektive Strategie zum Hinterlassen eines Audit-Trails/Änderungsverlaufs für DB-Anwendungen?

Question

Mit welchen Strategien haben Menschen Erfolg gehabt, um einen Änderungsverlauf für Daten in einer ziemlich komplexen Datenbank zu verwalten?Eine der Anwendungen, die ich häufig verwende und für die ich entwickle, könnte wirklich von einer umfassenderen Möglichkeit zur Verfolgung der Änderungen von Datensätzen im Laufe der Zeit profitieren.Derzeit können Datensätze beispielsweise eine Reihe von Zeitstempeln und geänderten Benutzerfeldern haben, aber wir verfügen derzeit nicht über ein Schema zum Protokollieren mehrerer Änderungen, beispielsweise wenn ein Vorgang rückgängig gemacht wird.In einer perfekten Welt wäre es möglich, den Datensatz nach jedem Speichern usw. so zu rekonstruieren, wie er war.

Ein paar Infos zur DB:

• Muss die Kapazität haben, um Tausende von Datensätzen pro Woche zu wachsen
• 50-60 Tische
• Hauptrevisionstabellen können jeweils mehrere Millionen Datensätze enthalten
• Angemessene Menge an Fremdschlüsseln und Indizes festgelegt
• Verwendung von PostgreSQL 8.x

Answer 1

In der Vergangenheit habe ich Trigger verwendet, um die Datenbankaktualisierungs-/Einfügungs-/Löschprotokollierung zu erstellen.

Sie können jedes Mal, wenn eine der oben genannten Aktionen für eine bestimmte Tabelle ausgeführt wird, einen Datensatz in eine Protokollierungstabelle einfügen, die die Aktion, den Datenbankbenutzer, den sie ausgeführt hat, den Zeitstempel, die Tabelle, für die sie ausgeführt wurde, und den vorherigen Wert verfolgt.

Es gibt jedoch wahrscheinlich eine bessere Antwort, da dies meiner Meinung nach erfordern würde, dass Sie den Wert zwischenspeichern, bevor der eigentliche Lösch- oder Aktualisierungsvorgang durchgeführt wird.Aber Sie könnten dies verwenden, um Rollbacks durchzuführen.

Answer 2

Eine Strategie, die Sie verwenden könnten, ist MVCC, Multi-Value Concurrency Control.Bei diesem Schema führen Sie niemals Aktualisierungen an einer Ihrer Tabellen durch, sondern führen lediglich Einfügungen durch und behalten die Versionsnummern für jeden Datensatz bei.Dies hat den Vorteil, dass zu jedem Zeitpunkt ein exakter Snapshot bereitgestellt wird, und umgeht außerdem die Update-Sperrprobleme, die viele Datenbanken plagen, vollständig.

Es handelt sich jedoch um eine riesige Datenbank, und „selects all“ erfordert eine zusätzliche Klausel, um die aktuelle Version eines Datensatzes auszuwählen.

Answer 3

Wenn Sie Hibernate verwenden, werfen Sie einen Blick auf JBoss Envers.Von der Projekthomepage:

Das Envers-Projekt zielt darauf ab, eine einfache Versionierung persistenter JPA-Klassen zu ermöglichen.Sie müssen lediglich Ihre persistente Klasse oder einige ihrer Eigenschaften, die Sie versionieren möchten, mit @Versioned annotieren.Für jede versionierte Entität wird eine Tabelle erstellt, die den Verlauf der an der Entität vorgenommenen Änderungen enthält.Anschließend können Sie ohne großen Aufwand historische Daten abrufen und abfragen.

Das ist etwas ähnlich Erics Ansatz, aber wahrscheinlich viel weniger Aufwand.Ich weiß jedoch nicht, welche Sprache/Technologie Sie für den Zugriff auf die Datenbank verwenden.

Answer 4

Das einzige Problem bei der Verwendung von Triggern besteht darin, dass sie den Leistungsaufwand beim Einfügen/Aktualisieren/Löschen erhöhen.Für eine höhere Skalierbarkeit und Leistung möchten Sie die Datenbanktransaktion auf ein Minimum beschränken.Die Prüfung über Trigger erhöht die für die Durchführung der Transaktion erforderliche Zeit und kann je nach Volumen zu Leistungsproblemen führen.

Eine andere Möglichkeit besteht darin, zu untersuchen, ob die Datenbank eine Möglichkeit zum Mining der „Redo“-Protokolle bietet, wie dies in Oracle der Fall ist.Redo-Protokolle werden von der Datenbank verwendet, um die Daten neu zu erstellen, falls sie ausfallen und wiederhergestellt werden müssen.

Answer 5

Ähnlich wie bei einem Trigger (oder sogar damit) können Sie jede Transaktion asynchron ein Protokollierungsereignis auslösen lassen und einen anderen Prozess (oder nur einen Thread) tatsächlich mit der Protokollierung beauftragen.Abhängig von Ihrer Anwendung gibt es viele Möglichkeiten, dies zu implementieren.Ich schlage vor, dass die Anwendung das Ereignis auslöst, damit Ihre erste Transaktion nicht unnötig belastet wird (was manchmal zu Sperren durch kaskadierende Prüfprotokolle führt).

Darüber hinaus können Sie möglicherweise die Leistung der Primärdatenbank verbessern, indem Sie die Prüfdatenbank an einem separaten Ort aufbewahren.

Answer 6

Ich verwende SQL Server, nicht PostgreSQL, daher bin ich mir nicht sicher, ob das für Sie funktioniert oder nicht, aber Pop Rivett hat hier einen tollen Artikel zum Erstellen eines Audit-Trails veröffentlicht:Pop Rivetts SQL Server-FAQ Nr. 5:Kommen Sie zum Audit Trail

Erstellen Sie eine Prüftabelle und erstellen Sie dann einen Auslöser für jede Tabelle, die Sie prüfen möchten.

Hinweis:verwenden Codeschmied um Ihre Auslöser aufzubauen.