viele (bild-)dateien - wie speichern ?!

[AxlF]

Hallo,

ich stehe vor folgendem Problem:

Ich habe eine Datenbank mit rund 90.000 Datensätzen. Zu jedem dieser Datensätze sollen mindestens 4 Bilder gespeichert werden.

Welche Verezichnisstruktur ist zu wählen, und welche ist auch noch performant ?!?
Oder ist das einfach egal?

Ich habe mir gedacht einfach zu jedem Datensatz die ID als Verzeichnis, darin dann die Bilder.

/bilder/134/bild1.jpg
/bilder/134/bild2.jpg
/bilder/134/bild3.jpg
/bilder/134/bild4.jpg
/bilder/135/bild1.jpg
/bilder/135/bild2.jpg
/bilder/135/bild3.jpg
/bilder/135/bild4.jpg

Macht das dem System was aus (performance) wenn in dem Verzeichnis "/bilder" um die 90.000 weitere Verzeichnisse gespeichert sind?

Hat soetwas schonmal jemand gemacht?


P.S. Ist ein Debian mit ext3 Dateisystem...

 

[2nd]

Die Verzeichnisstruktur auf der Platte spielt m. E. nur eine kleine Rolle. Viel mehr steht im Vordergrund, wie viele parallele Requests auf die Bilder stattfinden.

Wenn das Ganze serverseitig performant umgesetzt werden soll, könnte man überlegen, einen 2. Server aufzusetzen, der via lighttpd (anstelle des Apachen) ausschliesslich die Bilder ausliefert. Solange keine serverseitigen Skriptsprachen im Spiel sind, ist der lighttpd schneller als der Apache.

Und zur Benennung: Kann man die Relationen nicht ausschliesslich über die DB abbilden? Dann könnte man nämlich alle Bilder mit einem eindeutigen Namen (md5 Hash von ID + Bildname z. B.) in einen Ordner schmeissen. Bei der Menge halte ich das für die schlauere Variante. Es sei denn, die Bildnamen transportieren benötigte Semantik. Oder ihr sortiert auf der Festplatte per Hand

 

[AxlF]

hm...

So genau kann ich das nicht abschätzen...
Die Seite hat im Moment rund 1000 Zugriffe am Tag. Das geht eigentlich noch. Also dürften sich die parallelen requests eher in Grenzen halten...

Irgendwie stellen sich mir die Nackenhaare auf wenn ich daran denke um die 400.000 Bilder in einem Ordner zu haben ?!?!
Also der Dateiname wäre eigentlich egal, transportiert keine Semantik.

Was für Vorteile würde das bringen, alles in ein Verzeichnis zu stecken?

 

[moses_78]

Naja. Wenn du alles in einen Ordner steckst,
brauchst du vielleicht riesige Dateinamen, weil
sich sonst keine individuellen Namen mehr fin-
den lassen.

Wenns nur kleine Dateien sind...könntest du sie
als Blobs in die Datenbank stecken. Nicht schön,
aber du könntest den Bildern direkt zusätzliche
Attribute/Metainformationen geben.

 

[AxlF]

Naja. Wenn du alles in einen Ordner steckst,
brauchst du vielleicht riesige Dateinamen, weil
sich sonst keine individuellen Namen mehr fin-
den lassen.

Also bei 400.000 Dateien sehe ich da kein Problem noch...

Wenns nur kleine Dateien sind...könntest du sie
als Blobs in die Datenbank stecken. Nicht schön,
aber du könntest den Bildern direkt zusätzliche
Attribute/Metainformationen geben.

Die Relation ist sowieso in der Datenbank abgebildet. Von daher sind Meta-Informationen sowieso da bzw. speicherbar...
Bilder in einer Datenbank speichern ist aus Performance-Gründen her ein absolutes "No Go"...

 

[wegus]

Macht das dem System was aus (performance) wenn in dem Verzeichnis "/bilder" um die 90.000 weitere Verzeichnisse gespeichert sind?

Nein! Das macht einem UNIX-Dateisystem nichts aus, sofern noch inodes frei sind! Ich selbst habe nach einem ähnlichen Prinzip hier einen Bilderserver laufen der zu derzeit etwa 40.000 Produkten jeweils 6-8 Bilder und deren Thumbnails parat hält (sowie einige webtaugliche davon Größen dazu).

Auf die Bilder greife ich via Apaches httpd zu, ein Upload erfolgt über ein spezielles SMB-Share das turnusmäßig geleert wird. Die Bilder werden im Original ( also mit vollen Pixeln) ebenso aufbewahrt wie für spezielle Zwecke per imagemagic heruntergerechnet.
Da sich ein solcher Bilderserver nur mit hohem zeitlichen Aufwand sichern läßt, habe ich den auch noch gespiegelt, so daß ein Fallback-Server jederzeit einsteigen kann.

Läuft mit sehr geringen Ausfällen sehr sehr stabil und performant!

Irgendwie stellen sich mir die Nackenhaare auf wenn ich daran denke um die 400.000 Bilder in einem Ordner zu haben ?!?!

Das gibt auch irgendwann Probleme! Schon ein ls 10* wird dann irgendwann wegen Overflow nicht mehr gehen. Der tar Befehl steigt noch früher aus. Auch wenn UNIX-Dateisysteme wenig Probleme mit so einer großen Dateizahl haben, die Datei-Tools haben sie schon viel früher! Selbst ein rm einiger weniger Bilder kann dann scheitern!

 

[AxlF]

und wie sieht deine Ordnerstruktur aus?

Immerhin wären das auch noch 90.000 Ordner wenn ich nur nach ID trenne.

Man könnte das aufssplitten in 9 x 10.000 . Dann wäre die Anzahl in einem Verzeichnis wesentlich geringer...

 

[wegus]

ich habe in der Tat 40.000 Ordner! Ich habe schon einige Versuche durch ( 1000er Schritte 10.000er Schritte...). Hat alles Vor- und Nachteile. Am handlichsten und schnellsten für den Direktzugriff ist IMHO die jetzige Lösung. 1000er Schritte erforden eine hohe Verwaltungsdichte bei wenig Übersicht ( sind dann ja auch schon (6..8)*2*1000 Bilder je Verzeichnis), bei 10000er Schritte steigt ggf. schon ein tar aus. Die 1er-Schritte machen "nur" das Verzeichnis mit den n-tausend Unterverzeichnissen zu einem Problem. Auf das greift man aber eher selten bis nie zu, sondern über die ProduktNr. meist auf den Inhalt eine ebene tiefer, was ja dann dank (6..8)*2 Bildern sehr sehr zügig geht! Die Imagemagik aufbereiteten Bilder habe ich in einem separaten Verzeichnis wo sie zum Upload fürs Web bereitliegen.

Das System wird täglich von etwa 10-15 Usern mit Daten gefüllt, im Rahmen eines lokalen ERP von 50Usern verwendet und es erfolgt bis zu 8x täglich ein Upload an unterschiedliche Quellen. Der Load des Systems liegt trotzdem unter geschmeidigen 0.2 bis 0.3