Clustering, databaze a sdileni dat

[Michal Krause]

On 12/13/99 19:52, stano na trillian.eunet.sk wrote:
> On 13 Dec 1999 16:30:04 +0100, Michal Krause wrote:
> 
> : od modulu pro Apache), v zavislosti na tech datech se bud sahne do te
> : cache, ktera muze byt delena, paklize bude zajisteno, ze hit pro jeden
> : identifikator bude chodit vzdy na stejny stroj. Paklize je toto pravidlo
> : dodrzene, pak zaroven lze delit i databazi na vice stroju.
> 
> No, to uz je vynikajuca informacia. Inymi slovami data
> pre rozlicne id sa nijako "nemiesaju" a pokial
> to dovediem do extremu, mohlo by mat kazde
> id dedikovany pocitac :-)

Jo, ale to az pristi rok. Zatim by stacilo pouzit dva nebo tri compy :)
Jenom jestli nam provider umozni umistit k nemu 10000 stroju :)
A vubec, to bychom asi vyhrali Top500 Supercomputing Sites (www.top500.org)
 
> Vseobecnu architekturu by som potom videl dvojstupnovo:
> 
> Prva vrstva su "rozdelovace", ktore su bezstavove
> a akurat spravia nejaky hash z id a podla vysledku
> posunu request na urceny pocitac. Snad by som aj
> zahodil Apache a urobil jednouceloveho demona
> (niekto musi aj zase efektivne dorucit odpovede
> nazad), ale do tejto oblasti nevidim.

Je fakt, ze vlastni daemon by mel jednu vyhodu. Po odeslani odpovedi
(ktera je konstatni) by mohl odstrihnout spojeni a pockat, az data
prevezme uzel. To zadny HTTP server, ktery znam, neumi a zbytecne drzi
spojeni, dokud neni request ukoncen.
 
> Druha vrstva su potom stroje so samostatnymi SQL servermi
> a samostatnou cache, pricom obsluhuju konkretnu mnozinu id.
> 
> Tym padom sa da riesit rozlozenie zataze tak na urovni
> prichadzajucich pristupov (podla IP klienta - prva vrstva),
> ako aj na urovni SQL backendu (podla id).

Ted nerozumim. Jak podle IP adresy? Vsechny pristupy pro jedno ID se
museji kvuli te cachi zkoncit na jednom "delnikovi". Nebo myslis neco
jako


                 +--- ID1 (by ID) ---+  +-- Worker1 (SQL)
		         |                   |  |
Beowulf (by IP) -+--- ID2 (by ID) ------+
                 |                 +-|----- Worker2 (SQL)
                 |                 | |
          		 +--- ID3 (by ID) -+ +----- Worker3 (SQL)


Brr, to je zmatek, ale snad je to pochopitelne?
 
> Uzke hrdlo nema kde vzniknut - rozsirovat sa da tak
> prva vrstva, ako aj druha a pokial by nestihala
> siet medzi nimi (co by som dost pochyboval :-)),
> da sa znasobit aj ta.

To by asi nebylo nutne :)
Kdyz uz jsme u toho, jak bu to vlasnte slo (pominu-li drahy a
neefektivni gigabit)? Jedine snad nejakym load balancingem na dvou
100mbit kartach. Vic stejne PCI nezvladne, ze?
 
> Pridanie stroja ovsem nie je trivialne (pokial chvilkova
> odstavka nie je mozna) - viac-menej treba prehashovat
> tie data medzi backendami. Bohuzial neviem, o ake mnozstva
> sa jedna a co je mozne pocas takejto administrativnej
> akcie tolerovat.

Jednak jde o relativne male mnozstvi ID - priblizne 10000 a vygenerovani
hashe by asi slo udelat treba s pomoci dat za uplynuly den tak, aby se
optimalne rozlozilo vytizeni. To by nezabralo vic, nez par vterin.
Koneckoncu ta hash by se musela stejne generovat bud prubezne a nebo
periodicky znovu a znovu, protoze ID pribyvaji...

> V zaciatkoch samozrejme moze prva vrstva zdegenerovat
> na jeden stroj.

S tim pocitam.
 
> Prehliadol som nieco?

Zda se, ze nikoliv.
 
> Mimochodom, 4 mil. query denne, z toho polovica zapisov,
> na jednoprocesorovej masine s jednym SQL serverom,
> to teda klobuk dolu...

..pred MySQL. Ja rikam porad, ze ma az neuveritelne rychly engine.
Ono uz to dokonce vice nez 4 miliony, protoze za posledni necele ctyri
dny, kde byly dva dny vikendove, je prumer 3,85 milionu. Ted, v
relativne pozdni hodine, je aktulni stav 70 query za vterinu. Takze si
jiste umis predstavit ten mejdan v denni spicce :)

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.