Speichern einer großen Anzahl von Dateien

Hi TeK,

wie man so etwas am besten angeht, hängt noch von einer Reihe weiterer 
Gegebenheiten ab.
Erstmal zum Bildformat: Ich vermute mal .jpg (.jpeg), d.h. nicht 
wirklich weiter komprimierbar. Das bedeutet, ein Zusammenfassen in 
zip-Dateien hat eher organisatorischen Charakter - aber genau dafür 
würde ich das in Erwägung ziehen.
Kann das Aufkommen irgendwie reduziert oder aggregiert werden? D.h. gibt 
es feststellbar gleiche Bilder, bzw. welche, die bekanntermaßen als 
nicht mehr relevant markierbar sind? Reicht es, die Unterschiede 
zwischen den Bildern zu speichern (das lohnt sich nur, wenn es nur 
geringe Unterschiede gibt, und jpeg ist dann auch ein eher unglückliches 
Speicherformat)? Oder reicht es sogar, wenn z.B. per OpenCV Aussagen aus 
den Bilder extrahiert und nur diese (gut komprimierbar) gespeichert 
werden? Ist gar nur eine Prüfsumme notwendig (auch hier ist jpeg eher im 
Weg)?

40000 Dateien in einem Ordner klingt anstrengend, je nach Zugriff. Wie 
soll auf die Dateien zugegriffen werden (nach welchen Kriterien)? Wenn 
z.B. die Stunde bekannt ist/sein soll, und die Dateien einigermaßen 
gleichverteilt über den Tag anfallen, dann bringt ein Einsortieren in 
Unterordner nach Stunden schon einiges, evtl. auch noch nach Minuten, 
z.B. ein Ordner "0941" für Bilder, die (tada) um 09:41 Uhr erstellt 
wurden. Oder eben (siehe oben) eine Zip-Datei pro Minute.

Und wenn die Daten in der Menge wirklich notwendig sind, dann solltest 
Du imho die Infrastruktur dafür auch aufbohren. 8h für 8GB (40k*200kb) 
klingt nicht gerade nach USB3...
Zum Kopieren: Am besten immer per Kommandozeile (und unter Windows am 
besten per XCopy/Robocopy). Die Vorschau auf Bilder deaktivieren, 
Ansicht auf Liste, sonst kann dies einem USB-Stick einiges abverlangen.

Gruß, jois3

Ich würde die Bilder je Tag in ein TAR Archiv legen. (z.b. durch eine 
Jobs Nachts). Dazu würde ich in Datenbank (oder Textdatei) mir einen 
Index anlegen wo steht an welchen Offset welches Image im Tar beginnt 
und wie groß das Image ist - dann hat man auch einen sehr schnellen 
zugriff auf die Images.

Icke ®. schrieb:
> Also klarer Rat zur Datenbank,

Dann sollte man aber vieleicht mal nach NOSQL Datenbanken schauen.
Key Value oder Dokumentenzentrierten Datenbanken dürften besser auf das 
Problem passen und bessere Performance und skalierbarkeit bieten.

Gibt es vieleicht spezielle Bilddatenbanken für sowas?

Icke ®. schrieb:
> . Und bei euren enormen Datenmengen wird auch die
> Sicherung/Rücksicherung äußerst zeitaufwendig und in absehbarer Zeit
> unbeherrschbar. Also klarer Rat zur Datenbank, ggfs. Aufteilen in
> mehrere Datenbanken.

auf keinen Fall würde ich sagen, klar eine große Datenbank klingt 
einfacher. Hat aber den großen Nachteil das man nicht einen kleinen Teil 
der Daten wiederherstellen kann. Wenn man jeden tag in ein Tar packt 
kann man tageweise Sichern und Widerherstellen. Für jeden Tag eine 
Datenbank ist unhandlich.

Auch das Sichern ist nicht wirklich einfach, weil man schlecht von der 
Datenbank Differenzen ermitteln kann im schlimmsten fall wird bei sicher 
jeden Tag die Datenbank komplett kopiert.

Wie haben auch über 50.000.000 Dateien auf einen System liegen. Nur 
kostet das dann etwas mehr als ein einfaches NAS.

Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000 Dateien pro Tag 
sind nicht viel.

Du solltest genauer erklären was ihr genau machen wollt. Wenn dir nur 
das kopieren auf eine USB-Festplatte zu lange dauert, musst du 
herausfinden warum es so lange dauert. 16Gb in 40000 Dateien sollte 
keine 8 Stunden dauern.

RIAK KV kann sowas z.B.

Die Dateimanager von Windows und Ubuntu Linux tun sich mit vielen 
Dateien sehr schwer. Sie sind langsam und neigen bei so viele Dateien 
dazu, sich spontan aufzuhängen oder auch mal Dateien auszulassen.

Der Tip mit der Kommandozeile war schon goldrichtig - bei beiden 
Betriebsystemen.

Eine Datenbank bringt Dir den Vorteil, dass sie die Dateien 
(=Datensätze) indiziert, so dass du schneller suchen kannst. Aber wonach 
willst du suchen? Vermutlich nur nach Zeitstempel, richtig? Das kannst 
du in deinem gruppierten Dateisystem genau so gut.

Bei Kopieren von Massendaten wird die Datenbank hingegen keinen 
wesentlichen Vorteil haben. Im Gegenteil, da der Kopiervorgang auch das 
Aktualisieren des Index mit sich bringt, kostet es sogar vielleicht 
sogar noch extra Zeit.

Letztendlich ist das Dateisystem selbst schon eine Datenbank - nur mit 
fest vorgegebener Struktur des Index, nämlich dem Inhaltsverzeichnis.

Tek schrieb:
> Beim kopieren von Bildern aus 2 Tagen von einem
> Netzlaufwerk auf eine USB Platte wird 8h als geschätzte Zeit angezeigt

Muss das ein Netzlaufwerk sein? Ich würde die USB-Platte an die Maschine 
anschliessen, die die Bilder speichert.

Georg

Icke ®. schrieb:
> Peter II schrieb:
>> Auch das Sichern ist nicht wirklich einfach, weil man schlecht von der
>> Datenbank Differenzen ermitteln kann im schlimmsten fall wird bei sicher
>> jeden Tag die Datenbank komplett kopiert.
>
> Dafür wurden transaction logs erfunden.

und dann willst du beim restore erst mal das Backup einspielen und dann 
noch 356 diffs dazu?

Und was ist wenn du 1 Datei aus dem Backup brauchst?

Icke ®. schrieb:

> mh schrieb:
>> Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000
>> Dateien pro Tag sind nicht viel.
>
> Doch, das ist schon eine ganze Menge, wenn man nicht
> gerade in einem Rechenzentrum sitzt und auf hochperformante
> SANs speichert, sondern mit Technik aus dem SoHo-Bereich
> klarkommen muß.

Es stört aber eher die Anzahl, nicht das Datenvolumen.

8GByte (=8'000 MByte) gehen in 5 Minuten (=300s) über den
USB.

Das letzte Buch, das ich eingescannt habe, hat 600 Seiten
zu je 40MByte. Die Nachbehandlung lässt sich mühelos auf
einem 10 Jahre alten PC machen.

Tek schrieb:

> Pro Tag fallen so ca 40000 Bilder a 200kb an.
>
> Kennt jemand eine Möglichkeit wie man so etwas
> am besten angeht?

Bilder viertelstundenweise als tar-Archive zusammenfassen.
Automatisiert natürlich.

Für einen Tag (=24h) gibt das 96 Dateien mit je 400
Bildern, also je tar-File ca. 80MByte.

Topmoderne graphische Filemanager (wie der Midnight
Commander:) können direkt mit tar-Archiven umgehen, d.h.
diese wie Verzeichnisse "öffnen". Der wahlfreie Zugriff
ist dadurch nicht eingeschränkt.

Icke ®. schrieb:
> Doch, das ist schon eine ganze Menge, wenn man nicht gerade in einem
> Rechenzentrum sitzt und auf hochperformante SANs speichert, sondern mit
> Technik aus dem SoHo-Bereich klarkommen muß.

Man "muß" nicht mit Technik  klarkommen, die für so einen Anwendungsfall 
nicht gedacht und auch nicht sonderlich geeignet ist. Sie ist ja 
deswegen so günstig, weil sie für sowas eben nicht gebaut wurde.


Ansonsten, Dateimanager haben mit sowas Probleme, weil und wenn sie von 
Anfängern programmiert wurden (egal ob unter Linux oder bei MS). Da wird 
dann mit 50 Dateien getestet "ja geht", und das war's. Manchmal waren 
die Deppen auch bei der Entwicklung des Dateisystems, da kann der 
Dateimanager dann auch nichts mehr retten.

Siehe auch hier, da sind Shlemiels drin:
http://www.joelonsoftware.com/articles/fog0000000319.html

Alternativ auch Sortieralgorithmen, die bei 50 noch gehen, bei 40.000 
nicht mehr. Bubblesort etwa. Wer sowas in einen Dateimanager verbaut, 
gehört geschlagen.

Icke ®. schrieb:
> mh schrieb:
>> Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000 Dateien pro Tag
>> sind nicht viel.
>
> Doch, das ist schon eine ganze Menge, wenn man nicht gerade in einem
> Rechenzentrum sitzt und auf hochperformante SANs speichert, sondern mit
> Technik aus dem SoHo-Bereich klarkommen muß.

Solange man nicht versucht über eine Netzwerkverbindung auf jede Datei 
einzeln zuzugreifen, sollte das kein Problem sein.

Nop schrieb:

> Man "muß" nicht mit Technik  klarkommen, die für so
> einen Anwendungsfall nicht gedacht und auch nicht
> sonderlich geeignet ist.

Ach so.

Niemand hat je erfolgreich einen UseNet-Server auf
PCs betrieben. Soso.

> Ansonsten, Dateimanager haben mit sowas Probleme, weil
> und wenn sie von Anfängern programmiert wurden (egal ob
> unter Linux oder bei MS).

Nein -- weil sie von Anfängern für Zwecke eingesetzt werden,
für die sie völlig ungeeignet sind.

Wozu - zum Henker! - braucht man zur sinnvollen, d.h.
automatisierten Behandlung von Dateien eine DATEIMANAGER ?

Du stellst wohl auch extra eine Hilfskraft ein, die jedes
Bild mit der Maus in den passenden Unterordner zieht?

> Manchmal waren die Deppen auch bei der Entwicklung des
> Dateisystems,

Ja... zum Beispiel die grünen Bubis, die FAT entwickelt
haben.

SCNR

Icke ®. schrieb:
> Nur mal zum Vergleich, die Dateianzahl des TE wächst pro Jahr um einen
> zweistelligen Millionenbetrag. Bei dateibasierter Speicherung würde ein
> kompletter Restore Tage dauern, wenn keine sauteure Storagetechnik
> vorhanden ist.

nein, wie schon oben geschrieben, einfach jeden Tag in ein TAR packen 
und gut ist. Dann kann man mit Hilfe einer Index Datei sogar sofort auf 
den Inhalt zugreifen.

Backup und Restore ist dann keim Thema mehr, weil man es nur noch mit 
365 Dateien a 8GB zu tun hat.

Icke ®. schrieb:

> mh schrieb:
>> Solange man nicht versucht über eine Netzwerkverbindung
>> auf jede Datei einzeln zuzugreifen, sollte das kein
>> Problem sein.
>
> Denkste, das ist sehr wohl auch dann problematisch, wenn
> die Dateien auf lokalen Laufwerken bewegt werden. Ich
> rede aus Erfahrung.

Also besteht die Lösung darin, die Dateien blockweise
zusammenzufassen. Rechenbeispiel steht weiter oben.

Ich verstehe die Diskussion nicht. (Muss ich Gott sei
Dank auch nicht...)

Possetitjel schrieb:

> Niemand hat je erfolgreich einen UseNet-Server auf
> PCs betrieben. Soso.

Das ging ganz am Anfang, als das nicht viel mehr als Mailboxen waren. 
Gut, heute würde es wieder gehen, so wie das Usenet geworden ist.

> Nein -- weil sie von Anfängern für Zwecke eingesetzt werden,
> für die sie völlig ungeeignet sind.

Es gibt keinen Grund, wieso ein Dateimanager bei 40.000 Dateien versagt, 
wenn z.B. ls funktioniert. Außer schlampiger Programmierung mit mies 
skalierenden Algorithmen, und die sollte man auch in Dateimanagern nicht 
verwenden.

Sind übrigens dieselben Trottel, die auch sowas wie Testtools machen. 
Die funktionieren gut mit 50 Signalen. Zeichnet man damit 5000 auf, 
dauert es Stunden, bis sich alleine die Oberfläche mal aufbaut. Und dann 
stürzt sie ab.

> Wozu - zum Henker! - braucht man zur sinnvollen, d.h.
> automatisierten Behandlung von Dateien eine DATEIMANAGER ?

Dafür nicht. Um ins Verzeichnis reinzusehen dagegen schon.

> Ja... zum Beispiel die grünen Bubis, die FAT entwickelt
> haben.

Nö, FAT war schon nicht so schlecht - für Disketten. Idiotisch wurde es 
aber, als man damit angefangen hat, auf Festplatten loszugehen. 
Vermutlich veranlaßt durch inkompetente Manager, die "zack zack mal eben 
schnell los los mir doch alles egal" gedacht haben.

Danke für die vielen Antworten

jois3 schrieb:
> Erstmal zum Bildformat: Ich vermute mal .jpg (.jpeg), d.h. nicht
> wirklich weiter komprimierbar. Das bedeutet, ein Zusammenfassen in
> zip-Dateien hat eher organisatorischen Charakter - aber genau dafür
> würde ich das in Erwägung ziehen.

Die Bilder kommen aus einer Bildverarbeitung und sind unkompremiert nur 
so kann nachträglich mit anderen Parametern nochmal ausgewertet werden. 
Platztechnisch könnte da also auch noch was rausgeholt werden.

Übergeordnet gibt es eine Datenbank die mittels einer ID mit den Files 
verknüpft ist.

Der Zugriff auf die Bilder ist unterschiedlich:
Für nachträgliche Auswertungen werden z.B. alle Bilder von einer Woche 
benötigt da wären Tagesarchive unproblematisch.

Es kann aber auch sein das man mal eine Liste mit 100 Bildern verteilt 
über die letzten vier Wochen benötigt. Mit Archiven bräuchte man dann 
irgend ein Tool das die dann aus den entsprechenden Dateien extrahiert.

Tek schrieb:
> Es kann aber auch sein das man mal eine Liste mit 100 Bildern verteilt
> über die letzten vier Wochen benötigt. Mit Archiven bräuchte man dann
> irgend ein Tool das die dann aus den entsprechenden Dateien extrahiert.

was aber für jemand der Programmieren kann überhaupt kein Aufwand ist.

Peter II schrieb:
> was aber für jemand der Programmieren kann überhaupt kein Aufwand ist.

Nachdem ich mir die Antworten hier durchgelesen habe ist die Tagesarchiv 
variante auch mein Favorit.
Bisher war es halt recht bequem weil man auch zum "nur Office PC User" 
sagen konnte: Hier such dir Deine Dateien einfach aus der Ordnerstruktur 
raus.

Wie gesagt, RIAK KV angucken, oder minio.io wenn die IDs und Metadaten 
eh in einer separaten Datenbank liegen.

ergo70 schrieb:
> Wie gesagt, RIAK KV angucken, oder minio.io wenn die IDs und Metadaten
> eh in einer separaten Datenbank liegen.

Schau ich mir mal an, danke!

Nop schrieb:

> Es gibt keinen Grund, wieso ein Dateimanager bei 40.000
> Dateien versagt, wenn z.B. ls funktioniert. Außer
> schlampiger Programmierung mit mies skalierenden
> Algorithmen, und die sollte man auch in Dateimanagern
> nicht verwenden.

Ich glaube, wir brauchen nicht weiter zu streiten.
In der Kritik an stümperhafter, schlecht skalierender
Software sind wir ja einer Meinung.

Mein Punkt war ein ganz anderer: Hier wurde die
Behauptung in die Welt gesetzt, dass "der PC für
sowas eben nicht geeignet" ist -- und diese Aussage
ist schlicht und ergreifend Schwachsinn.

Wer so etwas schreibt, hat aus meiner Sicht entweder
einfach keine Ahnung, oder will provozieren - oder
beides.

Tek schrieb:
> Bisher war es halt recht bequem weil man auch zum "nur Office PC User"
> sagen konnte: Hier such dir Deine Dateien einfach aus der Ordnerstruktur
> raus.

Mit einem installierten 7-zip kannst du das weitgehend auch mit zip 
files.

Ich würde eher die oben vorgeschlagenen 15min oder maximal. 
Stundenarchive benutzen, sonst wirds unübersichtlich.