Organizacija tabela

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

Potpis

NO FATE. ONLY THE POWER OF WILL.

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

Potpis

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

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.

Potpis

NO FATE. ONLY THE POWER OF WILL.

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...) ..

Potpis

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

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 ;)

Potpis

NO FATE. ONLY THE POWER OF WILL.