DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)
-   -   Optimizacija baze - da li odvajati u novu tabelu? (http://www.devprotalk.com/showthread.php?t=9454)

Igor Manjenčić 14. 12. 2010. 00:04
Optimizacija baze - da li odvajati u novu tabelu?
 
Oduvek me je interesovala optimizacija baze podataka i stalno slušam svakakve "cake" za poboljšanje performansi.

Da li je skuplja operacija pronalaženja tabele (u moru tabela) i izvršavanje jednostavnog upita nad manjom tabelom (sa manje unosa i manje polja) ili izvršiti jedan upit nad većom tabelom? Da li je uopšte skupa operacija pronalaženja same tabele u ogormnoj bazi.

Drugo pitanje, na koji način biste realizovali sistem notifikacija (kao fb recimo) gde imamo nekoliko hiljada korisnika online koji na 1 sekund izvršavaju upit nad tom tabelom (ili tabelama)? A opet potrebno je u tu tabelu često ubacivati. Ok, ta tabela (ako je jedna) ne bi imala više od 3 polja i ne bi imala mnogo unosa jer bi se stariji arhivirali u drugu tabelu koja bi se zvala tek po potrebi. Da li je to jedino što se može učiniti. Šta predlažete?

Treće pitanje je vezano za chat sistem i kako optimizovati taj deo baze. I ako možete da se ograničite samo na mySQL :)
Hvala

misk0 14. 12. 2010. 00:15
Ne postoji 'silver bullet' koji rjesava sve probleme tj 'najoptimalnija varijanta za sve'. Uvijek je rijesenje zavisno od konkretne situacije tako da bi bilo bolje da dodjes sa konkretnim tabelama, upitima, upisima, frekvencijom i slicno pa ti se onda moze i pomoci.

Facebook mislim da koristi Cassandra-u tj noSQL bazu podataka gdje su pravila drugacija.

dinke 14. 12. 2010. 00:15
Citat:
Originalno napisao Igor Manjenčić (Napišite 92854)
Oduvek me je interesovala optimizacija baze podataka i stalno slušam svakakve "cake" za poboljšanje performansi.

Da li je skuplja operacija pronalaženja tabele (u moru tabela) i izvršavanje jednostavnog upita nad manjom tabelom (sa manje unosa i manje polja) ili izvršiti jedan upit nad većom tabelom? Da li je uopšte skupa operacija pronalaženja same tabele u ogormnoj bazi.
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) :)

Dakle, onako kako bih ja resio pomenuti problem:

1) Prvo pogledas sadrzaj tih tabela, da li sva polja koja pretrazujes moraju biti tu? Da li su tipovi polja optimizovani u odnosu na sadrzaj tabele? Npr ako za neko checked 0/1 koristis int, to znaci da trosis 3 bajta po polju vise nego sto treba, pa puta milion slogova = 3MBajt ... veca tabela = sporija tabela
2) Koristi fiksne tipove kada je to moguce, npr za smestanje ip adresa bolje je koristiti char nego varchar polje (brze je). Not null bi trebao biti brzi od Null polja itd.

3) Koristi indexe i explain za optimizaciju istih :)

4) Ako imas puno upisa/citanja istovremeno predji na innodb, u nasem slucaju pokazao se mnogo bolje od myisam (low level locking)

5) Bolji hardware

Citat:
Originalno napisao Igor Manjenčić (Napišite 92854)
Drugo pitanje, na koji način biste realizovali sistem notifikacija (kao fb recimo) gde imamo nekoliko hiljada korisnika online koji na 1 sekund izvršavaju upit nad tom tabelom (ili tabelama)? A opet potrebno je u tu tabelu često ubacivati. Ok, ta tabela (ako je jedna) ne bi imala više od 3 polja i ne bi imala mnogo unosa jer bi se stariji arhivirali u drugu tabelu koja bi se zvala tek po potrebi. Da li je to jedino što se može učiniti. Šta predlažete?

Treće pitanje je vezano za chat sistem i kako optimizovati taj deo baze. I ako možete da se ograničite samo na mySQL :)
Hvala
Memcache?

misk0 14. 12. 2010. 00:25
Citat:
Originalno napisao dinke (Napišite 92856)
2) Koristi fiksne tipove kada je to moguce, npr za smestanje ip adresa bolje je koristiti char nego varchar polje (brze je). Not null bi trebao biti brzi od Null polja itd.
Za IP adrese kazu da je najbolje koristiti - INT i ugradjene INET_ATON i INET_NTOA funkcije.

Kôd:
mysql> SELECT INET_ATON('192.168.10.50');
  +----------------------------+
  | INET_ATON('192.168.10.50') |
  +----------------------------+
  |                3232238130 |
  +----------------------------+
  1 row in set (0.00 sec)

  mysql> SELECT INET_NTOA(839559360);
  +----------------------+
  | INET_NTOA(839559360) |
  +----------------------+
  | 50.10.168.192        |
  +----------------------+
  1 row in set (0.00 sec)

dinke 14. 12. 2010. 00:39
Kazu :) I kako onda dobijes jedan pool? Npr :

Kôd:
select whatever where ip like '192.168.%';
Ovo gore ce kao suffix search koristiti index, da vidim da to urdi neka f-ja :) I inace (kada je optimizacija u pitanju) uvek je bolje koristiti fixed pretragu nego f-ju, npr:

PHP kôd:
$current_date = date("Y-m-d");
$db->query("select whatever from foo_table where date_field = '$current_date' "); 
ce biti brze nego :

Kôd:
select whatever from foo_table where date_field = current_date();

MorenoArdohain 14. 12. 2010. 00:40
Ako imas mogucnosti da furas nesto drugo osim MySql, istrazi non-relational baze tipa MongoDB, Cassandra ili Redis (key-value dbs).. Imas boljih resenja koje po performansama tuku MySQL nekoliko desetina puta (procackaj benchmark testove na netu). Jedina caka je sto ce ti trebati vise vremena da udjes u stos, pogotovu ako si dosad radio samo sa relational bazama.

misk0 14. 12. 2010. 00:50
Citat:
I inace (kada je optimizacija u pitanju) uvek je bolje koristiti fixed pretragu nego f-ju,
Ovo ne znam za mySQL ali kad sam citao Oracle literaturu rekli su da se vrijednost fixira na pocetku upita i da nece tokom svake iteracije ponovo da poziva funkciju i izracunava vrijednost.

dinke 14. 12. 2010. 00:53
^ http://net.tutsplus.com/tutorials/ot...est-practices/

dinke 14. 12. 2010. 00:55
@MorenoArdohain
Dobro bre pusti coveka da prvo nauci MySQL, nemoj odmah te razne Kasandre, Ljovisne, Madres egoistas ...

MorenoArdohain 14. 12. 2010. 00:56
Dzabe uci MySQL ako nece moci da mu izgura zahteve :)

Igor Manjenčić 14. 12. 2010. 01:02
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 14. 12. 2010. 01:04
Citat:
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 14. 12. 2010. 01:06
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ć 14. 12. 2010. 01:13
Citat:
Originalno napisao MorenoArdohain (Napišite 92871)
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 14. 12. 2010. 01:15
Generalno svi shared hostinzi imaju boljku sa MySQL-om.

vidak 14. 12. 2010. 01:25
ovde sam postavio uputstvo kako da napraviš notifikacije kao na Facebook-u i da do milje volje dodaješ novih notifikacionih opcija.

ivanhoe 14. 12. 2010. 15:37
Citat:
Originalno napisao dinke (Napišite 92856)
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 14. 12. 2010. 15:45
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 14. 12. 2010. 16:48
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 14. 12. 2010. 16:53
Opšte rešenje je da se počne školski, sa normalizovanim podacima, pa se deli, duplicira i šarduje kad za to nastane potreba.

bluesman 14. 12. 2010. 17:06
Opšte rešenje je da se sedne pre nego što se počne pa se odluči šta će da bude normalizovano a šta denormalizovano ... pa se menja usput samo ako vidiš da postoji bolje rešenje a ne da počneš sa nečim što znaš da ćeš menjati "kada nastane potreba" ;)

Dejan Topalovic 12. 01. 2011. 23:27
Pozdrav svima nakon duzeg vremena :)

@Igor: koliko sam shvatio tvoje potrebe, ti jos nemas tacno definisan koncept tvoje aplikacije - dakle moras koristiti agilne metode pri razvoju te aplikacije, sto samo po sebi iskljucuje donosenje odluke o konacnom izgledu/dizajnu/strukturi aplikacije i baze.
Kao sto rece neko (misk0 cini mi se) - ne postoji "silver bullet" rjesenje, nego ces morati zagrijati stolicu, te metodom "trial & error" (odnosno "generate & test" iliti "guess & check") doci do najoptimalnijeg rjesenja.

Evo ti par usputnih savjeta onako iz rukava:
- gledaj da ti broj tabela ne predje broj korisnika ;) , znaci tabele kreiraj svrsishodno i ne razbacuj se
- rasporedi tabele u vise grupa i imenuj ih sa odgovarajucim prefixom (chat_*, user_*, i td.), radi lakseg pregleda
- ako mozes, koristi particije - npr. particioniras tabelu sa korisnicima po pocetnom slovu imena/prezimena ili po godini rodjenja; particioniras tabelu sa chat porukama po datumu (Oracle ima i mogucnost kompozitnog particionisanja, pa mozes prvo particionisati po datumu i onda subparticionisati po korisnickom ID-u, tj. "Range-Hash composite partitioning" ili drugacije, zavisi o konceptu tvoje aplikacije); ne znam kakvo je stanje sa MySQL-om po pitanju particionisanja, jer sam totalno zapostavio MySQL zadnjih godina :(
- koristi indexe kada ti je "selectivity" za zadane kolone veoma visok
- koristi full table scan, kada imas neku batch job operaciju, koja obradjuje veliki broj redova u zadanim tabelama
- koristi uskladistene procedure
itd.

Eto nabrzaka nesto, cisto da se vratim u forumsku formu. ;)


Vreme je GMT +2. Trenutno vreme je 18:01.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.