Binäre Suche oder Btree Index Update-Problem

Ich würde verwenden diff .

Wenn ich es in meinem eigenen Programm zu implementieren benötigen, würde ich einen der Algorithmen verwenden , um die Suche nach längster gemeinsamen Teilfolge von zwei Sequenzen, die Behandlung jede Datei als eine Folge von Linien.

„Dann, wenn wir die nächste Datei morgen zu erhalten, gehen wir durch sie Zeile für Zeile, einen neuen Hash für jede Zeile zu schaffen und es den Hash des Vortages zu vergleichen.“

Verstanden: 1m Linien der heutigen Hash-Werte im Vergleich zu 1 m Zeilen des gestrigen Wertes.

Sie Zeilen eingefügt oder entfernt werden? Wenn nicht, ist dies ein einfacher Satz von parallel zu sehen liest, wenn die Hash-Werte unterschiedlich sind.

Wenn hinzufügt oder Umzüge sind, werden Sie den Diff-Algorithmus, um zu bestimmen, den Umfang der Änderung verwenden.

All das ist in Ordnung. Nicht zu schwierig zu implementieren.

In diesem Zusammenhang macht die folgende keinen Sinn.

Der Vergleich verwendet ein binäres Suchverfahren der Zeichenfolge vergleichen (> <Operanden) Dies liefert ein Ergebnis in einem Durchschnitt von vier Wiederholungen.

Gibt es irgendeine Art an die Hash-Werte der Bestellung? Oder eine Baumstruktur?

Ein Buch von 1 Million Zeilen ist riesig: Es gibt vielleicht 30 - 50 Zeilen pro Seite, also lassen Sie sich großzügig sein und 100 Zeilen pro Seite übernehmen, die 10.000 Seiten in dem Buch bedeutet.

Linien von 1 KB sind auch viel größer als normal ist; Grund Lesbarkeit schlägt bei weitem nicht, dass viele Zeichen pro Zeile. Beabsichtigen Sie Linien von bis zu 1 KB oder Chunk der Datei in 1 KB chunks Hash? Ein Problem mit Ihrem Schema ist, dass alle wiederholten Zeilen würde eine wiederholte Hash haben; Sie konnte nie, wenn eine dieser Linien identifizieren wurde hinzugefügt oder gelöscht werden.

Sie würden vermutlich müssen auch die Herausgeber von gelöschten Zeilen benachrichtigen.

Wie bei Glomek, würde ich diffauf die Datei. Wenn Sie die Datei unter RCS oder CVS Kontrolle zu halten, würden Sie nur aktuelle Version der Datei und die Differentiale zwischen vor gespeicherten Versionen. Damit würden Sie auch kumulativ Diffs über eine Woche oder einen Monat liefern können.

Und ich würde wahrscheinlich nicht meine eigene B-Tree-Indizierung entwickeln.

die Lösung, die Sie beschreiben, ist ähnlich dem rsync-Algorithmus. Ein wichtiger Punkt ist, dass rsync bestehende Stücke überall in der Zieldatei zu erkennen hat, auf jedem von den ursprünglichen versetzt.

Wenn Sie Ihre Dateien rekord strukturiert sind wirklich, können Sie ein wenig vereinfachen, wie Sie vorschlagen. Wenn nicht, müssen Sie eine Roll Prüfsumme.

auch, müssen Sie Umordnungen erkennen? oder nur Einfügungen / Löschungen / Ersatz?

der allgemeinste Fall ist der vollständige rsync-Algorithmus, der so geht:

• Parameter Definition:

  1. Wählen Sie eine Blockgröße 512 oder 1k in der Regel ok arbeiten.
     • ein ‚starken‘ Prüfsumme wählen. so etwas wie von MD4 oder so. 64bits gibt es genug.
     • ein ‚schwachen‘ Roll Prüfsumme wählen. eine, die Sie ‚subtrahieren‘ der Schwanz Byte und ‚add‘ ein Kopf-Byte erhalten die Prüfsumme eines Blocks 1-Byte nach vorne ermöglicht. in der Regel eine 16-Bit-Prüfsumme funktioniert ok.

• Unterschrift der alten Datei:

  1. Traverse die gesamte alte Datei, berechnen bei jedem Block sowohl schwache als auch starke Prüfsummen. mit 16 und 64 Bit-Prüfsummen und 512 Byte-Blöcken, die bedeuten 10bytes pro Block oder 20KB pro Megabyte. dies ist die ‚Signatur‘

• ‚Patch‘ mit neuer Datei und Unterschrift der alten Datei erstellen:

  1. die Signatur der alten Datei laden, ist die beste eine Hash-Tabelle, mit den schwachen Prüfsummen als Schlüssel, die starken Prüfsummen und Blockposition sind die Werte.
     • Lesen Sie den ersten Block der neuen Datei
     • die schwache Prüfsumme der geladenen Block berechnen
     • überprüfen Sie die Hash-Tabelle zu sehen, ob das schwache Prüfsumme ist.
     • wenn gefunden wird, berechnen die starken Prüfsumme und Vergleichen mit dem in dem Hash gefunden
     • wenn beide Prüfsummen übereinstimmen, Marke als "bekam es mit der Blockreferenz in der Hash, eine ganze Blockvorantreiben und gehen Sie zurück zu Schritt 3
     • wenn die starken Prüfsumme nicht übereinstimmen, oder wenn die schwache Prüfsumme ist nicht in der Hash, ‚Roll‘ das schwache Prüfsumme, das heißt, ‚Hinzufügen‘ das nächste Byte nach dem Block, und ‚subtrahiert‘ das erste Byte aus dem Schwanz.
     • fügen Sie das Byte ‚abgezogen‘ aus dem Schwanz in die Liste der ‚neuen‘ Bytes im Patch
     • gehen zurück zu Schritt 4

• anwenden Patch alte Datei

  1. die ‚Patch‘ die Liste der ‚neuen‘ Bytes ist, die abgesetzt, während die Prüfsumme rollen, und die Liste der 'bekam es blockiert, dass Spiel auf der alten Datei.

Dies ist eine Technik für die verwendete inkrementalen Laden auf einem Data - Warehouse. In der Situation , wo man nicht die Möglichkeit haben, geänderten Daten innerhalb eines Quellsystems zu identifizieren, können Sie einen Schnappschuss der Daten herausnehmen und vergleichen ihn mit dem letzten Snapshot die Unterschiede zu identifizieren. Diese Technik wird auch eine Erwähnung in Ralph Kimball Buch zu diesem Thema und wird verwendet in einer Anwendung , die ich bei der Gestaltung beteiligt war.

Sie benötigen einen Hashing - Algorithmus mit einem sehr breiten Schlüssel wie dieser Ansatz ist anfällig Geburtstag Angriffe . MD5 oder einer der SHA - Familie wäre gut. Es kann auch nicht erkennen , Deletionen ohne Post-Prozess, der die Differenz geht durch für fehlende natürlichen Schlüssel suchen. Diese Berechnung muss tatsächlich Kenntnis von der Tabellenstruktur sein.

Ein Problem mit Ihrem Schema ist, dass alle wiederholten Zeilen würde eine wiederholte Hash haben; Sie konnte nie erkennen, wenn einer dieser Zeilen hinzugefügt oder gelöscht wurde

Sehr guter Punkt, aber kein Problem. Eine wiederholte Zeile ist ein Duplikat und alle Duplikate in der nächsten Stufe der Verarbeitung gelöscht. Also ja, Sie haben Recht, aber es ist kein Problem.

„Diff“ Link führt mir eine Seite mit einer Beschreibung dessen, was ich davon ausgehen, ist eine Anwendung? Es gibt keinen Download-Link gibt es keinen Code in jeder Sprache ist ... Was ich hier fehlt?

Einige von Ihnen haben über Byte-Ebene Granularität gesprochen. Dies ist nicht erforderlich. nur Line-Level-Granularität ist erforderlich, da, wenn etwas auf der Linie geändert wurde, die gesamte Zeile (Datensatz) muss erneut verarbeitet werden becasue jede Änderung innerhalb der Linie, die die ganze Linie auswirkt.

So sind wir Linien von ca. 1000 Zeichen zu vergleichen (nicht binär), in zwei Dateien (heutige Snapshot und yesterdays Snapshot), die jeweils ca. 1 m Linien sind.

So mit einem sicheren Hash wie SHA256 (MD5 hat Kollisionen und ist langsam im Vergleich) Ich kann über 30 MB / s auf meinem Laptop HO verarbeiten. Der Server wird natürlich viel schneller durch kauen.

Also, wenn die Datei arond 1 GB ist, dann alle machen HASEn dauert ca. 33sec und Fenster Seitenspeicher dauert etwa 30 Sekunden mit 1 GB-Datei zu lesen. nicht schrecklich

Jetzt haben wir zwei Arrays von Hashes, die die Zeilen in jeder Datei. Wenn wir sie sortieren, können wir nun eine binäre Suche verwenden, so dass wir iterieren unseren Weg durch die neuen Dateien hashs für eine Übereinstimmung in den alten Dateien hashs suchen. Wenn wir es nicht finden, wird diese Zeile auf die Änderungen Datei hinzugefügt.

Beachten Sie, dass das Buch von Linien (Legacy-Datenbank) in jeder Hinsicht unbekannt ist. Es gibt keine Garantie für die Bestellung von Linien, die Lage der Änderungen, die Art der Änderungen.

Die Vorschläge des Lesens foreward Seite für Seite ist gut, geht aber davon aus, dass die beiden Dateien im smae um bis, bis die erste Veränderung. Dies kann nicht übernommen werden. Die Linien (Zeilen) können in beliebiger Reihenfolge angegeben werden. Auch die Wahl eines beliebigen Block verletze die Granularität einer Zeile. Für die Zwecke dieser Aufgabe sind, Linien unveränderlich.

Von diesem hervorragenden Link auf invrementa Laden: Dateivergleich Aufnahme: Diese Methode wird auch als Snapshot-Differenzverfahren bekannt. Diese Methode funktioniert, indem vor zu halten und nach Bildern von Dateien, die von Bedeutung für das Data Warehouse sind. Aufzeichnungen verglichen werden Änderungen zu finden, und Satzschlüssel verglichen werden Einfügungen und Löschungen zu finden. Diese Technik ist am besten geeignet für den Fall von Legacy-Systemen aufgrund der Tatsache, die normalerweise nicht existieren löst und Transaktionsprotokolle sind entweder nicht vorhanden oder in einem proprietären Format. Da die meisten Legacy-Datenbanken für Dumping-Daten in Dateien einen Mechanismus haben, schafft diese Technik regelmäßig Snapshots und vergleicht dann die Ergebnisse Änderungssätze zu erzeugen. Gewiss, alle Probleme der statischen Erfassung sind hier vorhanden. Zusätzliche Komplexität wird durch die Herausforderung des Vergleichens ganze Reihen von Informationen und durch Schlüsselidentifikation und Matching eingeführt. Diese Technik ist komplex in der Natur und in der Regel nicht wünschenswert, aber in einigen Fällen können die einzige Lösung sein.

Dies ist vor allem relevant hier: Wie wir in den Bereich der Terabyte-Datenlager gehen, die Fähigkeit, die Data Warehouse von Grund auf einer nächtlichen Basis gehen den Weg der Dinosaurier neu zu erstellen. Der logische und effizienter Ansatz das Data Warehouse der Aktualisierung beinhaltet eine Form von inkrementeller Update-Strategie.

Also ich denke, ich auf dem richtigen Weg bin dann? Ein btree Index würde keinen Vorteil leisten?