|
SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka |
|
Alati teme | Način prikaza |
|
14. 12. 2010. | #1 |
Knowledge base
Wrote a book
Datum učlanjenja: 16.06.2005
Lokacija: Novi Sad
Poruke: 1.437
Hvala: 37
131 "Hvala" u 82 poruka
|
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
__________________
Năo quero mais seguir um só caminho |
14. 12. 2010. | #2 | |
Ivan Dilber
Sir Write-a-Lot
|
Citat:
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..
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
14. 12. 2010. | #4 |
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
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. |
14. 12. 2010. | #5 |
Goran Pilipović
Sir Write-a-Lot
|
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.
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman I don't always know what I'm talking about but I know I'm right! |
14. 12. 2010. | #6 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Opšte rešenje je da se počne školski, sa normalizovanim podacima, pa se deli, duplicira i šarduje kad za to nastane potreba.
__________________
blog |
"Hvala" jablan za poruku: |
14. 12. 2010. | #7 |
Goran Pilipović
Sir Write-a-Lot
|
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"
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman I don't always know what I'm talking about but I know I'm right! |
12. 01. 2011. | #8 |
old school
Professional
|
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.
__________________
Blog: Baze podataka ------------------------ Oracle OCP DBA Oracle OCE SQL Expert Oracle OCP Developer Certified MySQL DBA |
"Hvala" Dejan Topalovic za poruku: |
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
Gde i kako smo docekali Novu? | 3banchi | Opušteno | 8 | 02. 01. 2010. 00:11 |
Šta bi sa forumom za novu godinu? | mangia | Obaveštenja, predlozi i pitanja | 61 | 21. 01. 2009. 15:38 |
javascript - kretanje kroz tabelu | bodi dilber | Sva početnička pitanja | 7 | 27. 08. 2008. 09:45 |
princip unosa u tabelu | [nq] | SQL baze podataka - Sponzor: Baze-Podataka.net | 10 | 06. 03. 2007. 13:09 |
Problem sa upisom u tabelu | bokey | SQL baze podataka - Sponzor: Baze-Podataka.net | 6 | 12. 09. 2006. 13:44 |