PHP Thumbnails in Datenbank speichern (Eure Meinung)

[syntec]

Ich würde gerne Ordner rekursiv nach Bildern durchsuchen lassen und daraus automatisiert die Vorschaubilder in einer mySQL Datenbank ablegen. Für anderen Websites habe ich bereits diverse Scripte die aber immer noch sehr viel manuelles Eingreifen nötig machen beim anlegen der Ordner, Rechte setzen usw. um die thumbs in einem anderen Ordner auf dem Server generieren zu können.

Ist das Speichern in der Datenbank für die Vorschaubilder ratsam - oder ist das alte Prinzip so dermaßen performanter, dass man die thumbs immer als file auf dem Server ablegen sollte.

Wie gesagt, mich reizt die zentrale Speicherung der Daten und der unproblematischerer Umgang mit den Bilddaten ohne den indirekten Weg über das Filesystem, Benutzerrechte und FTP.

Es geht hier auch um überschaubare Mengen an Bildern - es soll kein Flickr oder sonstwas werden..

Eure Meinungen?

 

[ice-breaker]

zur Speicherung von Dateien wurden Dateisysteme erfunden und keine Datenbanken!

 

[Black_Panter]

Bei ner überschaubaren Anzahl an Bildern, würde ich eher dazu tendieren die Bilder weiterhin klassisch abzulegen. Ich würde eher versuchen das Script so anzupassen, dass die benötigten Rechte immer automatisch gesetzt werden, bzw. sich die Konfiguration über eine eigene Seite erledigen lässt.

Ansonsten wäre es sicher ein interessanter Ansatz meiner Meinung nach.
Hast du schon testhalber was erstellt?

 

[achi7]

Speichern in der Datenbank hat durchaus Vorteile, nämlich dass man so Dinge wie Pixelgrößen des Thumbnails direkt in die Tabelle hineinnehmen kann (ohne mit Filenamen herumzufrickeln), aufräumen oder aktualisieren der Thumbnails ist auch viel einfacher und Rechteprobleme gibts keine. Dafür sind Backups mitunter unpraktisch.

Nachteil ist halt, dass man kleine Scripts schreiben muss, um sie einzufügen und auszulesen. Wichtig ist dabei, dass man die Cache-Header für den und vom Browser richtig generiert und interpretiert, damit die Thumbnails gecacht werden (statt jedesmal neu geladen) - das macht bei der filebasierten Lösung ja der Webserver automatisch für dich.

Meiner Erfahrung nach ist dann kein großer Performance-Unterschied zur Filesystem-Lösung spürbar. Allerdings habe ich auch keine richtig großen Systeme gebaut ;-)

 

[JP-M]

Wir haben mal als Projektarbeit im Informatik-Leistungskurs eine Bildergalerie für PhP und MySQL geschrieben, die Bilder wahlweise als Blobs direkt in der Datenbank ablegt. Insgesamt lief das ganze recht flott, auch bei vielen simulierten Zugriffen und einer 2GB großen Datenbank voller Bilder.

Allerdings befanden sich in der Datenbank die vollen Bilder und die Thumbnails wurden optional in einem Cache zwischengelagert oder "live" erzeugt ;-). Insgesamt fanden wir dieses System aber auf Grund der vielen Zugriffskontrollmöglichkeiten besser als die normalen Ordnerstrukturen, da man hier nicht einfach mal an die Bilder rankommt, wenn man den Datenbankzugriff vernünftig absichert.

 

[ice-breaker]

@JP-M: und wenn ich Bilder in der Datenbank speichern möchte die größer als die maximale Größe eines MySQL-Paketes (max_allowed_packet) fliegt mir alles um die Ohren.
Zudem wurden Datenbanken wirklich nicht dafür geschaffen, ich könnte jetzt tiefe Erklärungen über den Core und die Realisierung einer relationalen Datenbank bringen, aber das spare ich mir, die Datenbank ist dafür nicht ausgelegt und wird bei vielen großen binären Eintragen wie Bilder langsam, im Gegensatz zu einem Dateisystem welches auch mit 2 Millionen Dateien beliebiger Größe in einem Ordner kein Problem haben wird.

ich verweise mal hierauf, wo ich schonmal einige Gründe dagegen aufgeführt habe: Bilder abspeichern: Datenbank vs. Dateisystem
Fazit: Es ist für die Performance einer Datenbank grausam

 

[Belee]

Dei Bilder von Platte lesen ist schneller.

 

[ice-breaker]

Dei Bilder von Platte lesen ist schneller.

kann man so pauschal nicht sagen, ich kann auch ein Index auf die Bilddaten machen und hoffen, dass die Datenbank den Teil des Indexes im Ram hält, dann ist die Datenbank schneller. Aber die Idee ist schon abstrus

 

[Hancock]

Also grad bei Thumbnails und weitere Informationen ist eine Datenbank gerade gut (meine Meinung).
Weil sonst müsste man ja wiederum aufpassen, dass die Thumbs nicht als Datei angezeigt werden, inkl. updaten und löschen richtig verwalten.
Dass mySQL da so Probleme macht bei großen Sachen war mir nicht bekannt, könnte aber über so Sachen wie Datenbank-Streams gelöst werden (das gibt es!).
Da die DB das gleich auch Cached, ist ein weiterer Vorteil.

BTW: Große Datenmengen: Wenn ich meine Festplatte nach was durchsuche (nur Dateinamen) dann ist das ewig langsam, würde ich das alles in einer DB abspeichern, wäre es in Sekunden gesucht, gefiltert und nach Relevanz sortiert.

 

[Eagle-PsyX-]

Du suchst aber nicht. Du kannst Pfad systematisch ablegen oder den Dateinamen abspeichern. Dann wird der Endbenutzer direkt auf das Bild zugreifen ohne dass etwas 'gesucht' wird. Ob nun Dateisystem oder Datenbanksystem sei jedem selbst überlassen.
Das Caching ist bei so großen Dateien sowieso schnell an den Grenzen (zumindest in der Standard-Konfig).

 

[Hancock]

Ja aber wofür Thumbs wenn nicht zum suchen?

 

[Belee]

kann man so pauschal nicht sagen, ich kann auch ein Index auf die Bilddaten machen und hoffen, dass die Datenbank den Teil des Indexes im Ram hält, dann ist die Datenbank schneller. Aber die Idee ist schon abstrus

Das würde nicht lange gut gehen, ich spreche aus Erfahrung. Ab ca. 3.000 Thumbs war meine DB immer langsamer mit der Ausgabe, sehr oft wenn mehr User auf der Seite waren bauten sich die Seiten fast in Zeitlupe auf. Ich habe das nämlich vor 2 Jahren auch mal ausprobiert.
Hin und wieder bei Volllast hast du auch mal nur die Hälfte von einem Thumb angezeigt bekommen usw.

 

[ice-breaker]

ich habe doch gar nicht gesagt, dass ich das empfehlen würde

aber 3000 Thumbs sollten, wenn es korrekt gebaut ist, noch absolut kein Problem sein.
Ich habe Datenbanken mit Millionen bis Milliarden Datensätzen ohne Probleme im Betrieb.


@Blitzmerker: auch in einer Db würde es dann ähnlich lange wie beim Filesystem dauern, wenn du keinen Gigabytegroßen Index anlegst, um die Suche zu unterstützen. Datenbanken sind nicht auf magisxhe weise schnell...

 

[Belee]

Ich habe ja auch nicht gesagt das du das empfohlen hast

Du hast Millionen Datensätze mit Bildern im Betrieb? sorry aber das halte ich für ein Gerücht
eBay hat ja nicht umsonst vor 6-7 Jahren wieder auf Filesystem umgebaut also für die ganzen Thumbs und Bilder. Die hatten das ganze nämlich auch alles über die DB am laufen, das hatte ich dort gesagt bekommen weil meine Bilder die ich da eingestellt hatte sehr oft defekt waren oder verschwunden sind. Auf meiner Frage warum weshalb, erhielt ich dann die Info das man in Zukunft aufs Filesystem umsteigen würde und das dann nicht mehr passieren sollte.

Klar, man kann alles in die DB stopfen nur ich denke für Bilder ist eine DB nicht geeignet. Nicht wenn man einige tausend anlegt und dann auch noch Vollbetrieb auf der Seite herscht.
Ich kann mich jetzt nicht mehr richtig erinnern aber ich denke ich hatte auch Probleme mit BackUps, was da genau war weiß ich jetzt nicht mehr. Es gab aber Probleme.

Und wegen dem Speed, ich kann hier auch wieder aus Erfahrung sprechen. Werf 1.000 Thumbs in eine Verzeichnis und gebe sie auf einer Seite aus, das selbe mach mal über die DB, und dann stop mal die Zeit.

 

[ice-breaker]

ich habe auch mit keinem wort gesagt, dass ich Bilder in die DB speicher oO
Nur dass ich einige Datenbanken im Betrieb habe die deutlich größer als deine 30k datensätze mit Bildern waren und dementsprechend viel schwieriger sind performant zu halten.

Wenn man diemeisten Fehler vermeidet sind 30k Thumbnails garantiert kein Problem für die DB, sinnvoll ist esjedoch noch immer nicht.

 

[Belee]

ich habe auch mit keinem wort gesagt, dass ich Bilder in die DB speicher oO

Das liest sich hier aber so:

aber 3000 Thumbs sollten, wenn es korrekt gebaut ist, noch absolut kein Problem sein.
Ich habe Datenbanken mit Millionen bis Milliarden Datensätzen ohne Probleme im Betrieb.

Was soll sonst der zweite Satz wenn es hier um Bilder geht und nicht um normale Datensätze?

 

[ice-breaker]

Es sind keine Datensätze mit Bildern sondern mit Texten, diese werden aber durch die Datenbank, zumindest MySQL, identisch behandelt, mit dem Unterschied, dass das eine binär ist und das andere Texte. Die Größe pro Datensatz müsste aber ziemlich identisch sein.

Aber ehrlich gesagt habe ich da keine Lust mich zu streiten.
Ich wollte nur sagen, dass die pauschale Aussage vom Filesystem zu lesen schneller sei als aus einer Datenbank nicht stimmen muss, denn da hängen einfach viel zu viele Faktoren dran.

 

[Belee]

Hier möchte sich doch niemand streiten @ice...
Es ist aber doch ein Unterschied ob es Binäre Daten sind oder reiner Text. Teste es erst mal aus dann wirst du das feststellen.
Ich habe es getestet und das wurde von Leuten gemacht wo ich denke das die schon Ahnung haben, und die haben mir von meinem Vorhaben damals abgeraten. Naja, 2 Jahre sind natürlich eine lange Zeit, kann ja sein das es nun besser ist? keine Ahnung.

Aber ReadMe

 

[IceMatrix]

Thumbnails solltest du immer im Dateisystem ablegen. Als Hauptgrund würde ich gar nicht mal anführen, dass die Datenbank langsamer ist. Das muss bei einer lokalen Datenbank nämlich gar nicht der Fall sein.
Der Vorteil bei einem Dateisystem ist aber, dass du es leichter replizieren kannst, sozusagen als content delivery network.

@Belee: Haste MyISAM genutzt und regelmäßig in die Thumbnails-Tabellen mit INSERT/UPDATE/DELETE zugegriffen? Dann ist es kein Wunder dass es lahm ist.

 

[ice-breaker]

Es ist aber doch ein Unterschied ob es Binäre Daten sind oder reiner Text. Teste es erst mal aus dann wirst du das feststellen.

Ist es nicht
Ich weiß wie Datenbanken im Detail bis auf die Speicherung auf der Festplatte funktionieren und auch wie MySQL es tut.
Es als Text oder Binary zu speichern macht nur den Unterschied, das es an wenigen Stellen anders betrachtet wird, solange man nicht innerhalb der Binärdatei oder des Textes sucht macht es nachher keinen Unterschied mehr.

@IceMatrix: MyIsam wird wahrscheinlich der eine Fehler gewesen sein, der aber auch noch verschieden Ausprägungen hat. Die Lock-Algorithmen sind nur ein Teil der Problematik, MyISAM speichert die Daten ohne sinnvolle Ordnung auf der Festplatte, fragt man also 5 Bilder ab, führt dies dann zu 5 RandomIO-Operationen. Dann ist das alles wahrscheinlich in einer Tabelle gespeichert worden vermute ich mal, dass noch Queries dazugekommen sind, die den Index nicht korrekt ausnutzen können oder dass temporäre Tabellen auf der Festplatte erstellt wurden, denn bei Text- und Binär-Spalten geschieht das autom. wenn MySQL sagt es braucht für die Query eine temp. Tabelle. Und Schwups ist die Performance im Keller.


Das meine ich mit: "wenn man nicht haargenau weiß was man tut". Relationale Datenbanken sehen einfach bedienbar aus, um sie aber wirklich effizient nutzen zu können, muss man haargenau wissen, was in ihnen vorgeht und wie die Operationen realisiert werden. Bei kleinen Popel-Datenbanken wird man nie Probleme bekommen, das kommt dann erst bei großen Datenbanken.