Pokud vsak nebudete mit vic HDFS serveru, bude lepsi pouzit primo filesystem. A jen to naimplementovat tak, ze v budoucnu v pripade velke zateze je mozne prejit na HDFS.
Pro zvyseni vykonu je lepsi pouzit pro servyrovani tech souboru apache, ktery se je bude brat jako staticky obsah primo z toho filesystemu a tento pripadne doplnit o mod_cache.
Duvod proc nemit data v DB je treba i doba exportu dane DB, vyssi cena storage za DB apod.
Jeste pozor na performance jednotlivych FS, zejmena kdyz date do jednoho adresare hodne souboru, nektere maji seznam souboru jako linked list (pomale) a jine zase maji ruzna omezeni na maximalni pocet.
Lukas
On 9 Apr 2012 00:11, Libor Jelinek <[email protected]> wrote:
Není to odpověď, ale jednou jsem narazil na tuto analýzu porovnávající ukládání na NTFS v. BLOB v SQL Serveru - http://research.microsoft.com/pubs/64525/tr-2006-45.pdf. Závěr je, že to 256 kB je BLOB rychlejší, než filesystem. Nevím, jak by to mohlo být u PgSQL...
Jinak, když dojdete k nějakým závěrům, tak se podělte. Sám potřebuji výhledově v této oblasti udělat "průzkum a rozhodnutí" :-)
Libor
2012/4/8 Ivan Polak <[email protected]>
zdravim konferenciu,
potrebujem vo web aplikacii (tomcat+java+postgreSQL) ukladat tisicky
obrazkov, ktore uploaduju klienti (pocita sa hlavne s velkym poctom
ich zobrazovani - aj ako thumbnail, aj plna velkost).
rozhodol som sa, ze to budem ukladat na disk a nie do DB (ako blob).
do DB pojdu len meta-data (typ obrazku, cesta k nemu na disku,
velkost, komu patri, atd).
zvazujem ale pouzitie nejakeho riesenia, ako napr. hadoop
(http://hadoop.apache.org/), uz som ho raz pouzil, ale tam bolo
zobrazovanie-nacotanie vo velmi malej miere, klient ulozil subor,
zopar-krat editoval, a potom sa uz nikto niekdy k tomu suboru
ulozenemu v hadoop nevracal, v tejto mojej aplikacii musim pocitat
hlavne s tym nacitavanim-zobrazovanim (teda nacitanie musi byt velmi
rychle + pripadne pouzit nejaku cachce - ehcache alebo Memcached).
prosim, ma niekto skusenosti s riesenim taketho problemu.
dakujem
Ivan
