- HDFS bych urcite nepouzil, to je delane na jiny typ tasku (davkove zpracovani velkeho poctu dat), navic pokud s tim nemate zkusenosti, tak je hosting a provoz takovehle technologie celkem drahy spas - NoSQL mi nedava smysl pokud u tech obrazku nepotrebujete drzet nejaka metadata.
Osobne bych byt vami sahnul po te S3, ktera byla jiz zminena. Nemusite resit zadny load balancing, failover, hostovani, geograficke rozlozeni. To vsechno uz udelal nekdo za vas, navic nekdo kdo s tim ma zkusenosti a umi to. 2012/4/10 kek forums <[email protected]>: > 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 >> >> > -- S pozdravem Roman "Dagi" Pichlik /* http://dagblog.cz/ Blog pro kodery */
