Minimale Zugriffszeit bei bis zu 4.294.967.296 Dateien?
Eddie
Minimale Zugriffszeit bei bis zu 4.294.967.296 Dateien?
Eddie
Hallo allerseits,
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!!!
Wir hatten das Thema hier auch schonmal (2006), nur hab ich das System jetzt endlich als (fruehen) Prototyp laufen und muss jetzt ein bisschen weiterdenken.
Also: die Dateien werden als Baum gespeichert, nur die Details fehlen noch! Die Datei 1234.gif könnte man bspw. so speichern:
- /0/0/0/.../1/2/3/4/1234.gif (also aufgefüllt auf die max. Stellenanzahl von INT,
mit gleicher Blatttiefe für alle Dateien) - /1/2/3/4/1234.gif (also verschiedene Blatt-Tiefe bei verschiedener Key-Länge)
- /12/34/1234.gif (also ein breiterer Baum)
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?
Danke für eure Hilfe,
Eddie
--
Old men and far travelers may lie with authority.
Old men and far travelers may lie with authority.
-
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
-
Moin!
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.
Das klingt zwar toll, aber hast DU dir schon mal Gedanken gemacht, wie das ganze skaliert, sprich wie performant das wird? Einfach nur Daten in eine Datenbank zu kippen bringt keinerlei Vorteile, wenn man nicht genau weiß, was man tut - und dein Vorschlag klingt genau so, als ob du nicht so genau wüßtest, was zu tun ist.
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?
Nur so zur Info: Festplatten erreichen derzeit Terabytekapazitäten. Es gibt kein Platzproblem. Zumindest keines, dass ungelöst bleiben muß.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hallo Sven,
Das klingt zwar toll, aber hast DU dir schon mal Gedanken gemacht, wie das ganze skaliert, sprich wie performant das wird? Einfach nur Daten in eine Datenbank zu kippen bringt keinerlei Vorteile, wenn man nicht genau weiß, was man tut - und dein Vorschlag klingt genau so, als ob du nicht so genau wüßtest, was zu tun ist.
stimmt genau. Ich wollte es als Alternative in Betracht ziehen. Was ist denn nun besser?
Nur so zur Info: Festplatten erreichen derzeit Terabytekapazitäten. Es gibt kein Platzproblem. Zumindest keines, dass ungelöst bleiben muß.
Meine Festplatte erreicht derzeit lediglich Vollzustand. Da gibt es ein Platzproblem. Eines, was ungelöst bleiben wird. Ich bin arm.
Ich geb zu, meine Antwort war wenig produktiv. Aber sie informierte über die Kapazitäten aktueller Linux-Dateisysteme.
Grüße,
sven
-
-
-
Tach,
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!!!
hmm, bei 4 Milliarden Gifs deckst du alle Bilder mit 256 Farben und einer Größe bis zu 4096px*4096px ab([latex]\sqrt{4294967296/256}=4096[/latex]). Da werden wohl eher sehr viele Duplikate auf dich zukommen, die du erkennen (z.B. durch Hash-Bildung) und dann passend behandeln solltest, damit sollte sich die Anzahl der Dateien erheblich vermindern.
mfg
Woodfighter-
Moin!
hmm, bei 4 Milliarden Gifs deckst du alle Bilder mit 256 Farben und einer Größe bis zu 4096px*4096px ab([latex]\sqrt{4294967296/256}=4096[/latex]).
Wenn alle 4096x4096 Pixel die gleiche Farbe haben, hättest du Recht. :)
Deine Rechnung ist aber leider falsch.
Nur mal im kleinen durchgespielt: Ein Bild mit 4x4 Pixeln hat 16 Pixel. Jedes Pixel kann eine beliebige aus 256 Farben annehmen. Macht: 256 Farben für den ersten Pixel * 256 Farben für den zweiten Pixel * 256... = 256^16 verschiedene Pixelfarbkombinationen. Also 3,4e+38 unterschiedliche Bilder. 2^32 ist nur 4e+48 - deine Annahme von Riesenbildern ist also deutlich daneben gegriffen. Bestenfalls dürfte
Wobei noch zu berücksichtigen wäre, dass jede der 256 Farben eine aus 16 Millionen sein kann.
Da werden wohl eher sehr viele Duplikate auf dich zukommen, die du erkennen (z.B. durch Hash-Bildung) und dann passend behandeln solltest, damit sollte sich die Anzahl der Dateien erheblich vermindern.
"Ich denke nicht, Tim!"
- Sven Rautenberg
--
"Love your nation - respect the others."-
Tach,
hmm, bei 4 Milliarden Gifs deckst du alle Bilder mit 256 Farben und einer Größe bis zu 4096px*4096px ab([latex]\sqrt{4294967296/256}=4096[/latex]).
Wenn alle 4096x4096 Pixel die gleiche Farbe haben, hättest du Recht. :)
Deine Rechnung ist aber leider falsch.
aua, inzwischen habe ich Kaffee getrunken und sehe das auch so.
mfg
Woodfighter
-
-