Clustering, databaze a sdileni dat

[Michal Krause]

On 12/12/99 20:16, stano na trillian.eunet.sk wrote:
> On 12 Dec 1999 18:42:48 +0100, 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).
> 
> Zasadna otazka: nestihat moze vela veci - CPU, pamat, disky.
> Je stopercentne iste, co je problemom v tomto pripade?

Stoprocentni jistotu nemam, ale ted zrovna je nejspis na vine nejvetsi
merou disk. Jenze zkusenosti za tu dobu, co to provozujeme, uz rikaji,
ze ted je to disk, za mesic to bude CPU a za dalsi dva nebude stacit
pamet. Zkratka ted hledam neco, co do budoucna problem vyresi opravdu
efektivne, zejmena s prihlednutim k tomu, ze platforma Intel ma rekneme
jisty, relativne nizky, strop moznosti.
 
> Samostatna masina pre SQL so spustou pamati, viacerymi
> diskovymi radicmi a databazou vhodne "rozprestrenou"
> po diskoch dokaze urobit divy.

Otazka je, jak dlouho to vydrzi? Problem je, ze na neco lepsiho nez
Intel zkratka nejsou penize.

> : Jde o to, ze MySQL spolu s demonem realizujicim vlastni pocitani jsou
> : to, co se v systemu nejvic namaka.
> 
> Ake je rozlozenie potrebneho vykonu medzi zapisy a citania?

Pul na pul, z celkoveho poctu vice nez 4 milionu query denne.

> : 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.
> 
> Co ta cache obsahuje je zrejme tajomstvom... Kolko percent pristupov

Neni, jenom se mi to nechtelo rozvadet. Jde o ty pristupy, ktere
neposlaly cookie, takze lze pozdeji pri dalsim pristupu ze stejne IP
adresy v urcite casove periode online zjistit, zda jde o prvni nebo
opakovanou navstevu te ci one stranky.

> potrebuje pristup do tejto cache? Da sa vopred povedat, ci dany

Zhruba tak mezi 10 a 20 procenty.

> request tu cache bude potrebovat? Pokial by sa na strojoch

Ano, lze to zjistit.

> duplikovala, je pripustne urcite casove okno, v ktorom by obsah
> synchronny nebol (ovsem s tym, ze pre konkretneho klienta by bol
> konzistentny)?

Ne, to nepripada v uvahu.

> : Nakonec se mi pri psani tohoto mailu zacina zdat, ze jde o aplikaci,
> : jejiz paralelizace nebude vubec jednoducha.
> 
> To u aplikacii vyzadujucich zdielane data nie je nikdy :-( Vacsie
> firmy vedia, preco este vsetky mainframes nie su na smetisku a
> nahradene poprepajanymi PC-ckami...

No, mainframe si na to asi nekoupime :)

S pozdravem
--
Michal Krause                                                      /\
ICQ: 7665279            Informace (nejenom) ze sveta Linuxu     /\/  \
email: mike na navrcholu.cz ______ http://www.root.cz/ ______ NAVRCHOLU.cz

Co napsat do signatury, aby to nikoho nepohorsilo? Snad jedine nejakou
obecne znamou pravdu. Doufam, ze vsichni vite, ze tucnak je bylozrava ryba.