Clustering, databaze a sdileni dat

[radim.kubacki na rtscs.cz]

> > >jsem (pro zmenu) zase trosku OT, ale nemam se kde jinde zeptat.
> > >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).
> > 
> > Podle meho nazoru je v tomto pripade metoda hrube hardwarove sily
> > nejlepsi reseni.
> 
>  Nepouzivaji tuto metodu u M$? Neni zajimavejsi najit slaba mista, pokusit
> se o zlepseni a az uz to nepujde dal, tak sahnout na HW? Casto se da
> optimalizaji (casto jen nekolik malo radek kodu) udelat mnoho, nedavno
> jsem
> psal neco do PgSQL, udelal jsem to tak jak by se ocekavalo. No a pak jsem
> to
> zacal optimalizovat a v soucasne dobe je ta funkce o 50% rychlejsi a
> stacilo
> opravdu malo (jen se zamyslet:-) - a to jsem take na zacatku mohl rict
> "dejte
> si tam dalsi CPU..."
> 
Ja myslim, ze uz se to probiralo. Kazde reseni ma pro i proti. Prepokladam,
ze jednoducha vylepseni uz MK vycerpal (vic pameti, disky, ruzna
optimalizacni vylepseni kodu apod., proste se asi uz parkrat zamyslel  :-) )
a dospel k nazoru, ze je treba neco zasadnejsiho. Je otazka kolik ten lepsi
HW stoji, jake zlepseni prinese a kdy to opet narazi na strop a co bude moct
v tu chvili delat. A to same se tyka SW reseni. 
Rict, ze na HW sahnem az kdyz uz to nepujde softwarem, je podle spatne.
Jasne, ze to je docasne reseni v pripade ze ty naroky _porad_ rostou ale ten
strop dany HW se taky porad posouva.

> Jde o to, ze trva-li neco 0.005 vterin tak po vynasobeni nekolika
> milionama
> dostanete cas "na svacimu".. Todle je problem vsech cyklickych operaci.
> Trva-li v SQL neco 0.0001 vteriny na jeden radek tak pri dotazu na
> poradnou
> tabulku to muze byt nekolik vterin...
> 
Ladit db aplikace je trochu magie ;-) a da se dosahnout opravdu hodne (treba
radova zlepseni) ale furt to na nejake meze.

Radim