Beste Implementierung für vollständig auditierbares Datenmodell?

Question

Meine Anforderung ist ein Datenmodell, bei dem ein vollständiger Audit Trail für Änderungen an jedem Attribut jedes Objekts beibehalten wird. Objektdefinitionen sind ebenfalls fließend: Neue Attribute können erscheinen oder im Laufe der Zeit verschwinden. Dieser Audit-Trail wird getrennt von den ursprünglichen Datenbanken ausgeführt, sodass ein triggerbasiertes Auditingmodell nicht funktioniert.

In einer relationalen Datenbank kann ich dies mit einer einzigen großen ATTRIBUTE_HISTORY-Tabelle implementieren, die jede einzelne Änderung an jedem Attribut mit entsprechenden Zeitstempel- und Verantwortungsfeldern aufzeichnet.

Meine Frage: Sind irgendwelche der neueren Speichermodelle (BigTable, HBase, CouchDB, RDF-Speicher usw.) einem RDBMS für diesen Zweck überlegen?

Answer 1

Sie können auch ein Protokollierungssystem im Anwendungscode erstellen. Protokoll ruft jede Funktion auf, die die Datenbank ändert und zu einem erfolgreichen COMMIT führt.

Antwort auf Ihre Frage: Nein, verwenden Sie einfach ein RDBMS. Es ist einfacher, Abfragen im Protokoll auszuführen.

Answer 2

Ich sehe keinen Grund, warum ein Trigger nicht auf eine andere Datenbank verweisen kann. Alle Änderungen würden jedoch fehlschlagen, wenn diese Datenbank nicht verfügbar wäre. Dies kann ein Problem sein, wenn sich die Überwachungsdatenbank auf einem anderen Server befindet und die Verbindung unterbrochen ist. Aber unser Auditing erfolgt über Trigger und wir haben eine separate Audit-Datenbank.

Answer 3

Ich glaube nicht, dass ein bestimmtes Datenbankparadigma für ein Auditprotokoll als überlegen angesehen werden kann. Es ist weniger ein Datenmodellproblem als ein Protokollierungsproblem und kann als etwas orthogonal zum Datenspeicher betrachtet werden.

Das gesagt CouchDB kann so konfiguriert werden, nie alte Versionen von Dokumenten zu löschen. Mit dem Hinzufügen eines Zeitstempels und möglicherweise eines Benutzerfelds zu jedem Dokument können Sie die Funktion verwenden, um automatisch einen vollständigen Verlauf aller Objekte zu speichern, die jemals in der Datenbank gespeichert wurden. Dies könnte das einfachste Setup für die Audit-Protokollierung sein, das Sie in einer Datenbank erhalten könnten.

Wie für die anderen weiß ich nicht, welche Art von Unterstützung sie diesbezüglich haben könnten.

Caveats:

(Sie müssten auch folgen eine nie Strategie für Objekte in der db löschen und Objekte statt nur zum Löschen markieren)

(Für eine RDBMS die einfachste Lösung könnte eine einfache Tabelle, die protokolliert jedes Einfügen, Aktualisieren oder Löschen einer Anweisung, die in einem Textfeld mit Zeitstempel und Benutzerfeldern ausgeführt wird. Ich habe das einmal in einer Postgres-Datenbank gemacht und es funktionierte ziemlich gut zum Speichern von Verlauf)

Answer 4

Erstellen Sie eine Tabelle, die das enthält Namen der Tabellen, die Sie auditieren möchten (zB: AuditTable); Mindestspalten sollten sein: TableName (varchar), RandomValue (float). Fügen Sie einen Trigger für die AuditTable hinzu, der ausgelöst wird, wenn sich ein RandomValue ändert - der Job dieses Triggers besteht darin, den Audit-Trigger für jede aufgelistete Tabelle (TableName) in der AuditTable dynamisch neu zu erstellen. Der Audit-Trigger (für jede Tabelle) sollte in eine AuditRecord-Tabelle eingefügt werden, die Folgendes enthält: Tabellenname, Primärschlüssel-ID, Aktionstyp (INSERT/UPDATE/DELETE), ursprüngliche Feldwerte und aktualisierte Feldwerte. Wenn sich die Tabellenstruktur ändert, führt eine einfache Aktualisierung von RandomValue in AuditTable dazu, dass die Trigger erneut generiert werden. Sie müssen den Code schreiben, der den Trigger für eine bestimmte Tabelle automatisch generiert; Es wird empfohlen, dass für jede geprüfte Tabelle nur ein primärer Ganzzahlschlüssel verwendet wird.

Answer 5

Leistung wäre ein Anliegen für solche Audit-Trails. Ich würde für einen Cache (der ziemlich fehlertolerant ist) gehen und den Cache-Inhalt beibehalten, wenn die Zählung einen bestimmten Schwellenwert (sagen 1000 Datensätze) erreicht. Dies wäre idealerweise eine Stapelaktualisierung.

Ich denke, In-Memory-Datenbanken mit Persistenz-Optionen (wie H2) sollten auch das gleiche tun. Aber ich habe es nicht selbst benutzt.

Answer 6

Die Frage, wie die Daten gespeichert werden, hängt davon ab, wie sie unter anderen Problemen verwendet wird. Ich würde vorschlagen, mit etwas Einfachem fortzufahren, das Sie vorerst verstehen, und testen, ob Sie eine Vorstellung von der wahrscheinlichen Belastung haben, die Sie erwarten. Dann in Zukunft bei Bedarf Verbesserungen vornehmen.

In Bezug auf Ihr Problem mit einem Trigger-basierten Auditing-System habe ich einen Vorschlag, da es sich anhört, als ob Sie die Arbeit auf Datenbankebene erledigt haben. Verwenden Sie Trigger, um Änderungen an einer Tabelle in der Datenbank zu protokollieren, und über Nacht (oder wie auch immer) den Inhalt der Tabelle zu verarbeiten und den Audit-Trail dort zu erstellen, wo er gespeichert wird, und den Inhalt der Tabelle in der Datenbank zu leeren. Auf diese Weise können Sie Änderungen auf Datenbankebene erfassen, aber dennoch Ihre Anforderung erfüllen, den eigentlichen Audit-Trail an anderer Stelle zu speichern.