[es] - Organizacija tabela

ihti
Jasmin I

Član broj: 3794
Poruke: 30
*.PPPoE-6690.sa.bih.net.ba.

Sajt: www.inservio.ba

Profil

^{04.03.2009. u 11:50 - pre 184 meseci}

Poceo sam radit na projektu koji je vec gotov ali treba dodat neke nove stvari.
Radi se o social net. stranici sa oko 500.000 korisnika.
U bazi sve izgleda ok, osim 100+ tabela imena messages3_{ID} u kojima se nalazi oko 30.000.000 poruka koje korisnici razmjenjuju, svaka tabela ima 300.000 - 500.000 redova. Tu je jos par pomocnih tabela gdje se vodi evidencija u kojoj tabeli se nalazi odredjena poruka i sl.

Prije nisam radio sa ovako velikim bazama pa me interesuje sta mislite o ovom dizajnu.
Kako bi vi ovo rijesili? Da li sve poruke smjestit u jednu tabelu ili podjelit u vise tabela kao sto je ovdje uradjeno pa bi eksponencijalno sa rastom broja poruka rastao i broj tabela, za par mjeseci ce bit 200+ tabela...

Ovako to izgleda kroz Navicat: http://img25.imageshack.us/img25/4295/messageshe0.jpg

NO FATE. ONLY THE POWER OF WILL.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: Organizacija tabela

^{04.03.2009. u 12:18 - pre 184 meseci}

deljenje na veliki broj tabela je cest pristup... isti ima svoje prednosti i mane no u svakom slucaju nije "los" i za sistem gde je potrebna brzina prilicno dobar....

najbolja alternativa tom pristupu je partitioning: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

- ima sve benefite koje ima pristup sa gomilom tabela
- ima dodatne benefite (ne moras da cuvas gde se sta nalazi na primer)
- nema one mane koje ima pristup sa gomilom tabela

ono sto su danas problemi sa partitioningom je
- partitioning nije prisutan u mysql-u dovoljno dugo te nije dovoljno istestiran
- nema dovoljan broj klijenata koji koriste partitioning u production okruzenju tako da nemam feedback koliko je stabilan
- da li sam spomenuo da nemamo pojma koliko je stabilan?

realno, sun sada ima nekoliko velikih klijenata koji koriste partitioning i oni su pomogli u testiranju i doveli partitioning dovde. partitioning je jedan od razloga zasto je 5.1 cekao ovoliko dugo da postane GA i jedan od razloga zasto se neki ne slazu da je 5.1 "dovoljno dobar za GA" (monti na primer) posto je to nedovoljno istestiran proizvod da bi se reklo da je "Stabilan". Ono sto je glavni problem partitioninga je "administracija particija", do pre neku verziju, uopste nisi mogao da popravis tabelu ako je jedan particija zabodena .. i dalje neke administrativne operacije nad jednom particijom (na primer analyze) u stvari se izvrsavaju nad celom tabelom i slicno ...

za proizvod koji "danas" treba da ide u production - ja bih se zadrzao na pokazanom resenju (mnogo tabela), za proizvod koji ce u production za 6+ meseci, ja bih koristio partitioning "od odma" kako bih
- testirao ponasanje partitioninga
- ukazao sun-u na potencijalne bagove na koje sam naisao tokom testiranja kako bi ih sun u narednih 6 meseci ispravio

sve u svemu, ja znam za dva klijenta (mozda ih ima vise ali ja nisam naleteo) koji koriste partitioning u production okruzenju sa tabelama preko 500M slogova / tabelema velikim po nekoliko desetina G .. jos niko nije ostao bez podataka :D ali se desilo da je jedan klijent imao 6h downtime zato sto je morao da se radi rebuild cele tabele umesto samo jedne particije

izvini na odgovoru "s'brda s'dola" ... nije mi danas dan

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

ihti
Jasmin I

Član broj: 3794
Poruke: 30
*.PPPoE-6690.sa.bih.net.ba.

Sajt: www.inservio.ba

Profil

Re: Organizacija tabela

^{04.03.2009. u 15:57 - pre 184 meseci}

Hvala na brzom i opsirnom odgovoru ;)

Citao sam o partitioning-u pa mi je palo na pamet da bi se ovo sa partionigom moglo rijesit, ali nemamo namjeru da koristimo MySQL 5.1 bar jos neko vrijeme.
Kakav je efekat na perfomanse kada bi se u ovom slucaju svi podaci drzali u jednoj tabeli i kakva je generalno praksa kod velikih korisnika.
Postoji mogucnost da cemo trebat cijeli ovaj projekat uradit na novo tj. isprogramirat jer je trenutno hrpa proceduralnog koda sto je veoma tesko odrzavat.
Pa bi usput dobro bilo poboljasat dizajn baze.

NO FATE. ONLY THE POWER OF WILL.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: Organizacija tabela

^{04.03.2009. u 16:32 - pre 184 meseci}

sto se tice 5.1 ako ga koristis kao 5.0 (dakle ne koristis nove stvari) radi bolje, brze i stabilnije od 5.0 .. ono sto je kod 5.1 "ne dovoljno dobro" i zbog cega cela halabuka su "novi feature's" koje 5.1 donosi (na primer partitioning).

ako imate nameru redizajnirati i preprogramirati - partitioning je po meni resenje - posto vama treba vreme da to napravite a do tada ce partitioning biti stabilan proizvod... (skoro da vec danas jeste sa 5.1.31)

veliki korisnici su veliki korisnici ... uvek ce tabela od 1000 slogova biti brza od tabele od 1000M slogova :)... svako optimizuje posao po svojim zahtevima i potrebama ... ima mnogo tabela od po par G online danas i to nije nista cudno .. bitno je samo da je db struktura ok i da su upiti ok ... dodatne performanse se dobijaju dodavanjem servera, koristenjem query cache-a, koristenjem memcashed-a i slicnim kombinacijama ... ne postoji "univerzalno" resenje ... iliti sto anglikanci kazu "there is no silver bullet"

nemoj me pogresno shvatiti, partitioning prolazi nase testove, ne postoji mnogo otvorenih poznatih bagova i ozbiljne firme ga vec koriste u production okruzenju ... dakle, ne pricamo o "polufabrikatu" ... ono sto kazem je da prosto nije jos dovoljno istestiran ...

dakle, odgovor na "kakav je efekat na performanse" ... nemam pojma .. zavisi od previse stvari .. moze da bude mnogo brze sa jednom velikom tabelom a moze da bude brze sa mnogo manjih .. sve zavisi kako se koriste ... ono sto je bitno
- na windozi posle nekog broja tabela windoze prave razne probleme (posebno u slucaju myisam ili innodb-file-per-table)
- u slucaju myisam ili innodb-file-per-table obratiti paznju na table_cache i max_open_files

optimizuj svoj mysql server prema nacinu na koji ga koristis ... ne postoji ni "univerzalno setovanje" servera .. (doduse, vrlo moguce da ce 6.x da se "samosetuje" koristeci real time usage data - na tome se trenutno radi - ali ... dok 6.x bude ga...) ..

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

ihti
Jasmin I

Član broj: 3794
Poruke: 30
*.PPPoE-6690.sa.bih.net.ba.

Sajt: www.inservio.ba

Profil

Re: Organizacija tabela

^{04.03.2009. u 18:44 - pre 184 meseci}

Vidjet cemo kako ce sve teci oko projekta, ja bi volio koristit partinioning, djeluje kao elegantno, lako i ucinkovito rjesenje u odnosu na hrpu tabel.
Redovno pratim Planet MySQL gdje uglavnom pljuju po 5.1 pa sam jos oprezan oko koristenja u produkciji posebno novih featuresa. Znaci ipak ima velikih korisnika i nije tako strasno bugovit koa sto se pise.

A sto se tice programerske strane tu obavezno ide optimizacija query-a, koda, cache (memcached)...
O MySQL na Windows-u nema govora, Debian obavezno :)

btw. da li je u tvom opisu posla promocija MySQL-a kroz forume, blogove i sl. ili ovako opsirne i kvalitetne savjete djelis iz hobija :)
U svakom slucaju hvala ;)

NO FATE. ONLY THE POWER OF WILL.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: Organizacija tabela

^{05.03.2009. u 01:12 - pre 184 meseci}

Citat:

gdje uglavnom pljuju po 5.1 pa sam jos oprezan oko koristenja u produkciji posebno novih featuresa. Znaci ipak ima velikih korisnika i nije tako strasno bugovit koa sto se pise.

mnogo je kompleksnija stvar nego sto naizgled deluje
1. mnogo ljudi je izbedaceno sto je sun kupio mysql te je sada mysql vlasnistvo ogromne firme a ne par likova iz skandinavije
2. mnogo je ljudi izbedaceno zato sto je monti otisao iz mysql-a
3. mnogo ljudi to sada koristi da zaradi neke pare

vezano za kvalitet 5.1 ... i monti je rekao a ja cu samo da ponovim, ako ces da ga koristis kao 5.0 onda je bolji i stabilniji od 5.0.

ono sto u 5.1 ne valja to su "nove opcije"
- partitioning nije gotov
- federated je bogu za plakati i skoro pa je neupotrebljiv
- podaci iz information_schema dolaze sporo do zla boga
...
...

ali ako koristis samo 5.0 opcije, 5.1 je mnooooooooogo bolji od 5.0 i stabilniji...

uzmi ovako, MySQL Cluster SQL nod je 5.1 :) i koriste ga mnoooooooooogo zeznute firme za mnooogo zeznute poslove ..

Citat:

da li je u tvom opisu posla promocija MySQL-a kroz forume, blogove i sl. ili ovako opsirne i kvalitetne savjete djelis iz hobija :)

haha .. ja uopste ne radim obican mysql .. ovo sto napisem je ono sto je iz mog licnog iskustva i sto vidim / procitam usput .. moj posao je MySQL Cluster .. to nije bas mnogo slicno obicnom mysql-u .. za "podrsku na forumu" sam morao traziti "dozvolu" :) ... tako da .. yup - solim pamet iz hobija :) ... generalno, mislio sam da je ovde u ovim krajevima svest o mysql-u prilicno rasirena i da ljudi znaju sta mysql moze, sta ume, i gde mu je mesto ... posto su me prosle godine zamolili da odrzim neko kratko predavanje u novom sadu i beogradu pricajuci sa ljudima pre, za vreme i posle tog predavanja sto u novom sadu sto u beogradu, dosao sam do zakljucka da ljudi pojma nemaju sta se desava u mysql svetu pa sam odlucio da nesto "vratim" nazad u "community" soleci pamet iz hobija :)

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu