Clustering, databaze a sdileni dat

Jan Kasprzak kas na informatics.muni.cz
Pondělí Prosinec 13 16:22:21 CET 1999


Michal Krause wrote:
: Premyslim docela vazne o nejake paralelizaci Navrcholu, protoze jeden
: stroj zvolan prestava stihat a uz neni kam zvedat vykon (vyjma SMP, u
: ktereho mi ale vadi, ze za nejaky cas zase nebude co zlepsit, v tomto
: ohledu mi pripada clustering pruznejsi).
:
: Celkem nevidim zasadni problemy s implementaci, alespon teoreticky se v
: problematice orientuju, ale porad mi lezi v hlave dve zalezitost. A to
: je pouziti SQL serveru a pripadne sdileni jistych dat mezi uzly.
: 
: Jde o to, ze MySQL spolu s demonem realizujicim vlastni pocitani jsou
: to, co se v systemu nejvic namaka. Presunuti SQL serveru na vlastni
: stroj je pouze momentalni reseni, ktere opet narazi za par mesicu na
: svuj strop, nehlede na to, ze spojeni po TCP/IP bude mozna i pomalejsi
: nez pres unix socketu (to je jenom moje domnenka). Zkratka i praci SQL
: serveru by bylo vhodne rozdistribuovat na vice stroju.
: 
: Jenze to by bud znamenalo distribuovat pozadavky na vyssich urovnich,
: nez je sitovani (konkretne podle ID, jehoz se hit tyka) a to se mi
: nelibi. Jednak to asi bude mene vykonne, oproti pouziti treba Beowulfa a
: jednak to nezajistuje optimalni rozlozeni pozadavku (protoze par
: nejnavstevovanejsich stranek dela skoro 30% trafficu).
: 
: Pokud bych ale rozlozil requesty klasicky na urovni TCP/IP, vyvstavaji
: dalsi problemy, konkretne to, ze demon pracuje s jistymi daty (jakousi
: pametovou cachi), ktera se dynamicky v prubehu casu meni. Do tehle cache
: je potreba mit maximalne rychly pristup (momentalne to resim pres hash)
: a hlavne by musela v ramci clusteru existovat jenom jedna, sdilena. A
: jak tohle resit, to me momentalne nenapada vubec.

	Ja teda presne nevim, co Navrcholu dela, jen mam mlhavou predstavu,
ze pocita pristupy na nejake www stranky. Asi by to chtelo blizsi informace
o implementaci (napriklad, jestli se kazdy hit uklada do databaze a pak
se to nekde sumarizuje, jestli v dalsim procesu je potreba pristupovat
i k jednotlivym hitum oddelene nebo se pak pristupuje jen k sumarnim
informacim pro jedno id, a podobne). Pokud totiz neni potreba vedet,
ze tehdy a tehdy kliknul ten a ten, ale jen "v prubehu dne z tehle
IP adresy na toto ID pristupovali XYZ-krat", pak bych ten prvni krok
(http server -> sumarizacni demon) vubec nehonil pres databazi, ale
treba pres soubor s O_APPEND, ktery by se jednou za cas zrotoval
a zesumarizoval.

	Ale jak rikam, mozna jsem uplne mimo a ta aplikace potrebuje
jeste neco uplne jineho.

-Yenya

-- 
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
/// I'd much prefer a sane architecture that doesn't continually try to  \\\
//  reinvent the bad idea of memory windows.   -Linus on Xeon 36-bit MM   \\


Další informace o konferenci Linux