Die erste Frage sollte lauten:Was würden Sie mit diesen Daten tun? Wenn Sie keine klaren geschäftlichen Anforderungen haben, tun Sie es nicht.
Ich habe etwas Ähnliches gemacht und nach 3 Jahren Betrieb gibt es etwa 20% der "gültigen Daten" und der Rest sind "Vorgängerversionen". Und es sind 10 Millionen + 40 Millionen Datensätze. In den letzten drei Jahren hatten wir 2 (zwei) Anfragen, um die Historie von Änderungen zu untersuchen, und beide Male waren Anfragen albern – wir zeichnen den Zeitstempel der Datensatzänderung auf und wir wurden gebeten, zu überprüfen, ob Personen Überstunden gemacht haben (nach 17:00 Uhr).
Jetzt stecken wir in einer übergroßen Datenbank fest, die 80 % der Daten enthält, die niemand braucht.
BEARBEITEN:
Da Sie nach möglichen Lösungen gefragt haben, werde ich beschreiben, was wir getan haben. Es ist ein bisschen anders als die Lösung, die Sie in Betracht ziehen.
- Alle Tabellen haben Ersatz-Primärschlüssel.
- Alle Primärschlüssel werden aus einer einzigen Sequenz generiert. Dies funktioniert gut, da Oracle Nummern generieren und zwischenspeichern kann, sodass hier keine Leistungsprobleme auftreten. Wir verwenden ORM und wollten, dass jedes Objekt im Speicher (und der entsprechende Datensatz in der Datenbank) eine eindeutige Kennung hat
- Wir verwenden ORM und Zuordnungsinformationen zwischen Datenbanktabelle und Klasse liegen in Form von Attributen vor.
Wir zeichnen alle Änderungen in einer einzigen Archivtabelle mit folgenden Spalten auf:
- id (Ersatz-Primärschlüssel)
- Zeitstempel
- Ursprungstabelle
- ID des ursprünglichen Datensatzes
- Benutzer-ID
- Transaktionstyp (Einfügen, Aktualisieren, Löschen)
- Daten als varchar2-Feld aufzeichnen
- das sind tatsächliche Daten in Form von Feldname/Wert-Paaren.
Das funktioniert so:
- ORM hat Befehle zum Einfügen/Aktualisieren und Löschen.
- Wir haben eine Basisklasse für alle unsere Geschäftsobjekte erstellt, die die Einfüge-/Aktualisierungs- und Löschbefehle außer Kraft setzt
- Befehle zum Einfügen/Aktualisieren/Löschen erstellen eine Zeichenfolge in Form von Feldnamen/Wert-Paaren unter Verwendung von Reflektion. Code sucht nach Zuordnungsinformationen und liest Feldname, zugeordneten Wert und Feldtyp. Dann erstellen wir etwas Ähnliches wie JSON (wir haben einige Modifikationen hinzugefügt). Wenn eine Zeichenfolge erstellt wird, die den aktuellen Status des Objekts darstellt, wird sie in die Archivtabelle eingefügt.
- Wenn ein neues oder aktualisiertes Objekt in der Datenbanktabelle gespeichert wird, wird es in seiner Zieltabelle gespeichert und gleichzeitig wird ein Datensatz mit dem aktuellen Wert in die Archivtabelle eingefügt.
- Wenn das Objekt gelöscht wird, löschen wir es aus seiner Zieltabelle und fügen gleichzeitig einen Datensatz in die Archivtabelle ein, der den Transaktionstyp ="DELETE" hat
Profi:
- Wir haben keine Archivtabellen für jede Tabelle in der Datenbank. Wir müssen uns auch keine Gedanken über die Aktualisierung der Archivtabelle machen, wenn sich das Schema ändert.
- Das komplette Archiv wird von den "aktuellen Daten" getrennt, sodass das Archiv keine Leistungseinbußen für die Datenbank verursacht. Wir legen es auf einem separaten Tablespace auf einer separaten Festplatte ab und es funktioniert einwandfrei.
- Wir haben 2 Formulare zum Anzeigen des Archivs erstellt:
- Allgemeiner Betrachter, der Archivtabellen gemäß Filter auf Archivtabelle auflisten kann. Filtern Sie Daten, die der Benutzer in das Formular eingeben kann (Zeitraum, Benutzer, ...). Wir zeigen jeden Datensatz im Formular Feldname/Wert und jede Änderung ist farblich gekennzeichnet. Benutzer können alle Versionen für jeden Datensatz sehen und sie können sehen, wer und wann Änderungen vorgenommen hat.
- Rechnungsbetrachter - dieser war komplex, aber wir haben ein Formular erstellt, das die Rechnung sehr ähnlich dem ursprünglichen Rechnungserfassungsformular anzeigt, aber mit einigen zusätzlichen Schaltflächen, die verschiedene Generationen anzeigen können. Es hat viel Mühe gekostet, dieses Formular zu erstellen. Das Formular wurde einige Male verwendet und dann vergessen, weil es im aktuellen Arbeitsablauf nicht benötigt wurde.
- Code zum Erstellen von Archivdatensätzen befindet sich in einer einzigen C#-Klasse. Es sind keine Trigger für jede Tabelle in der Datenbank erforderlich.
- Leistung ist sehr gut. Zu Spitzenzeiten wird das System von etwa 700-800 Benutzern verwendet. Dies ist die ASP.Net-Anwendung. Sowohl ASP.Net als auch Oracle laufen auf einem dualen XEON mit 8 GB RAM.
Nachteile:
- Das Einzeltabellen-Archivformat ist schwerer zu lesen als eine Lösung, bei der es eine Archivtabelle für jede der Datentabellen gibt.
- Die Suche nach Nicht-ID-Feldern in der Archivtabelle ist schwierig - wir können nur
LIKE
verwenden Operator auf Zeichenfolge.
Also noch einmal, überprüfen Sie die Anforderungen an die Archivierung . Es ist keine triviale Aufgabe, aber Gewinne und Nutzen können minimal sein.