Clustering, databaze a sdileni dat

[stano na trillian.eunet.sk]

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?

Samostatna masina pre SQL so spustou pamati, viacerymi
diskovymi radicmi a databazou vhodne "rozprestrenou"
po diskoch dokaze urobit divy.

: 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?

: 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 potrebuje pristup do tejto cache? Da sa vopred
povedat, ci dany request tu cache bude potrebovat? Pokial
by sa na strojoch duplikovala, je pripustne urcite casove
okno, v ktorom by obsah synchronny nebol (ovsem s tym,
ze pre konkretneho klienta by bol konzistentny)?

: 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...

Zdravi
-- 
				Stano