Sven (κ): Minimale Zugriffszeit bei bis zu 4.294.967.296 Dateien?

Beitrag lesen

Hallo Eddie,

ich bin hier gerade dabei, ganz eifrig dynamisch Dateien zu erzeugen. Jedesmal, wenn der User was tut, wird prinzipiell eine neue erzeugt: ihre Eigenschaften kommen in die DB, und die Grafik selbst wird mittels /{Primary_Key}.gif lokal gespeichert.
Natürlich werden es nicht 4.294.967.296 Dateien (der Wertebereich von INT), aber ein paar 100.000 koennten schon zusammen kommen - und wer weiß, wenn's erfolgreich wird, vielleicht ein paar Millionen ;-) Man soll ja positiv denken!!!

das klingt zwar toll, aber hast du dir schon mal Gedanken gemacht, wie das ganze skaliert, sprich wie perfomant das wird? Wie wär's z.B. als Alternative, die Grafiken selbst in der Datenbank (BLOB) zu speichern? Dann müsstest du dir nämlich nun im Folgenden über die Dateisystemlimitationen keine Gedanken machen, außerdem wäre die Zugriffsgeschwindigkeit vermutlich höher, weil man in einer großen DB-Datei schneller was findet als in zig kleinen, außerdem wird die gecachet (beim Lesen), wohingegen das bei einigen millionen schon bald nicht mehr der Fall sein wird.

Jetzt weiss ich aber nicht genug über Dateisysteme (es wird auf einem Linux-System laufen), um die richtige Breite und Tiefe zu kennen. Spielt das ueberhaupt eine Rolle? Und wenn ja, könnt ihr mir was raten?

Es spielt, sofern moderne FS genutzt werden, so gut wie keine Rolle, weil sie fast alle gigantisch große Limitationen haben. Ein paar Beispiele:

http://de.wikipedia.org/wiki/ReiserFS
  "maximale Dateien pro Verzeichnis: 518.701.895"

oder noch besser:

http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

Ach ist ja auch egal. Auf jeden Fall solltest du auch mal an die Speicherkapazität denken: Selbst wenn jedes gif nur 1Byte groß sein würde, hättest du da schon 4GB an Daten... wo sollen die denn alle hin?

Grüße,

Sven