Finch

Hallo Leute,

aufgrund des Wartungsaufwandes möchte ich die Bilder meiner Webgallary in der Datenbank speichern und abrufen. Das speichern erfolgt über externen MySql Zugriff (C#, haut schon supi hin). MySql deshalb weil ich mehrere Alben mit bildern und diese wiederum mit Kommentare und hitcouter blabla also ne schöne Relationale Datenbank. Ich möchte jedoch auch die Bilder in der Datenbank haben denn ich möchte sie drehen löschen und dabei die Verbindung zur FotoID beibehalten.

Es wird in den meisten Foren nichts gutes über das abrufen von Bilder aus der Datenbank geschreiben. Doch bei großen Webportalen ist es ja gar nicht anders Möglich... siehe ebay

Das Hauptproblem ist das die leute ne * Abfrage und/oder Bilder mit 1000k abspeichern.

Also meine Thumbnail sind <10k und die Bilder <100k. Bild wird immer nur 1es dargestellt und Thumbnails ca. 30.

Meine Frage: Was ist die schnellste/beste Möglichkeit Bilder aus der Datenbank in eine html Seite zu bekommen, seit php 5 ?

Mister Ad

mepeisen

Was meinst du denn genau mit "schnellste und beste Möglichkeit"? Die schnellste und beste Möglichkeit, ist den Apache den direkten Zugriff auf ein lokal abgespeichertes Bild zu ermöglichen, wegen mir auch die Bilder aus der DB auszulesen und lokal zwischenzuspeichern (in der Art eines Caches). Wieso du eBay als Grund nennst, Bilder in die Datenbank abzuspeichern, erschließt sich mir nicht. Der enzige Grund für eine zentrale Datenhaltung solcher BLOBs über eine DB ist in der Regel eine Cluster-Anwendung. Wenn du grundsätzlich mehrere Webserver in ein Cluster schließen willst, sag es nochmal.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

robo47

Mal ein paar Beispiele für Systeme wo es nicht anders möglich ist ?
Hast du Informationen dazu welche Bilder und warum bei Ebay in der Datenbank speichert ? Also irgendwas, was deine Aussage abdeckt ? Weil ich denke nämlich eher dass die ihr eigenes CDN oder das eines Anbieters nutzen für das ablegen ihrer Bilder, weil das ablegen in der Datenbank mag zwar für viele auf den ersten Blick die einfachste Lösung sein, aber spätestens wenn es mal um Performance und co geht wird man da wohl kaum auf eine normale Datenbank zugreifen, sondern wenn dann irgendeinen speziellen Image-Server (den man eventuell "ähnlich" einer Datenbank ansprechen kann) oder halt einen Anbieter für CDNs.

Beim ersten nachschauen (soweit man den Server-Headern vertrauen kann), die Bilder die in Angeboten verwendet werden liegen auf einem Apache Coyote-Server, die statischen Bilder unter pics.ebaystatic.com auf einem IIS 5.0

Gerade wenn der Datenbank-Server extern ist, bedeutet es halt im Endefekkt immer doppelten Traffic für den Webserver, weil jedes Bild erst von mysql zum webserver muss und von dort dann wieder raus an den Client UND für jedes Bild muss PHP laufen (verbraucht cpu-zeit + ram) (Mal vorrausgesetzt man hat nicht noch irgendwelche Caching-proxys ala Squid vorne dran laufen).

Vor allem werden die Datenbankdumps dadurch sehr schnell sehr groß was weder den Backups noch einem neuen einspielen sonderlich förderlich ist, sprich über phpmyadmin wird man da schnell an die grenzen kommen, was den einsatz von tools wie mysql-dumper, extern erreichbarer mysql-server oder zumindest zugriff auf die mysql-console erfordert.

Also abhängig davon was dein Zielfeld ist (o8/15 webspace, v/root-server oder eigene Server-Fram) und wie viel Daten du vor hast abzulegen, solltest du das ganze nochmal überdenken.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Flor1an

Normaler weise wird das so gemacht dass du die Bilder direkt abspeicherst und dann einen DB Eintrag für das Bild erstellst in dem steht wo das Bild liegt. Somit kannst du weiterhin Daten zu dem Bild speichern (Kategorie, Kommentare).

Gibt meiner Meinung nach keinen Grund die Bilder in der DB zu speichern.

nikosch

Ich kann mir kaum was wartungsaufwändigeres vorstellen.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

ventrix

Würde ich so nicht sagen, es gibt einige Vorteile.
z.B. höhere Integrität, da keine Bilder ohne Eintrag gelöscht werden.
Höhere Verständlichkeit, da Infos und Bild nicht getrennt sind.
Höhere Sicherheit bei evtl. falsch gesetzten Rechten im Dateisystem.
Bessere Portierbarkeit. Einfach ein Backup einspielen ist leichter als alle Bilder rüberzuschieben, Rechte zu setzen usw. (Wobei das backupen selbst schwerer wird)

Aber auch Nachteile:
Perfomance z.B.
Es wird für jedes Bild ein neuer Prozess gestartet und die Datenbank belastet. Eine Abfrage im Dateisystem ist da gerne mehr als 100% schneller. Da bringt auch keine besondere Technik etwas. Würde man es cachen, könnte man es ja gleich im Dateisystem ablegen.
Der Browser kann die Datei nichtmehr cachen, da er die Aktualität des Bildes nicht überprüfen kann. -> noch höhere Belastung und zwar für beide Seiten.

Wirtschaftlich gesehen meiner Meinung nach die totale Fehlentscheidung.
Auch im Bezug auf die Wahl der Datenbank. Mysql kann Bilder (BLOB) nicht fragmentieren und ist daher an die in der Konfiguration angegebene Maximalgröße gebunden.

nikosch

Wie gut die Integrität der DB ist, steht auf einem anderen Blatt.
Dann wärst Du der erste den ich kenne, der Bilder in Binärcode erkennen kann. Da sagt ein Pfad wohl deutlich mehr.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

ventrix

Auf welchem Blatt sollte es denn stehen?
Wenn die Bilder mit den Informationen zusammen gespeichert und nur zusammen gelöscht werden können, dann ist die referentielle Integrität für die Bilder gesichert.

Es liegen alle Infos gebündelt vor und kann zum Verständnis und zur Wartung beitragen. Wenn dein DBMS nur Binärcode anstatt die eigentlichen Daten ausgibt und somit (mind.) 2 Verarbeitungsebenen überspringt, dann ist das dein Problem. // Mal davon abgesehen, dass so gut wie jeder noch eine externe Ebene nutzt, z.B. in Form von Adminbereich. Und da lässt man die Daten sicher nicht Binär anzeigen.

Eine Diskussion auf dem Niveau "ich pick mal 2 HALBE Sätze raus und mach sie lächerlich" ist unnötig.

Finch

Ok, danke für eure Antworten. Das bedeutet um auf Daten der Datenbank zugreifen zu können muss man sie immer am Server cachen. Und somit wirds auch immer langsamer sein. Die Frage ist um wieviel ists langsamer bei einem durchschnitts webserver. (domaingo)

Mit schnellste/beste Möglichkeit mein ich eine Variante die nicht für jedes Bild ein eigenes php file erzeugen muss alla: <img source="bildderdatenbank.php">
Würd mich über ein Codeschnippsel freun, möchts selbst testen ob ein zeitlicher Unterschied spürbar/messbar ist.

Hauptbeweggrund: Will nur vermeiden einen zusätzlichen externen ftp Zugang zu verwenden.

Ganz andere Frage wie bringt ihr die Bilder auf den Server?

Für mich muss: Mehrfachauswahl von Bildern + Bilder clientseitig verkleinern um Uploadzeit zu verringern.

Flor1an

Was genau möchtest du? Willst du jetzt die Bilder auf der Festplatte oder doch in der DB speichern (indirekt natürlich auch auf der HDD)?

Ich lade Bilder meist über FTP hoch, ist die einfachste Methode finde ich. Für normale Webuser gibts eben nen Webinterface. Da gibts mitlerweilen gute Flashuploader bei denen du auch mehrere Dateien selektieren kannst damit es schneller/einfacher geht.