Zadejte hledaný výraz...

Ukládání obrázku přímo do databáze

Kloban
verified
rating uzivatele
23. 8. 2014 11:30:34
Ahoj,
kdy má význam ukladát obrázky přímo do databáze a kdy je lepší, mít v databázi pouze odkazy na ně?
Máte s tím někdo zkušenosti?
Díky
23. 8. 2014 11:30:34
https://webtrh.cz/diskuse/ukladani-obrazku-primo-do-databaze/#reply1049735
Scorpius
verified
rating uzivatele
(19 hodnocení)
23. 8. 2014 11:49:21
Lepší je ukládat do DB jen odkazy nebo nějaká metadata, jak se k obrázku dostaneš.
Důvody?
1) Ulehčíš tablespace DB.
2) Významně si ušetříš paměť/čas v aplikaci - nemusíš sebou tahat velký blok binárních dat, ale máš jen odkaz.
3) Snadno přejdeš na externí storage s CDN (třeba Amazon S3)
4) Můžeš použít nginx(nebo podobný lightweight http server) a opět zrychlíš svou aplikaci.
Osobně preferuji rovnou externí storage, pokud to pro projekt není úplně nesmyslné.
23. 8. 2014 11:49:21
https://webtrh.cz/diskuse/ukladani-obrazku-primo-do-databaze/#reply1049734
crs
verified
rating uzivatele
(1 hodnocení)
28. 8. 2014 12:55:32
Není to tak jednoznačné.
Záleží na několika faktorech, jedním z těch důležitějších jsou průměrná velikost souboru a počet přepisování. Co se týče čistě výkonu, objekty do 256 KiB je lepší ukládat do databáze, objekty nad 1 MiB do souborů; mezi těmito hodnotami není jasný vítěz a mělo by se přihlédnout k dalším faktorům.
Jen poznámka ke Scorpiusově bodu 2) pokud se obrázek má zobrazit na klientově počítači, pak "velký blok binárních dat" se k němu musí přenést tak jako tak. Jde jen o to kudy.
výhody ukládání do souborů (doplnění):
* cesty, kterými se načtou všechny obrázky, řeší webserver (a jeho operační a souborový systém)
* tzn. obsahy obrázků nejdou přes databázi a nekonkurují si s konvenčními databázovémi daty
výhody ukládání do databáze:
* konzistence dat
* možnost uzamknout metadata do obrázku a jeho obsah jako jeden celek
* obrázek a jeho miniaturu lze držet atomárně v jednom místě
* lepší verzování (a možnost "undo" nad některými operacemi, která ve file systému jaksi nejde)
* při hromadné operaci s obrázky lze používat transakce
* nemáš omezení souborového systému
** v názvu (uznávám, že to většinou není problém, ale přece)
** v maximálním počtu souborů v jednom adresáři (uznávám, že se to dá vyřešit, ale přece)
** pokud to vyloženě takto chceš, můžeš mít víc obrázků stejného jména
** u případné migrace musíš myslet na specifika cílového souborového systému (jinými slovy je to na něm závislé), příklad: rozlišování velkých/malých písmen
* v případě obrázků SVG lze vyhledávat fulltextově v jejich obsahu
Pro více info viz například http://arxiv.org/ftp/cs/papers/0701/0701168.pdf (ta je mimochodem pro Win/ASP.NET/MSSQL Server). Vím, že o tom byl ještě český článek na zdrojáku nebo rootu, ale už jsem ho nanašel.
Dělal jsem projekty, kde byly obrázky ukládány jak do souborů tak do databáze, a nejsem zavilý zastánce ani jednoho - jednoduše každý způsob má své výhody i nevýhody.
mé zkušenosti v případě projektů, které soubory ukládaly do souborů:
* lidský faktor
** v jedné z prvních verzí byly přepsány soubory s lomítkem v názvu, protože lomítko bylo webalizováno na minus a soubor s tím názvem už existoval (byla to chyba programátora, neprezentuju to jako nevýhodu tohoto řešení).
** k projektu přibrali nového člověka, který jednoho dne změnil strukturu adresářů a než se na to přišlo a opravilo to, nefungovalo kompletně nic
** potom jiný člověk hromadně manipuloval s adresáři (kopíroval/přesouval..), byl přerušen telefonátem a po jeho skončení už si nepamatoval, kde skončil (a žádné ROLLBACK nebylo)
** jednou update souborů z nějakého obskurního FTP klienta zmršil názvy asi u tisícovky souborů, to bylo zjištěno až mnohem později a příšerná piplačka to všechno opravit
** jiný FTP klient měl zase při jednom takovém kopírování zapnut převod na malá písmena a tak u několika souborů se (z pohledu OS) cesta neshodovala soubory se nezobrazovaly
** přes všechna opatření u projektu s více lidmi s přístupem k FTP byly neustále čas po čase nacházeny nekonzistence jako chybějící obrázek k miniatuře či miniatura k obrázku nebo to, že si obrázek a miniatura neodpovídaly, apod.
mé zkušenosti v případě projektů, které soubory ukládaly do databáze:
* zálohovací SQL soubor (pochopitelně) nakynul na desítky MB
** u daného hostingu to zrovna nebyl problém, ale měl bych asi říct, že u jiných hostingů by mohl být
** to mě přimělo rozdělit zálohování speciálně pro obrázky a ostatní tabulky (které dohromady nezabíraly ani mega)
* ještě ad zálohování, konkrétně jeden velký soubor versus tisícovka malých - stáhnout/nahrát jeden velký soubor je (empiricky vzato) rychlejší, ale v případě přerušení spojení (nepamatuji se, že by se mi stalo) pak většinou přijdeme o všechno
* z localhostu se "někdy" i menší obrázky načítaly pomaleji, na hostingu to fungovalo normálně. Takže si vlastně tak jistý výsledky té studie nejsem. ;)
28. 8. 2014 12:55:32
https://webtrh.cz/diskuse/ukladani-obrazku-primo-do-databaze/#reply1049733
Pro odpověď se přihlašte.
Přihlásit