Foto's in MySQL - voors en tegens???

[Duwgati]

Ik wil wel eens weten of er iemand ervaring heeft met het plaatsen van foto's/screenshots in een MySQL database. Dus niet het management van de foto's, maar de foto's zelf.

 

Ik moet besluiten of het zich loont om al mijn foto's/screenshots in mijn database te proppen. Het zijn in totaal ca. 1200 images en het is ong. 20 MB aan data.

 

Wat ik echter niet weet is of de performance een beetje overeind blijft, hoewel dat volgens mij vooral afhangt van de juiste structuur en inrichting van de database. Maar wie weet het zeker? Wie heeft ervaring?

 

En zijn er scripts om batch-uploading te doen? Dus bijvoorbeeld een hele subdirectory ineens uploaden en per directory (huidige structuur) een nieuwe MySQL-tabel creëren.

[rlckring]

Ik heb het zelf ook wel eens geprobeerd, en werkte goed.

 

Alleen een Myssql BLOB CEL (voor binaire opslag) kan alleen iets minder dan 1mb hebben dus voor grotere files zul je een speciale routine moeten schrijven. Per cel word '906240 bytes' geadviseerd en, ik heb het zelf beproefd, het kan inderdaad niet meer zijn.

 

Bijlage een stukje code hoe ik het ongeveer had, kun je kijken hoe ik het bedoel. Er zullen ongetwijfeld scripts zijn maar kon toen zelf ook niets vinden en ben met hulp van php.net zelf wat gaan knutselen..

 

Je ziet dus 2 tabelen 1 bevat de 'Filename', 'FileExtension', 'FileSize'

en de andere 'insertID van de 1e', 'Binaire_Data'.

 

Dit script was voor mij toen voor file uploads via HTML POST en bevat dus alleen de opslag actie, voor lezen/downloaden moet je net zo iets schrijven.

Maar je weet nu de manier..

 

Ja voor performance zou ik het laten, niet doen dus...

633630-Nieuw - Tekstdocument.txt

[Duwgati]

De file-size zou geen probleem mogen zijn, want de grootste image die ik gebruik is iets van 50Kb. Net te groot voor medium blob dus, maar met de 'normale' longblob kom ik ruimschoots uit.

 

Ik heb er vanmiddag trouwens al aan zitten programmeren en zelf al iets in elkaar getimmerd om te uploaden en weer te displayen, maar ik heb ook al van diverse anderen begrepen dat het aanzienlijk trager is dan de images gewoon 'plat' op schijf zetten. Zoals ik het nu heb dus.

 

Enfin, ik denk dus nog <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

[pinocchio]

Of heel het verhaal klopt... ik weet het niet.

Maar je hebt wat leesvoer.

Waarom kun je beter geen plaatjes in een database zetten?

[deduijk]

Grappige van het verhaaltje van je is, dat De zgn. oplossing dus in werkelijkheid geen oplossing is. Om de naam van een bestand te gebruiken uit de database , moet nu toch een script gedraaid worden.

 

En dit script verteld nu alleen waar het bestand staat. Wat betekent dat je dan pas de link heb om het bestand te tonen. Het bestand moet daarna dus nog geladen worden.

 

Een nadeel noemt het zelf al.., je moet alles toch per hand doen.., dus waarom zou je dan een database bijhouden...

 

Feit blijft wel dat een database eigenlijk geen bestandssyteem is (je moet om het plaatje op te slaan het bestand lezen in een object en dit dan weer als binaire data in het database veld voegen {APPEND}).

 

Ik werk toch met een database voor mn plaatjes in een bepaald project: Ik heb een mailing lijst programma geschreven in ASP (+vbscript, jscript) met als database een access database. Dit omdat er plaatjes moeten kunnen worden toegevoegd als links in een mailing (in de mailing gaat dus het script als link mee, wat realtime wordt geladen bij de ontvanger). Zolang je je database optimaliseerd, heb ik nog geen extreem lange wachtijden gezien, moet ik er natuurlijk wel bij zeggen, dat er op het ogenblik (nog) niet zoveel plaatjes in zitten.

 

Wat ook jammer is dat de historie van het bericht niet vermeld wie en wat de auteur is....

 

Ik weet niet of jou host asp ondersteund duwgati..?

 

CU,

deduijk

[Duwgati]

Ja, hij ondersteunt asp. Maar of ik daar wat aan heb is de vraag. Ik ken zelf geen asp, en ik draai liever geen scripts die ik zelf niet kan beheren. Tenminste niet als ze zo essentieel zijn voor de werking van de site <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

 

Maar ik heb eens even alles door mijn hoofd laten malen, en er is 1 ding dat me toch wel belangrijk lijkt in de overweging, en dat is dat scripts niet gecached worden. Dat betekent dus dat idd voor iedere pagina-opvraag telkens opnieuw elke foto uit de database moet worden geladen i.p.v. uit cache, alvorens de server die pagina kan renderen. Nou is zoiets vast geen probleem bij enkele tientallen bezoekers, maar wat nu als je enkele honderden bezoekers tegelijk hebt???

Ik heb soms van die dagen dat er op een willekeurig moment enkele honderden bezoekers tegelijk aanwezig zijn. 409 unieke bezoekers tegelijk aanwezig, is tot op dit moment het hoogst gemeten aantal. Dat was op 31 mei. Ik had toen in 1 uur tijd 2348 unieke bezoekers op de site. Mij lijkt dat dan de performance van de database wel eens kritisch zou kunnen worden, of zie ik dat fout?

[deduijk]

Ik heb het nog even nagezocht, maar je kan asp pagina's maken die de binaire data bevatten. Deze kan je dan een expiratie-datum geven. Wat betekent dat tot die tijd het plaatje 'gecashed' is; het plaatje wordt pas weer uit de database gehaald na de expiratie datum.

 

V.w.b. de database performance, dat hangt af van welke database je kiest. En van hoe je je script hebt gemaakt. De database connectie in het script moet zo snel mogenlijk weer sluiten. Mysql, ms Access voldoen nu niet. Access mag maximaal 255 gelijktijdige gebruikers hebben (gelijktijdig in de database; dus vertaald niet helemaal naar bezoekers met goed geschreven scripts..), Maar op toch zeker te zijn zou ik er dan een oracle database aanhangen. (of misschien een SQL database, maar daar ken ik de specs niet zo goed van).

 

Eventueel kan je je vraag stellen op

http://www.experts-exchange.com Op deze site kan je experts op dit gebied de vraag stellen. Ik ken nl wel ASP en databases e.d., maar dit is toch een zeer specifieke vraag, waar ik niet helemaal het antwoord op weet.. <img src="/ubbthreads/images/graemlins/anoniem.gif" alt="" />

 

Maar sowieso..., mySql zou ik laten.., de specs daarvan zijn nog slechter dan van Access.. <img src="/ubbthreads/images/graemlins/crazy.gif" alt="" />

 

CU,

deduijk

[Gast]

Om als eerste de vraag te beantwoorden. Ik heb het technisch wel werkend gezien (in combinatie met CMS systemen) maar ik vind het zelf erg vies. Een plaatje hoort wat mij betreft niet in een database thuis. In een database plaats je dingen waar je ooit op wil kunnen zoeken. Een plaatje zoek je niet. De meta data van een plaatje kan natuurlijk heel goed in een database. Maar ik ben nog al een purist op dit vlak <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />

 

Citaat:

Ik ken zelf geen asp, en ik draai liever geen scripts die ik zelf niet kan beheren.

 

Mag ik zeggen dat ik dit een hele gezonde instelling vind. Waarmee ik natuurlijk niet af wil doen aan het feit dat het aardig is als mensen hulp aan bieden. <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

 

Citaat:

en er is 1 ding dat me toch wel belangrijk lijkt in de overweging, en dat is dat scripts niet gecached worden.

 

Klopt. Al kun je wel wat doen aan de headers in PHP waarmee je caching toe zou kunnen staan. De vraag is dan alleen waarom je dan nog gebruik zou willen maken van een database?

 

Persoonlijk vind ik her principieel fout. Een database is geen file systeem. Het feit dat iets kan wil niet zeggen dat je het dan ook maar daarvoor moet gebruiken. Maar zoals bij de meeste principes is dit geen kwestie van "gelijk hebben".

 

Citaat:

tientallen bezoekers, maar wat nu als je enkele honderden bezoekers tegelijk hebt???

Ik heb soms van die dagen dat er op een willekeurig moment enkele honderden bezoekers tegelijk aanwezig zijn. 409

 

Hoewel ik zelf heel tevreden zou zijn met een dergelijk bezoekers aantal op mijn forum (is een muziek forum geen sat forum) zijn dit toch geen getallen waar een MySQL database van onder de indruk zou moeten zijn. Ook het aantal records in een MySQL database zou niet snel een beperking moeten zijn.

 

Citaat:

unieke bezoekers tegelijk aanwezig, is tot op dit moment het hoogst gemeten aantal. Dat was op 31 mei. Ik had toen in 1 uur tijd 2348 unieke bezoekers op de site. Mij lijkt dat dan de performance van de database wel eens kritisch zou kunnen worden, of zie ik dat fout?

 

Dat is niet zomaar zonder meer te zeggen. Dit hangt van je manier van connecten af (gebruik je een open/close connectie per query of maak je gebruik van een connection pool?) Staat de database op een apart systeem of op het zelfde systeem als waar de scripts draaien (lees: gebruikt het unix sockets of een IP connection over een lan en/of internet). Uberhaupt de snelheid en belasting van het systeem. Maar in z'n algemeenheid zou jouw aantal bezoekers geen probleem op mogen leveren (niet lullig bedoeld.. Nogmaals zoveel heb ik er lang niet).

 

 

Citaat:

Ik heb het nog even nagezocht, maar je kan asp pagina's maken die de binaire data bevatten. Deze kan je dan een expiratie-datum geven. Wat betekent dat tot die tijd het plaatje 'gecashed' is; het plaatje wordt pas weer uit de database gehaald na de expiratie datum.

 

Klopt. Dit kan met PHP ook. Het wel of niet cachen wordt door je headers bepaald. Standaard geven de meeste script talen een niet-cachen header mee. Ook wel logisch want scripts zijn normaal niet bedoelt om statische content terug te geven en is caching dus een vervelend bijverschijnsel. (Niet altijd dus maar in zijn algemeenheid dus wel).

 

Citaat:

V.w.b. de database performance, dat hangt af van welke database je kiest. En van hoe je je script hebt gemaakt. De database connectie in het script moet zo snel mogenlijk weer sluiten.

 

Nou dat ben ik niet helemaal met je eens. Het gebruik van persistent connections kan juist een enorme performance winst opleveren.

 

Citaat:

Mysql, ms Access voldoen nu niet. Access mag maximaal 255 gelijktijdige gebruikers hebben (gelijktijdig in de database; dus vertaald niet helemaal naar bezoekers met goed geschreven scripts..),

 

Waarom voldoet MySQL dan niet? Bij MySQL is dit aantal configureerbaar. Nu wil ik daarmee niet beweren dat het daarom per definitie beter is dan MySQL maar meer dan 255 is echt geen probleem. Je moet natuurlijk wel opletten (zeker als je connect ipv pconnect gebruikt) dat je meer MySQL connecties toe laat dan Apache/IIS connecties anders kan je Apache (of IIS) niet bij de database en krijg je database fouten te zien waar je eigenlijk iets anders bedoelt.

 

Citaat:

Maar op toch zeker te zijn zou ik er dan een oracle database aanhangen. (of misschien een SQL database, maar daar ken ik de specs niet zo goed van).

 

Oracle levert natuurlijk prima producten maar de prijs van MySQL is natuurlijk niet te verslaan? Of heeft Oracle ook al een gratis te gebruiken personal versie????

 

Citaat:

Maar sowieso..., mySql zou ik laten.., de specs daarvan zijn nog slechter dan van Access..

 

Mag ik vragen op welke specs je doelt want die van MySQL zijn bepaald niet kinderachtig. Ik weet dat er een stevig aantal zeeeer populaire sites vrijwel hun gehele content in MySQL hebben staan. Waaronder b.v. freshmeat.net en ik meen ook slashdot.org en SourceForge (maar die laatste 2 moet je me niet op vast pinnen).

[Gast]

Ook nog twee cent van mij <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />

 

Als database purist ben ik sowieso tegen het opslaan van plaatjes (of andere externe data) in een tabel. Buiten dat je er niet meer extern bij kunt, wel eens een verhandeling gelezen over data paging (het interne mechaniek waarmee een dbms records opzoekt etc) en het wel-of-niet passen van data? Omdat de database van binaire velden nooit weet wat het maximum formaat gaat worden krijg je al meteen de meest ongunstige opslag en, helaas, dito performance. Een sec filesysteem is veeeeel sneller met het terugtoveren van 'binaire data'. Bovendien ontlast je hiermee de database, ook al moet je inderdaad voor het scriptje dat de uiteindelijke img link gaat vertellen toch nog wel wat querien, dat is echter qua omvang niet te vergelijken (wat, 30, 40, misschien 50 bytes?).

 

En dan wat betref

Citaat:

Nou dat ben ik niet helemaal met je eens. Het gebruik van persistent connections kan juist een enorme performance winst opleveren.

 

Hierover zijn de meningen verdeeld <img src="/ubbthreads/images/graemlins/smirk.gif" alt="" />. In ieder geval voor servers die IIS draaien wordt aangeraden connecties zo snel mogelijk op te blazen, zodat IIS kan managen wat-waar-hoe gebeurt, ergo de draaiende applicaties optimaal gedraaid kunnen worden (configureerbare connectie pool etc) - dus beter schaalbaar. Ga je zelf bepalen hoe lang een connectie geldig blijft, dan bypass je in feite IIS. Draai je op je eigen server dan zal eea je natuurlijk compleet wurst zijn <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

[deduijk]

persistent connections is nu geen oplossing.., een asp script is in princiepe sessie afhankelijk. Dus openen wanneer nodig en meteen sluiten blijft mn devies...

 

Het feit of plaatjes al of niet in een database horen doet niet terzake.. <img src="/ubbthreads/images/graemlins/disc.gif" alt="" /> het gaat erom wat de bezwaren zijn ertegen dus performance etc, niet wat je ervan vindt.. <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

 

CU,

deduijk

[Gast]

Citaat:

Hierover zijn de meningen verdeeld <img src="/ubbthreads/images/graemlins/smirk.gif" alt="" />. In ieder geval voor servers die IIS draaien wordt aangeraden connecties zo snel mogelijk op te blazen, zodat IIS kan managen wat-waar-hoe gebeurt, ergo de draaiende applicaties optimaal gedraaid kunnen worden (configureerbare connectie pool etc) - dus beter schaalbaar. Ga je zelf bepalen hoe lang een connectie geldig blijft, dan bypass je in feite IIS. Draai je op je eigen server dan zal eea je natuurlijk compleet wurst zijn <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

Ik geeft direct toe dat ik geen ervaring heb met IIS en high performance sites maar ik heb in de praktijk zelf wel successen geboekt met LAMP (P in dit geval Perl niet PHP). Neemt niet weg dat je inderdaad gelijk hebt dat de meningen verschillen. Mijn ervaringen zijn positief maar dat is natuurlijk geen absolute waarheid.

Citaat:

persistent connections is nu geen oplossing.., een asp script is in princiepe sessie afhankelijk. Dus openen wanneer nodig en meteen sluiten blijft mn devies...

Dan zou voor IIS + ASP prima kunnen werken....en misschien wel voor andere omgevingen ook. Maar in dit geval gaat het om PHP. Hoe het daar uit pakt zal "je" (duwgati) zelf moeten bepalen...

Citaat:

Het feit of plaatjes al of niet in een database horen doet niet terzake.. <img src="/ubbthreads/images/graemlins/disc.gif" alt="" /> het gaat erom wat de bezwaren zijn ertegen dus performance etc, niet wat je ervan vindt.. <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

Ik lees de vraag wat ruimer (Voors en tegens) en dan vind ik de principiele vraag weldegelijk van toepassing. Met de bezoekers aantallen van Duwgati (niet lullig bedoelt!!) zou performance ook niet snel een probleem mogen zijn. Maar zoals gezegd is dit van meer factoren afhankelijk dan of er plaatjes in de database zitten.

Duwgati moet uit eindelijk zelf maar bepalen of welke delen van de berichten hij overneemt. Zal zonder twijvel een stukje van ieders bericht zijn... Ik beweer zeker niet de wijsheid in pacht te hebben.

[Duwgati]

Ik vind het een bere-interessante discussie aan het worden en ik leer weer eens wat nieuwe zaken hier. Perfect <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

 

Niet om de discussie te beëindigen, maar ik ben inmiddels bezig met een andere provider waar ik binnenkort een test mee ga lanceren. Als die performance en up-time e.d. me bevallen, stap ik helemaal over. Dus inclusief het download-archief en al.

 

OK, terug naar de discussie:

Nog even over de achtergrond van het plaatsen van foto's in een database. Het idee was puur geboren uit gebrek aan schijfruimte. Ik heb in principe voldoende schijfruimte als ik de ruimte van de MySQL database ook zou kunnen benutten. Maar daar zit het probleem. Ik gebruik maar een paar MB van m'n beschikbare DB-ruimte. Maar wat zou ik daar in kunnen stoppen. De teksten zou het meest voor de hand liggen, maar dat is om allerlei redenen voor mij niet interessant. De foto's zijn het meest statische deel van mijn site en daarom heb ik daarover lopen denken.

 

Ik vind het zelf ook niet per definitie een echt gewenste oplossing. Dat was ook voor mij de reden om deze vraag te stellen, om te zien of iemand me kan overtuigen dat het wel een geschikte oplossing voor mij zou kunnen zijn.

 

Maar hoe meer ik erover nadenk, hoe meer nadelen ik ga zien. Wat te denken bijvoorbeeld van de verschillen in de diverse PHP-versies. Ik heb inmiddels het zaakje wel in test aan het werken, maar het heeft wel even geduurd. Uiteindelijk kwam ik erachter dat het script dat ik als voorbeeld gebruikte(voor het tonen van de foto) gemaakt was voor PHP 3.?? maar dat voor 4.x wat aanpassingen nodig waren.

Als dat soort zaken ook al een rol speelt, heb ik het dus niet meer geheel in eigen hand. Dan loop ik in potentie, bij iedere update door de provider, het risico dat de site niet meer werkt zoals het zou moeten. En dan ligt het plat tot ik de oorzaak gevonden heb.

 

Nog afgezien van of de test met de nieuwe provider goed uitpakt of niet, voor mij is de oplossing niet bepaald ideaal. Denk ik <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

[Gast]

Foto's in een Database kan op een aardige manier. Pak een van de vele Dating, Man zoek Vrouw zoekt relatie etc sites op het web. Alle info die een lid inklopt gaan in een database incl foto.

Heb eens een script naar binnen gehaald en je kan het invoer gedeelte (account aanmaken e.d.) eruit halen. Blijft er over een hele mooie database incl foto's.

 

Hier (772Kb) kan je ze downloaden. Ik heb er 3 verschillende scripts ingezet en heb even gespeeld met Netpals200. Hun site is Atlantdesigns en het is volledig gratis (Open Source).

Alles gaat naar een MySQL database en er staan na installatie al wat voorbeelden in. Met PHP pagina's kan je er dan natuurlijk alles van maken.