Taky řešíme podobnou úlohu, ale zatím je to ve fázi prvních úvah. Každopádně zatím mám poznamenáno, že
- asi nepoužívat Apache ale Nginx, nebo http://www.lighttpd.net/ na poskytování těch souborů, mělo by to být rychlejší, pokud máte velký počet klientů, používá to asynchronní IO a nežere to tolik paměti, apod. - myslet na možnost případného rozdělení domén img01.domain.eu, img02.domain.eu, img03.domain.eu - soubory se pak stahují paralelně do stránky - pokud tam má být nějaká autorizace přístupu k obrázku, tak použít něco jako http://code.google.com/p/mod-auth-token/ - co se týče filesystému - tak navrhovaný HDFS je nevhodný - pokud ho hodláte používat opravdu přímo jako filesystem. Cituji z dokumentace "Applications that run on HDFS need streaming access to their data sets. They are not general purpose applications that typically run on general purpose file systems. HDFS is designed more for batch processing rather than interactive use by users." "Applications that run on HDFS have large data sets. *A typical file in HDFS is gigabytes to terabytes in size*. Thus, HDFS is tuned to support large files." - tedy na obrázky absolutně nevhodná záležitost. Navíc integrace do OS (pokud byste chtěl, aby Váš WebServer poskytoval soubory přímo) bývá přes FUSE adapter, který volá ten HDFS realizovaný nad Javou - to už na první pohled asi nevěští ideální řešení z pohledu výkonu. Něco jiného je, pokud byste nad tím vybudoval svoje úložiště - ve smyslu, že pospojujete hromadu souborů dohromady a ty pak uložíte do HDFS. Něco jako Haystack co má Facebook - http://www.niallkennedy.com/blog/2009/04/facebook-haystack.html .A nebo rovnou použijete nějakou "NO-SQL" - lépe asi říkat "NO-RDBMS" databázi, jako je HBASE, Cassandra, Mongo, .... A nebo použít nějaké filesystémy jako http://cs.wikipedia.org/wiki/Global_File_System , http://www.moosefs.org/, http://ceph.newdream.net/, http://wiki.lustre.org, ale pro relativně malé řešení si dovedu představit, že se použije NFS. A nebo prostě jen použít S3 od Amazonu společně s http://aws.amazon.com/cloudfront/. Možností je spousta, záleží jen na Vašich požadavcích (škálování, správa, dostupnost, zabezpečení, latence, rychlost, odkud jsou vaši uživatelé, apod.), termínu a rozpočtu :) Protože pro jednodušší řešení bych udělal nějaký jednoduchý sharding - každému obrázku vygenerovat unikátní ID - tím ho propojit s těmi metadaty ve vaší databázi. ID pak rozdělit po skupinách a tím ho namapovat na nějakou adresářovou strukturu třeba fotka.jpg => 162456873109.jpg => /1624/4568/162456873109.jpg - tím zajistit rozkládání uložení souborů na různé servery, nebo jen disky a nebo prostě jen zajistit, že nemáte v 1 adresáři příliš mnoho souborů - moderní filesystémy sice většinou už problém nemají, u ext2 jsme třeba narazili na limit 10 000 souborů v adresáři, pak se filesystém strašně zpomalil. Ale i u ext3 a jiných můžete mít problém s administrací - třeba vylistování adresáře, nebo použití FTP nebo nějaké backupy adresáře s milionem souborů, to může být problém, proto raději provádím vždy sharding. Na druhou stranu - příliš velká hloubka adresářů taky není ideální, čím míň adresářů, tím líp :). Dne 9. dubna 2012 7:09 Lukas Barton <[email protected]> napsal(a): > Vyhoda HDFS je, ze ho muzete geograficky distribuovat a v dane lokalite > mit jenom nejakou lehkou proxy, ktera jen presmeruje request na lokalni > HDFS cluster. > > 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 >> > >
