Hallo zusammen, wir haben ein Prüfsystem das Bilddateien generiert. Zur Rückvervolgbarkeit und Diagnose des Systems werden die Bilder gespeichert. Pro Tag fallen so ca 40000 Bilder a 200kb an. Im Moment werden die Files in einer Ordnerstruktur Jahr/Monat/Tag abgelegt, das handling der Files ist aber aufgrund der großen Menge problematisch. (Beim kopieren von Bildern aus 2 Tagen von einem Netzlaufwerk auf eine USB Platte wird 8h als geschätzte Zeit angezeigt) Auf die einzelnen Bilder sollte ohne größeren Aufwand zugegriffen werden können daher halte ich ein archivieren in zb. Zip Dateien für keine gute Alternative. Am liebsten wäre mir eine Art Datenbank auf die ich dann mit einem selbst erstellten Tool zugreifen und Bilder hinzufügen und suchen kann. Vom abspeichern der Bilder als BLOB in einer SQL Datenbank wird einem aber eigentlich bei so großen Mengen eher abgeraten. Kennt jemand eine Möglichkeit wie man so etwas am besten angeht?
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.
Tek schrieb: > Vom abspeichern der Bilder als BLOB in einer SQL Datenbank wird einem > aber eigentlich bei so großen Mengen eher abgeraten. Vom Abspeichern solch großer Datenmengen ist generell abzuraten, egal wohin. Nee im Ernst, die Datenbank ist sicher noch die bessere Variante. Bei gleicher Gesamtdatenmenge dauert das Bewegen vieler kleiner Dateien durch den Overhead des Öffnens/Schließens um Größenordnungen länger als bei einer großen Datei. 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.
:
Bearbeitet durch User
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.
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.
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.
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ß.
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.
Fileserver+ Dateinamen richtig wählen/Ondemand umbeschriften.. Eine Parallele Datenbank mit Timestamp und eindeutigem Stempel erstellen.. geht ja einfach da man nach Dateien Erstelldatum seit letztem Sync sucht. Ich hab mal ähnliches mit CSV und einem kleinen Tool gemacht.. Die Files wurden wild in einem Ordner abgelegt, nach jedem Auftrag hat man ein einfaches Batch/Java Programm geöffnet das alle Daten wie Auftragsnumme,Produktnummer abgefragt hat und das ganze dann passend verteilt, umbenannt und einsortierte.
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
Peter II schrieb: > 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? Es gibt mittlerweile Backup-Software wie VEEAM, die sogar in der Lage ist, einzelne Nachrichten von Exchange-Postfächern aus dem Backup wiederherzustellen. Sollte also nicht allzu schwer lösbar sein. 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.
Possetitjel schrieb: > Es stört aber eher die Anzahl, nicht das Datenvolumen. Mein Reden: Icke ®. schrieb: > Bei > gleicher Gesamtdatenmenge dauert das Bewegen vieler kleiner Dateien > durch den Overhead des Öffnens/Schließens um Größenordnungen länger als > bei einer großen Datei.
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.
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.
Tek schrieb: > Mit Archiven bräuchte man dann > irgend ein Tool das die dann aus den entsprechenden Dateien extrahiert. Egal welche Lösung du bevorzugst, die Software muß in jedem Falle angepaßt werden. Ohne Anpassung denkbar wäre allenfalls ein Lösung, die bspw. realtime die Archive auf Hardlinks mountet, sodaß die Software scheinbar auf eine Ordnerstruktur zugreift.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.