Hunderttausende Dateinamen mit Pfaden effizient in Datenbank speichern

[himitsu]

Einige Dateisysteme bieten auch die Möglichkeit Dateien/Verzeichnisse via ID anzusprechen.
Man braucht da also keinen Dateinamen.

Oder man sieht jeden vollständigen Dateipfad als einzelnen String an, welcher in einer Pfadtabelle gespeichert wird.
> nur eine ID auflösen (hilft nur, bei wenigen Verzeichnissen und vielen Dateien)
Und wer unbedingt will, kann noch weiter sparen, indem er nur einzelne Verzeichnisnamen und die Rootverzeichnisse speichert und diese dann als Baum untereinander verlinkt.
> hier muß man halt erst wieder die Pfade rekursiv zusammensetzen

[Sir Rufo]

Ein vergleichbares Konzept wird bei der Backup-Software Retrospect verwendet. Bis zur Version 7.x wurde vor dem Backup von allen Dateien Hash-Werte gebildet und anhand derer wurde überprüft, ob sich die Datei geändert hatte. Als Option können auch gleiche Dateien (gleiche Hash-Werte/Datei-Größe) nur einmal im Backup gespeichert werden.

Die Pfade werden logischerweise auch gespeichert (ich vermute mal auch als Tree, obwohl die Katalog-Dateien auch sehr groß werden).

Ab der Version 8.x läuft ein Dienst mit, der bei Dateiänderungen direkt den Hash-Wert neu berechnet um die Zeit bis zum wirklichen Anlaufen des Backups zu verkürzen.

[Benmik]

Ich bitte um Entschuldigung, ich dachte, es würde reichen, mich auf ein Detailproblem zu konzentrieren. Wie aus diesem Beitrag hervorgeht, geht es um ein selbst gestricktes Backup-Programm, insofern hat Sir Rufo ins Schwarze getroffen. Ich hätte Perlsau einige Mühe ersparen können. Es geht also natürlich darum, bereits gesicherte Dateien in einer DB zu speichern und bei neuen Dateien nachzuschauen, ob man sich die erneute Erstellung einer Prüfsumme sparen kann (in vielen Fällen über 99%). Trotzdem - der Hinweis von Perlsau, ein MD4 von Pfad und Dateinamen zu erstellen, ist schonmal gut!

[Perlsau]

Wenn es auch um die Überprüfung von Dateiänderungen geht (Dateiname bleibt gleich, Änderungsdatum und ggf. Größe jedoch unterschiedlich), mußt du zur Berechnung eines eindeutigen Hashwerts natürlich auch Größe und Datum mit einbeziehen.

[Benmik]

Natürlich. Von jeder Datei wird aber ohnehin ein MD4 erstellt. In der DB werden Dateiname, MD4, Größe, Erstellungs- und letztes Änderungsdatum vermerkt. Wenn nun Dateiname, Pfad, Größe, Erstellungs- und letztes Änderungsdatum übereinstimmen, dann spare ich mir die erneute MD4-Berechnung und gehe von Identität aus. Da bei sehr großem Dateibestand der Prozentsatz der geänderten Dateien sehr klein ist, kann man sich so meist >99% der Arbeit sparen.

Retrospect ist natürlich toll, ich weiß aber nicht, ob ich so einen Dienst mitlaufen haben möchte. Insbesondere nicht, wenn ich Videobearbeitung mache.

Ich glaube, ich verfolge jetzt erstmal den Ansatz, die Verzeichnisse mit ID zu versehen und für den Gesamtnamen ein MD4 zu speichern, was mich einheitlich 32 Byte kosten würde.
Vielen Dank für eure Anregungen, und wenn jemand noch eine zündende Idee hat, immer her damit!

[Sir Rufo]

Zitat von Benmik:

Retrospect ist natürlich toll, ich weiß aber nicht, ob ich so einen Dienst mitlaufen haben möchte. Insbesondere nicht, wenn ich Videobearbeitung mache.

Und warum sollte das stören?

Klar kann man das so implementieren, dass es fürchterlich stört, aber auch so, dass es eben nicht störend wirkt.
Wenn die CPU sich langweilt, dann alles berechnen, was da ansteht, ansonsten vornehm zurückhalten und nicht bei jeder Änderung sofort die Berechnung anwerfen.

[Benmik]

Ist natürlich richtig, wenn die Jungs das so geschickt machen. Womit auch Persaus Frage beantwortet wäre, was ein Profi ist Mir jedenfalls stehen solche Möglichkeiten wie die Implementierung eines solchen Dienstes nicht zur Verfügung. Was auch für die blockweise Datensicherung gilt.