[ bokini @ 19.04.2004. 15:05 ] @
Pozdrav,

Pravimo sajt koji ce raditi sa korisnicima (nesto kao mail client, ali dosta drugacije) i bice zasnovan na MySQL-u. (MySQL je jedino resenje za sada)

Posto smo do sada pravili samo manje sisteme, zeleo bih da postavim par pitanja:

posto ce svaki korisnik imati listu uplata i listu "trosenja" zanima me kako je NAJBOLJE organizovati tabele da bi se dobile najbolje performanse.

a) Da li da imamo po jednu veeeeliku tabelu za sva placanja svakog usera, u kojoj ce postojati polje user_id po kome ce se identifikovati user te uplate/trosenja. (vrlo lako je moguce je da tabela ima i preko 1 000 000 slogova!)

b) Ili da svaki user ima svoju tabelu: placanja_1, placanja_2, placanja_3....placanja_n (dakle, ako imamo 1000 usera, da imamo 1000 tabela). Znam da ovo nije bas elegantno, ali ako radi brze nego prvo resenje uzecemo njega.

Dakle, jos jednom naponena da ce sistem raditi preko web sajta (strani hosting) i da su nam performanse vrlo vazne.

Isto me JAKO zanimaju situacije kada vise korisnika od jednom dodje na sajt i salje zahteve MySQL-u (INSERT, SELECT), i koje resenje ce se tada pokazati kao bolje.

Ako neko poseduje veliko iskustvo u ovakvih sistemima, molio bih za bilo kakav savet

Pozdrav i hvala

[ madamov @ 19.04.2004. 15:29 ] @
Citat:
bokini:a) Da li da imamo po jednu veeeeliku tabelu za sva placanja svakog usera, u kojoj ce postojati polje user_id po kome ce se identifikovati user te uplate/trosenja. (vrlo lako je moguce je da tabela ima i preko 1 000 000 slogova!)

b) Ili da svaki user ima svoju tabelu: placanja_1, placanja_2, placanja_3....placanja_n (dakle, ako imamo 1000 usera, da imamo 1000 tabela). Znam da ovo nije bas elegantno, ali ako radi brze nego prvo resenje uzecemo njega.


Pod b) nikako, milion slogova u tabeli ne bi trebalo da predstavlja problem ni za neke "manje" baze podataka, a kamoli za MySQL.
[ Dejan Topalovic @ 19.04.2004. 15:30 ] @
Kao prvo, ako ste u mogućnosti, koristite radije Oracle, nego MySQL. Pošto pretpostavljam da niste u takvoj mogućnosti, da vidimo onda šta se da uraditi sa MySQL-om.

1. Opcija pod a) mi se čini neprihvatljivom, jer se krši sa svim pravilima optimizacije. Što bi više tabela rasla, smanjivale bi se performanse.

2. Ni opcija b) nije baš najidealnije rješenje (ako sam te dobro shvatio), jer bi onda imao previše tabela. Kako bi vršio operacije sa tim tabelama? Morao bi negdje čuvati nazive tih tabela ili ih raditi po nekom univerzalnom ključu, npr. tabela_user1, tabela_user2 ili slično. To je malo nezgrapno za izvesti, a i ne bi dalo željene rezultate.

3. Ne znam kako si zamislio insert i update podataka pri velikom opterećenju baze, ali vrlo lako je moguće da dođe do asinhronizacije prilikom istovremenog pristupa određenim tabelama. Naravno, moguće je to uraditi i osigurati se od toga koliko toliko (sa LOCK-ovanjem npr.), ali tada dolazi do pada performansi. Ne znam detaljnu speficikaciju vašeg projekta i zahtjeve pod kojim uslovima bi čitava aplikacija trebala raditi, ali morate dobro paziti sad na početku da dobro isplanirate strukturu baze, da njen model bude fleksibilan i da normalizacija bude minimalno na trećem nivou.

Za početak, ja bih razdvojio podatke o userima i podatke o plaćanjima u odvojene tabele:
tabela_users - useri: podaci o userima, stavite neki primary key kao index, npr. user_id
tabela_placanja - plaćanja: podaci o plaćanjima pojedinih usera, takođe stavite neki primary key kao index, npr. placanja_id
tabela_lookup_users_placanja - lookup kombinacija sa user_id i placanja_id

Toliko od mene.
[ bokini @ 19.04.2004. 15:44 ] @
Hvala na odgovoru

ako ne valja ni prvo ni drugo resenje, koje da koristimo ;) ne znam ni jedno trece ;)

da li je neko od Vas vec pravio ovakve sisteme i koje resenje koristi tada. Zaista mi je potrebno misljenje nekog ko je vec imao iskustva sa time. hvala.

u slucaju a)

mi bi dakle imali sledece tabele:

tabela_korisnici (id, name, password...)
tabela_placanja (id, user_id, ammount....)

i to bi se pomocu JOIN-a lepo sastavilo. problem sa visestrukim pristupom bi nekako resili.

Zanima me samo sta vise usporava MySQL:
- visestruki pristup vise usera (INSERT, SELECT) na jednoj tabeli
- ili na vise tabela.

dakle moze da se desi i da 50 njih istovremeno pristupa tabeli/tabelama.

Znam da je MySQL ogranicen, ali u prvo vreme dok ne predjemo na nesto bolje, moramo da koristimo njega, zato bih zeleo da ga do kraja iskoristimo.

Hvala na savetima.

[ sspasic @ 19.04.2004. 15:53 ] @
Pod a). Imaj u vidu da, uz pametno kreirane indekse što se u MySQL-u može uraditi, vreme pristupa podacima u odnosu na broj slogova u tabeli (uglavnom) raste logaritamski.
Ovo pod b) izbegavaj. Mislim da je jeftinije staviti brži disk ili kompjuter nego se upuštati u ovakav hack.
[ bokini @ 19.04.2004. 16:00 ] @
Citat:
sspasic:
Pod a). Imaj u vidu da, uz pametno kreirane indekse što se u MySQL-u može uraditi, vreme pristupa podacima u odnosu na broj slogova u tabeli (uglavnom) raste logaritamski.
Ovo pod b) izbegavaj. Mislim da je jeftinije staviti brži disk ili kompjuter nego se upuštati u ovakav hack.


Dakle mislis da koristimo jednu tabelu? Da li si vec imao iskustva sa ovakvim sistemima (zaista mi je to potrebno da znam ;)) . Isto me zanima koje resenje bolje radi kada vise posetilaca sajta pristupa bazi; Hvala.
[ bluesman @ 19.04.2004. 16:37 ] @
Znas kako mozes da probas, ako imas korisnike onda oni verovatno imaju neki id. Pa lepo, napravi 10 tabela: users_0, users_1, users_2 ... users_9 i svi slogovi korisnika koji se zavrsavaju sa recimo 6 nalaze se u tablei users_6. Tako ces malo optimizovati, tabele nece biti prevelike, a opet ih nema 1000.

Dakle, naziv tabele dobijes tako sto uzimas ostatak od deljenja sa 10, recimo za ID=347 dobijes: mod = ID % 10 = 347 % 10 = 7, znaci tablela se zove users_7. To je u PHP jedan red za svaki id koji procesiras:

$table_name = "users_". (id % 10);
pa onda
$query = "SELECT ... FROM ".$table_name." ...";

Jedini problem koji moze da nastane je ako trazis neke sumarne statistike, onda moras sa UNION za svih 10 tabela, a to je dosta spora operacija.
[ bokini @ 19.04.2004. 17:01 ] @
Citat:
bluesman:
Znas kako mozes da probas, ako imas korisnike onda oni verovatno imaju neki id. Pa lepo, napravi 10 tabela: users_0, users_1, users_2 ... users_9 i svi slogovi korisnika koji se zavrsavaju sa recimo 6 nalaze se u tablei users_6. Tako ces malo optimizovati, tabele nece biti prevelike, a opet ih nema 1000.

Dakle, naziv tabele dobijes tako sto uzimas ostatak od deljenja sa 10, recimo za ID=347 dobijes: mod = ID % 10 = 347 % 10 = 7, znaci tablela se zove users_7. To je u PHP jedan red za svaki id koji procesiras:

$table_name = "users_". (id % 10);
pa onda
$query = "SELECT ... FROM ".$table_name." ...";

Jedini problem koji moze da nastane je ako trazis neke sumarne statistike, onda moras sa UNION za svih 10 tabela, a to je dosta spora operacija.


Mene vise zanimaju neka iskustva, cisto da ustedim malo vremena (tj. da li da pocnem sa intenzivnim testiranjima od vise dana i da tek onda imam neke pocetne rezultate). Sama resenja umem da implementiram.

Ako je neko ovde pravio malo veci sistem verovatno moze da mi kaze svoja iskustva, tj. koji od ova 2 metoda koristiti (jedna tablela sa svim userima | posebna tabela za svakog usera).

Ili ako je bar gledao source code nekog veceg sistema, sta se koristi tamo (neki e-shop, web mail...). Gledao sam PHBB forum (njegovu bazu) i vidim da se svi postovi cuvaju u istoj tabeli, sad me zanima kako je kod drugih.
[ broker @ 19.04.2004. 17:14 ] @
Kao sto si dobio u prvom odgovoru, radi pod a). To ti je po teoriji a i po praksi najbolje resenje. Sve ostalo je nepotrebno komplikovanje. Ako MySQL server ne bude mogao da izdrzi toliki broj slogova a trebao bi, onda:

a) napravi sistem da arhiviras zastarele slogove u sporednu tabelu a u radnoj drzis samo one slogove koji su relevantni (tj ima ih smisla tu drzati). Recimo stavi da se u radnoj tabeli drze slogovi upisani u poslednja dva mezeca a ostale cuvaj u posebnoj tabeli. Ako je bas poterbno da das izvestaj i za stariej slogove to mozes da napravis kao poseban upit koji ce da join-uje podatke iz obe tabele. Tako ces server masirati samo za taj jedan izvestaj a ostali ce raditi sa manje podataka.

b) koristi bolji server

Na Stripijev odgovor se ne osvrci, verovatno te je pogresno razumeo, tj. prevideo da si rekao da za identifikaciju korisnika imas user_id a ostalo su podaci o uplati pa nema redundanse.
[ bokini @ 19.04.2004. 17:32 ] @
Citat:
broker:
Kao sto si dobio u prvom odgovoru, radi pod a). To ti je po teoriji a i po praksi najbolje resenje. Sve ostalo je nepotrebno komplikovanje. Ako MySQL server ne bude mogao da izdrzi toliki broj slogova a trebao bi, onda:

a) napravi sistem da arhiviras zastarele slogove u sporednu tabelu a u radnoj drzis samo one slogove koji su relevantni (tj ima ih smisla tu drzati). Recimo stavi da se u radnoj tabeli drze slogovi upisani u poslednja dva mezeca a ostale cuvaj u posebnoj tabeli. Ako je bas poterbno da das izvestaj i za stariej slogove to mozes da napravis kao poseban upit koji ce da join-uje podatke iz obe tabele. Tako ces server masirati samo za taj jedan izvestaj a ostali ce raditi sa manje podataka.

b) koristi bolji server

Na Stripijev odgovor se ne osvrci, verovatno te je pogresno razumeo, tj. prevideo da si rekao da za identifikaciju korisnika imas user_id a ostalo su podaci o uplati pa nema redundanse.


Pozdrav broker: gde na internetu mogu da vidim kod nekog open-source sistema?
(PHBB forum imam na sajtu i gledao sam njegovu bazu koja radi na principu jedne tabele).
Ako nije tajna, ako neko zna da li moze da mi kaze kako EliteSecurity funkcionise, sa jednom tabelom za sve postove, ili ima po tabelu za svaku grupu, ili sl.

Hvala.
[ broker @ 19.04.2004. 17:58 ] @
Ne znam koji OS bih mogao da ti preporucim. S obzirom da izgleda da znas da modeliras baze, sve je stvar konkretne realizacije. komentari koji su ti dati ovde mi se cine sasvim svrsishodni, da se odlucis za ispravan model, a sve ostalo bi terbalo da se resava skolski, bar u meri i kojoj mogu da zamislim sistem za evidenciju naplate.

Tesko da nesto mozes prepisati od nekoga ako on koristi sistem koji ima drugaciju namenu, a opet svi se zasnivaju na teoriji i praksi koji te vode na tvoje a) resenje.

Neko bi mozda mogao da ti predlozi neko optimalnije resenje ali moras da mu pruzis vise informacija kako bi mozda mogao da iskoristi specificnosti podataka koje cuvas u bazi i moras biti spreman da to platis, posto je potrebno znanje i vreme da se to resenje napravi a i gotov model baze je po pravilu kljuc cele aplikacije.

Sto se tice phpBB baze, sticajem okolnosti sam radio sa njom i mislim da ona bas i nije primer dobro smisljenog modela.

Ako nisi siguran u resenja koja si smislio, najbolje je da ovde izneses konkretne probleme ili nedoumice posto su ljudi uvek spremni da pomognu.
[ bluesman @ 20.04.2004. 11:03 ] @
Citat:
Mene vise zanimaju neka iskustva, cisto da ustedim malo vremena...


Pa podelio sam iskustvo, ne znam sta ti je jos potrebno, ocigledno me nisi shvatio.
[ leka @ 20.04.2004. 12:23 ] @
Pokretacu ove teme predlazem toplo da ozbiljno procita ovaj clanak -
http://www.phpbuilder.com/columns/barry20000731.php3?aid=64 i da kupi neku knjigu (ili nadje na NET-u) koja se bavi dizajnom baza podataka.
[ bokini @ 20.04.2004. 21:02 ] @
Ja umem da radim sa bazama podataka i da ih dizajniram, ali ovde sam pitao za iskustva sa vecim WEB sistemima. Verujem da je svako radio na bazi koja se koristi na jednom racunaru, ili u lokalnoj mrezi, ali je retko ko pravio ozbiljniji WEB sajt koji intezivno radi sa bazom. Svi znate koliko je to pipavije i koliko je protok ograniceniji od LAN-a i localhost-a. Ja sam ovde jednostavno pitao koje je resenje prikladnije za taj WEB sistem (posto ga nisam radio do sada), a neki od vas mi pokazuju neke pocetnicke linkove. Posto prvi put krecem u tu avanturu, i cuo sam razlicite komentare , zeleo sam vas da pitam. Ja dakle vec imam neko znanje, ali ko zna, mozda su za WEB pravila drugacija potpuno, mozda su potrebni kojekakvi trikovi i sl.
[ Gojko Vujovic @ 20.04.2004. 21:32 ] @
Predlažem da pročitate i sve stare teme na ovom forumu, ima tu dosta korisnog materijala. Kao jako bitan faktor treba navesti izbor tabela, NIKAKO MyISAM, osim za neko logovanje (samo inserti, retko select i neki komplikovani kveriji).

Isto tako zbog licence koja dosta ograničava komercijalnu upotrebu (GPL), proverite i kako vam se to uklapa u planove i razmislite o postgresqlu kao alternativi.
[ Goran Rakić @ 20.04.2004. 21:38 ] @
Sada sam te potpuno pogubio... Kakve veze ima brzina web linkova? Pa server sa bazom će svakako biti u internoj mreži na jaaaako dobrom linku? Pored bluesman-ovog predloga ne vidim šta bi još moglo da se kaže.

Ipak, meni sve ovo liči na ambiciozno zamišljeni početnički projekat, bez uvrede naravno. Razmisli o load balancing rešenjima. Znači podela na tabele po bluesman-ovom predlogu ali i distribuciju samih tabela po serverima. Ako je sve ozbiljno, a po tvojim dodatnim pitanjima meni na to ne liči, onda je potrebno razmišljati i o fault protection rešenjima, odnosno o replikaciji distribuiranih tabela, pa onda o njihovoj sinhronizaciji u trenucima niskog load-a i slično.

Naravno, pored database modela, potrebno je pravilno naći i alat za izradu same web aplikacije...
[ bokini @ 20.04.2004. 22:19 ] @
Citat:
Goran Rakić:
Sada sam te potpuno pogubio... Kakve veze ima brzina web linkova? Pa server sa bazom će svakako biti u internoj mreži na jaaaako dobrom linku? Pored bluesman-ovog predloga ne vidim šta bi još moglo da se kaže.

Ipak, meni sve ovo liči na ambiciozno zamišljeni početnički projekat, bez uvrede naravno. Razmisli o load balancing rešenjima. Znači podela na tabele po bluesman-ovom predlogu ali i distribuciju samih tabela po serverima. Ako je sve ozbiljno, a po tvojim dodatnim pitanjima meni na to ne liči, onda je potrebno razmišljati i o fault protection rešenjima, odnosno o replikaciji distribuiranih tabela, pa onda o njihovoj sinhronizaciji u trenucima niskog load-a i slično.

Naravno, pored database modela, potrebno je pravilno naći i alat za izradu same web aplikacije...


Najuze me ja zanimalo, u kom slucaju ce dolaziti do manjeg zagusenja kada vise korisnika pristupa bazi. Projekat za pocetak nije preterano ozbiljan, ali bih zeleo da ga od pocetka lepo isplaniramo i da ga polako nadogradjujemo i da se na njemu ucimo. Zato sam pitao za neka iskustva. Aplikacija ce se praviti u PHP-u, sto mozemo raditi i u Notepad-u. Izvinjavam se ako sam nekog uvredio, ali cisto me je zanimalo kako poceti ovo na osnovu necijeg iskustva. Dakle da malo bacim pogled u daljinu tog problema. Desava se cesto (na ostalim forumima) da mnogi odgovaraju preko volje ili da ne procitaju pitanje, ili imaju samo teorijsko znanje.

pozdrav
[ bluesman @ 21.04.2004. 00:20 ] @
Citat:
bokini:
Ja umem da radim sa bazama podataka i da ih dizajniram, ali ovde sam pitao za iskustva sa vecim WEB sistemima. Verujem da je svako radio na bazi koja se koristi na jednom racunaru, ili u lokalnoj mrezi, ali je retko ko pravio ozbiljniji WEB sajt koji intezivno radi sa bazom.


Ono sto sam ti ponudio se koristi na sajtu koji ima skoro 600.000 clanova i oko 4 miliona slogova u mysql bazi. Pri tom, nije radjen nikakav load balancing, radi na dedicated serveru, a baza je na istom serveru kao i sajt. Upravo sam proverio, u ovo trenutku ima 669 korisnika online. Server je pao jednom za 2 godine a i to nije bilo zbog baze vec rookie admina koji se malo igrao. Da li je dovoljno veliko po tvojim standardima?

Jos da napomenem, baza je optimizovana maksimalno (koliko sam umeo), onaj clanak ce ti puno pomovi u tome, znaci, imas osnovnu tabelu korisnika i u njoj su samo polja koje se uvek citaju ili pretrazuju, a onda pravis dodatne tabele u zavisnosti od sadrzaja. Tamo svaki koriskik ima svoj record u toije 1 osnovnoj + 6 tabela koje se JOIN-uju samo po potrebi. Time dobijas da ti je osnovna tabela mala i brza.