Fotky do databáze nebo souboru?

[stewe]

zdravim,

situacia: webovy portal, moznost registracie, kazdy uzivatel ma profilovu fotku
otazka: ako ukladat ku kazdemu profilu profilovu fotku? malo by to byt ulozene ako blob, alebo ako bytea (tusim je taky typ v postgres-e) alebo to ukladat ako subor na disk s tym, ze si vymyslim nejaky hash aka nazov fotky a potom ten nazov (cestu na disku) ulozim ako varchar do stlpca "foto" v tabulke uzivatelov?

ake su vyhody / nevyhody oboch rieseni?

diky za tipy

[Reklama]

[Lenin POWER!]

cpat to do databaze. Pouzivame u vsech reseni, taky to zakaznici vyzaduji. Snadnejsi administrace aplikace. Co se dava mimo databazi jsou jen lucene indexy pokud se pouziva externi lucene a ne to co je integrovany v db2.

pokud bude to cteni LOB objektu brzdit server (zalezi jaka tam bude zatez) tak pred apache prasknout varnish a ty URL cachovat.

Nejakej typ jak to ulozit do databaze bych neresil. Nechal bych tam ten default to tam da ORM. Dneska delat aplikaci bez ORM to zbytecne prodrazuje vyvoj a zvysuje moznost chyby.

Ted jsem si vzpomel ze mame jednu postgresql aplikaci co jede pres hibernate a pouziva LOBy pro uploady:


\d upload
                 Table "public.upload"
    Column    |            Type             | Modifiers
--------------+-----------------------------+-----------
 id           | bigint                      | not null
 version      | bigint                      | not null
 comment      | character varying(80)       |
 data         | oid                         | not null
 date_created | timestamp without time zone | not null
 ip           | character varying(15)       | not null
 sha1         | character varying(20)       |
 size         | integer                     | not null
 status       | character varying(3)        | not null
 username     | character varying(16)       |
Indexes:
    "upload_pkey" PRIMARY KEY, btree (id)

[iGi]

Kedze sa jedna o profilove fotky tak nie je predpoklad ze by tam bola nejaka zataz.  Ak by sa uz islo o web kde je vela dotazov 3000 a viac (za sekundu) tak jednoznacne to hodit do filesystemu, len to uz potom treba riesit veci ohladom synchronizacie transakcii (vymazanie suboru napr. ak sa odstrani subor a nahodou nezbehne commit a podobne). Ak pouzivas spring s anotovanim riadenim transakcii takpouzit TransactionSynchronization a pridat metody do commit a rollback.

[Mordae]

Prave ze na profilovky bude nejvetsi load. Asi zalezi na velikosti projektu. DB + cache zni jako fajn napad.

IMO dokonale ciste reseni to bude davat do FS nebo do Haystacku a periodicky udelat garbage collect na nedostupne fotky, ale to je opravdu hodne usili za malo muziky.

[X125]

Jednu malou fotku do dB.
Hodně fotek (velkých) do FS.

[Reklama]

[Lenin POWER!]

No pokud jede ve springach tak varnish neresit, misto toho tam dat @Cacheable.

Stovky LOBu databaze nacist za sekundu dokaze. Nekde jsem mel test na rychlost zpracovani LOBu. Pamatuju si ze zapis do lobu je vyrazne pomalejsi (10x) nez zapis do varchar, ale u cteni to zase takova tragedie nebyla.

Ono se spis jedna o kulturni rozdil. PHP programatori jako spravna prasata zapisuji do filesystemu, sql dotazy koduji rucne a nekteri borci generuji i kod .php stranek automaticky ktere pak include. Pani javisti nechaji ORM at se jim o to postara a pokud 2nd level cache v ORM z nejakeho duvodu nevyhovuje tak otaguji metodu @Cacheable a dal to neresi. To uz je vec admina, aby to dotunil.

PHP pouzivaji lidi kteri jsou presvedceni ze by se jim nevyplatilo investovat 2 tydny do nauceni springu.

[alefo]

No hej, a co ked som mlady vyvojar, co nema na zaplatenie Java webhostingu?

[Kit]

Jednu malou fotku do dB.
Hodně fotek (velkých) do FS.

Snad obráceně, ne? Málo fotek do FS, hodně fotek do DB.

I když dnešní FS si poradí i s několika milióny fotek v jednom adresáři, neboť od určitého počtu záznamů se přepnou do režimu B-stromu. Daný adresář se pak chová jako indexovaná databáze.

[Lenin POWER!]

No hej, a co ked som mlady vyvojar, co nema na zaplatenie Java webhostingu?

Dulezity je mit znalosti. Kdyz budes umet delat Java aplikace tak pak nabehnes na jeden z tech bounty hunters serveru kde si najimaji lidi na kratkodobe veci. Tam zjistis ze javista dostane asi 4x vice nez PHP manik a navic je tam javistu neustale nedostatek.

Normalne se tam Javistum treba nabizi 1000 USD za nakodovani 1 webservicu jako modulu do axis2 nebo do spring aplikace. A mastit webservices z dodaneho WSDL to neni nic co by ses na tyden, dva nenaucil. Nakodis 1 webservis a mas tak na 5 let hostingu.

Musis si proste umet poradit. Proc si myslis ze 95% lidi v zivote selze. Kdyz jsou mladi tak maji velke plany co jednou budou ale nikdy se jim nesplni. Protoze neumi resit problemy a pak najivne si mysli ze ti lide co jsou uspesni nikdy zadne problemy nemeli. Problemy tu ma kazdy. Ten kdo se poctive pripravoval a trenoval tak je dovede uspesne vyresit. Ti, co se flakali a velice se snazili vyhybat praci a delat jen to opravdu nezbytne nutne minimum ti to nedokazi. Prace je vubec nezajima, jediny co je zajima je vyplata. Bez zajmu o praci se pracuje tezko.

A kdyz se nepracuje tak pak nejsou vysledky. Pracovat se musi hlavne efektivne. Pak ta prace jde rychle kupredu a cloveka to bavi.

Pokud se jedna o produkci tak tam jde o to aby se minimalizovala udrzba kterou musi delat admini. Aby to proste bezelo samo. V tomto smeru je i5/OS genialni system. Ten dokaze bezet leta aniz by na to musel admin sahnout, db2 v i5/os se umi automaticky tunit naprosto vyborne. Takovydle systemy pouzivejte a prodavejte zakaznikum. Takovydle veci delejte a prodavejte, na PHP se vykaslete to je o nicem. Nebojte se ze by lidi to i5/os nechteli. Kdyz je namotivujete, tak si vezmou cokoliv, oni si kupuji aplikaci OS a databaze je nezajima. Bezi vam na tom systemu websphere, databaze, LDAP server a reportovaci system. Vsechno tohle dostanete pribalene k OS zadara. Tyhlety SW bundly pro jsou desne vyhodny - a to jak pro i5 (vic) tak pro mainframe (mene). Navic vam ted na i5 bezi i PHP a MySQL (db2 ho emuluje). Je k dispozici spousta jazyku v kterych se na tom da delat, rek bych ze vic nez na jakykoliv jiny platorme. Umi to i mainframovy i unixovy prostredi.

Banky vyrazuji masiny s i5/os zhruba po 10-15 letech produkce; ta masina se za 15 let zaplatila mnohonasobne. Jestli tam maji cloveka do tomu nejak vic rozumi? Ale nemaji, oni si na vsechno nadstandardni volaji servis, neumi si tam vymenit ani disk v RAIDu. Inu banka. Ty masiny maji pri vhodne konfiguraci 5 devitek dostupnost i kdyz nebezi v clusteru. Proto to banky tak radi pouzivaji - spolehlivy provoz zvladnou i ty trdla co tam maji.

Ono se to nezda, ale v produkci jsou downtimy velmi drahe. Treba PostGreSQL ma podle nasich statistik vypadky 1x rocne. Ono se to nezda tolikrat, ale DB2 LUW nemela tenhle typ vypadku (pokurvili se indexy a db pak seqfaultovala) za 15 let. Chce to databazi, ktera kdyz zjisti ze se ji rozbil index (nesedi checksumy stranek) tak ho automaticky znovu vytvori bez zasahu admina.

Shrnuto: Cokoliv je lepsi nez LAMP. Hostingu se nebat, vydelate si na nej. Chce to vlastni snahu a touhu naucit se neco poradnyho. Ja bych v cechach sel do i5/os. Nikdo to tam prakticky nedela, co vic si prat? Mrknete na novinky v 7.1 (nejsou tedy nic moc, sestka byla vice revolucni). Nejpouzivanejsi je porad V5R4. To je podobny jako s websphere. Ted je sedmicka, osmicka v bete ale vetsina lidi jede na mainframech porad petku. Lidi proste neradi upgraduji na mainframech SW, HW ten naopak upgraduji velice radi a rychle. U nas je to stejny, my taky neupgradujeme soft pokud to neni nezbytne ale opravdu nezbytne nutne. mame na mf db2 8 (ted je 10), IMS 8 (ted je 12 v beta)  a opravdu neplanujeme migraci v nasledujicich 2 letech. Podle vetsiny lidi se namaha spojena s migraci nevyplati. Kdyz stavajici system vyhovuje, proc ho menit a zase testovat a patchovat aplikace.

http://www.redbooks.ibm.com/abstracts/sg247858.html

[Tomas Matejicek]

Varianta A, ukladani do filesystemu:

pokud bude mit web 10 000 uzivatelu, bude ve filesystemu v jednom adresari 10 000 souboru. To nektere filesystemy dost brzdi. Jak uz bylo receno, cas od casu muze dojit k vytvoreni nejakeho odpadu (soubory ktere uz nemaji odkaz v DB, nebo obracene radky DB ktere nemaji soubory). K tomu muze dojit proto, ze ulozeni do databaze a ulozeni do filesystemu jsou 2 operace ktere neprobehnou atomicky - pri vypadku se proste udela jen jedno (treba ulozeni radku do databaze) ale ne to druhe (ulozeni souboru na disk). Jsou tedy nutne dalsi tools na detekovani a opraveni techto vadnych stavu. Dalsi nevyhodou je, dospeje-li aplikace do stavu, kdy je nutne ji nechat bezet z vice serveru - pak je nutne synchronizovat fotky z disku nejak mezi jednotlive nody, pokud tedy nejsou ukladane na nejaky sitovy disk.

Varianta B, ukladani do DB:

Obecne nehrozi nekonzistence dat jako v predchozim pripade, pri prechodu na vic serveru je mozne databazi jednoduse replikovat, nebo servirovat z centralni vykonne masiny. Pro velke zatizeni je samozrejme nedobre, kdyz mi nacitani profilovych fotek zpusobi dalsi zatizeni databaze, ale jak uz bylo receno, je mozne profilove fotky cachovat, aby se databazi ulevilo. Jedine co je asi nevyhoda je celkova velikost databaze, neb bude obsahovat i ty fotky, ale tohle je dost relativni, pro nekoho je uz 1GB moc, pro nekoho je 1TB malo...

Doporucuji tedy profilove fotky ukladat do databaze, ale ja sam z pohodlnosti (a ze zvyku) ukladam do filesystemu, nicmene do vetsiho stromu, typu
images/b/a/b/babicka.jpg
images/k/a/r/karkulka.jpg
atd

[KapitánRUM]

Já jsem ještě ze starý školy a k ukládání fotek do DB mám nedůvěru.

Optimální mi připadá způsob ukládat do DB jen klíč.
URL+klíč+.jpg = cesta k souboru.

Modelová situace:
Dokud výkon serveru stačí, bydlí obrázky i DB na jednom serveru.
tj. http://srv1.cz/blablabla/bliblablop.jpg
Jak výkon přestává stačit, skript začne předhazovat jinou základní url.
http://srv2.cz/blablabla/bliblablop.jpg
Ale DB jede stále na srv1.

Ostatně tahle technika se používá například na načítání některých JS knihoven - dělá to tak Google.

Pak je i hrozně jednoduché si místo dalšího serveru si připlatit jen za prostor na webu.
Tj. ,,objemný" trafic patláte někomu, komu to vlastně nevadí a samotný server s DB si spokojeně odpočívá.

Sync probíhá TŘEBA následovně:
Nový obrázek se nahraje na server kde je DB, do DB se uloží úplně nové ID (což je vlastně jméno souboru v nějakém stromě).
Jednou za nějakou dobu - například CRONem, se smaže obsah vzdáleného serveru a přenesou se tam všechny nové obrázky ,,jak jsou", od té chvíle jedou na novém serveru, do té doby se načítají ze serveru kde je DB

Výkon se tak dá snadno rozložit na několik serverů.

Největší a prakticky jedinou nevýhodou je omezení přístupu podle oprávnění.
Lze použít metodu neuhádnutelné URL, což je jednoduché, ale ne zcela bezpečné.

[vyvojar www aplikaci]

Bloby cpat do filesystemu a v DB si poznacit pouze nazev souboru a nejake info o nem, pokud to bude potreba, treba hash, nebo datum posledni zmeny, delku, content-type atd. Ja jsem takove data taky onehda preferoval v databazi, ale brutalne jsem si na tom vylamal zuby jak se aplikace casem rozrostla, zacala diky velke databazi obrazku chcipat a bylo potreba ji po case velmi razantne prepsat a data z databaze proste vyhazet do FS. Kdybych daval tento typ dat do FS, usetril bych si spoustu prace. Dnes uz po letitych zkusenostech s vetsimi a vcelku narocnymi aplikacemi pro nase zakazniky (velkoobchody atd.) bych obrazky do DB nerval nikdy.

[Lenin POWER!]

ted jsem si to zkusil na notebooku a do DB2 9.7.4 (free edice) to vklada bloby rychlosti asi 4500-5000 za sekundu pokud se jede z vice vlaken soucasne (pouzivam 10) a je zapnuty logovani (takze se da delat s datbazi rollforward a ty bloby tam budou).

Cte je to pomaleji zhruba 2000 za sekundu.

Program je v groovy s vyuzitim baliku groovy SQL, tedy zadne prepared statementy a podobne higtek veci. U tehlech veci kdyz si date blok zpracovani + prepared statementy tak dostanete 3x vyssi vykon.

Zkusil si to nekdo z vas nakodovat a zmerit? Ani jeden. Vsichni jen dokazete knourat jak je to nemozny a pomaly to cpat do DB. Nemate proste odvahu to zkusit a hned vsechno vzdavate, bojite se neuspechu, bojite se prace.

Strucne receno: Jste zbabelci.

[Petr_Svetr]

Nehci se dotknout soudruha Lenina, ale poslednich par let delam ECM a nevidel jsem snad jediny produkt, ktery by cpal binarky do DB. A to nemluvim o nejakym bastlu od studentiku, ale reseni pro korporaty. Pokud by bylo ukladani do DB skutecne o tolik efektivnejsi, tak by se urcite nasel alespon jeden, ktery by to do ty DB placnul (navic je to i jednodussi). Ale fakt jsem to nikdy nevidel (reseni je nejcasteji Java s Hibernate). Bavim se o desitkach GB binarek rocne, pro par fotek je to asi sumak. Ukladani do FS ma dalsi vyhodu v tierech, snadno muzes data delit podle naroku na rychlost pristupu, coz u DB bude asi trochu komplikovanejsi. Velky pocet souboru v adresari na FS neni problem, obvykle systemy delaji strukturu slozek a do kazde sloky ukladaji max. stovky souboru a podle ID v DB potom snadno sahnou do FS a urci slozku, ve ktere se soubor nachazi.
Takze teoreticky muze byt ukladani binarek do DB opravdu rychlejsi - az rozbehnes finalni aplikaci a uzivatele ji zacnou pouzivat, tak budes mit velky problem to udrzet v chodu, protoze vsechno pujde jenom pres DB.

[RDa]

Udelal jsem jednoduchou tridu v PHP na ukladani avataru (save vrati uniq id, load cte uniqid), pri pouziti souboru me to dava tyto vysledky (paralelni beh 10 vlaken):

2414 wr/sec, 14607 rd/sec z disku, 59311 rd/sec z cache

HW: Core2Duo E8400, 8G ram, 60GB OCZ-VERTEX2.
Avataru bylo 10x10.000 (celkem 100K), velikost 3709 (tj. do jednoho 4K clusteru)

Rozhodne je to lepsi vysledek nez Leninovych 2K z databaze, protoze se avatary spis prezentuji nez zapisuji. Jen pro informaci, pokud dosahnete takoveho vytizeni, tak tech 60K/s dava traffic ~220MB/s. Zde vas jiz bude omezovat pripojeni serveru.