Optimizacija baze - da li odvajati u novu tabelu?

[Igor Manjenčić]

Hmm... znam da bi neko noSQL rešenje bilo bolje. Iskreno nisam to nikad radio i ne znam ni kako se instalira. Opet, projekat bi bio na nekom shared hostingu (u pocetku). Koliko je komplikovana instalacija takve baze i da li je to uopšte moguće na shared hostingu?

@dinke
Hmm, notifikacija bi trebalo da stoji i do 2 dana zapamćena. Jesi siguran da bi Memcache bilo dobro rešenje?

EDIT: ma nije meni problem da naučim Kasandru, brzo bih ja ušao u štos, nego da se ne zalećem bezveze ako mi neće rešiti problem.

[misk0]

This applies to all non-deterministic functions like NOW() and RAND() etc… Since the return result of the function can change

good to know... thx dinke.

[MorenoArdohain]

Ako vec planiras da vrtis aplikaciju koja treba da izgura nekoliko hiljada korisnika istovremeno kao sto si pomenuo u prvom postu, naravno da neces koristiti shared hosting

[Igor Manjenčić]

Originalno napisao MorenoArdohain

Ako vec planiras da vrtis aplikaciju koja treba da izgura nekoliko hiljada korisnika istovremeno kao sto si pomenuo u prvom postu, naravno da neces koristiti shared hosting

Da ali u početku će biti istovremeno 100 korisnika online . Neću da bacam pare na dedicated a opet voleo bih da znam šta me čeka ako sistem poraste i u ovom trenutku već da razmišljam o optimizaciji. Mislim, ovo je jedno od onih večitih pitanja..

[MorenoArdohain]

Generalno svi shared hostinzi imaju boljku sa MySQL-om.

[vidak]

ovde sam postavio uputstvo kako da napraviš notifikacije kao na Facebook-u i da do milje volje dodaješ novih notifikacionih opcija.

[ivanhoe]

Originalno napisao dinke

Mislim da bi kreiranje gomile malih tabelica koje na ne znam koji nacin nalazis pa vrsis upite nad njima bio totalno pogresan nacin, svojsvten onima koji slabo poznaju rdbms sisteme (mada ko zna mozda sam ja u krivu)

Zavisi od nacina upotrebe, gomila tabela je ok dok god ih je dovoljno malo da mysql moze sve da ih otvori, i drzi otvorene. Cim preraste taj broj, pa krene da ih stalno otvara i zatvara (jer ne mogu sve da budu otvorene istovremeno) nastane uzasno usporenje.

To naravno zavisi od toga kako se te tabele koriste, ako je samo mali podskup postojecih tabela u stalnoj upotrebi, recimo za nekakvu log arhivu, gde se radi na poslednjem logu, a ostali se cuvaju za svaki slucaj, to je dobro resenje. Isto i za slucaj shardinga, jer tad svaki server otvara samo jednu od shardovanih tabela, cak iako postoje kopije svih postojecih (ako se ide na takvo resenje da se tabele razlicito zovu)

Ako imas uniformniji pristup tabelama, onda je frka. Svojevremeno sam imao taj problem sa WPMU, jer on pravi zaseban set od 10-tak tabela za svaki blog, sto je ok radilo do negde 3000 blogova, a onda je krenulo da naglo puca, jer su ljudi posecivali blogove random redom i mysql je svo vreme trosio na otvaranje i zatvaranje tabela i ucitavanje i brisanje keseva, i trebalo mu je po par sekundi za request. Tacna cifra posle koje krenu problemi zavisi od servera, memorije, kolicine podataka, broja requesta, itd..

[webarto]

Ja sam gurao MyBB forum sa peak 1000 korisnika istovremeno, na home made serveru ( 2ghz dualcore + 4gb ram) i load je bio 1-2%. Isti taj forum je blokirao čitav server na hostmonster i hostgator pa su suspendirali account, paket je bio unlimited i to.
Tako da ako ne planiraš nešto x puta veće ne brini toliko o optimizaciji.

[bluesman]

Svako će da ima svoj savet, ali generalno sve zavisi od strukture baze, upita i nekih druguh stvari ... nekada je bolje sve držati u 1 tabeli, nekada i nemaš izbora jer je alternativa ipak sporija a često je efikasnije da se razbije u nekoliko manjih tabela. Ne postoji OPŠTE REŠENJE koje je primenjivo svuda i u svakoj situaciji.

[jablan]

Opšte rešenje je da se počne školski, sa normalizovanim podacima, pa se deli, duplicira i šarduje kad za to nastane potreba.