MySQL: Više tabela, više baza ili?

[Ilija Studen]

Kada kreiramo hosted demo korisnicima kreiramo im posebnu instalaciju activeCollaba sa njihovim setom tabela u jednoj bazi. Problem je što broj tabela raste na cifre sa kojima se do sada nisam sretao, pa me zanima da li je i koliko to problematično?

Da li je bolje koristiti više baza sa malim brojem tabela u svakoj ili više tabela unutar jedne baze? Korisnici se obično poigraju sa demoom i odu, a mi smo dužni da isti držimo na serveru 30 dana.

Iskustva, tips and tricks...

Thanks

[benjamin]

Originalno napisao Ilija Studen

Kada kreiramo hosted demo korisnicima kreiramo im posebnu instalaciju activeCollaba sa njihovim setom tabela u jednoj bazi. Problem je što broj tabela raste na cifre sa kojima se do sada nisam sretao, pa me zanima da li je i koliko to problematično?

Da li je bolje koristiti više baza sa malim brojem tabela u svakoj ili više tabela unutar jedne baze? Korisnici se obično poigraju sa demoom i odu, a mi smo dužni da isti držimo na serveru 30 dana.

Iskustva, tips and tricks...

Thanks

generalno nećeš postići ništa dramatično drugačije koristeći bilo koju od solucija. pokušao sam jednom to da testiram i nisam dobio nikakav rezultat.
sem na oracle 10g ... ali to nije tema

na tvom mestu ja bih pravio na svaki mesec (rekao si 30 dana) novu bazu i u nju stavljao klijente koji su zatražili demo ... tehnički ništa nećeš postići sem lakšeg administriranja.

ti daješ istog usera za pristup bazi svim demo korisnicima?

[Dejan Topalovic]

Nisam siguran da sam najjasnije shvatio tvoje potrebe, ali pokusacu da iznesem svoje misljenje....

Ukoliko imas vise razlicitih korisnika, koji nemaju administratorski pristup bazi, onda je efikasnije da koristis vise tabela u jednoj bazi i to tako da koristis tzv. template - "korisnik1_tabela1", "korisnik1_tabela2", te analogno tomu "korisnik2_tabela1", "korisnik2_tabela2" i td.
Smanjuje se broj upita za privilegijama (upiti nad dictionary semom - INFORMATION_SCHEMA), nemas potrebu za zahtjevnijom administracijom veceg broja baza (lakse je podesiti jednu bazu, nego njih 100), odrzavas manji broj connection stringova (da ne moras imati vise config.php fajlova ili vise baza da biras sa select_db)...

E sad, ako imas neke specificne potrebe, onda ih moras navesti, da bi se moglo diskutovati sta je bolje u tvom slucaju...

[ivanhoe]

sve zavisi sta znaci veliki broj tabela, o kojoj cifri pricamo tacno?

imam jako lose iskustvo sa stvarno velikim brojem tabela (oko 60000 u istoj bazi), pri cemu se vecini tabela periodicno pristupa i to iz vise razloga:

1. izuzetno lose perfomanse jer se table cache stalno puni i prazni i mysql stalno otvara i zatvara tabele
2. dodatno kvari perfomanse sto sistemski cache ne moze da efikasno kesira toliko paraleno otvorenih fajlova
3. i jos gore perfomanse jer ext2 i ext3 ne umeju bas najbolje da radi sa tolikim brojem fajlova u istom direktorijumu
4. potrosi ti uzasno mnogo fajl deskriptora na sistemu
5. nemoguce je odraditi iole efikasno backup jer nijedan tool koji sam probao ne ume da radi sa toliko tabela, na kraju smo pisali custom skriptu koja dumpuje tabelu po tabelu i to je trajalo po 2 dana dok se izvrsi...

To je sto se tice negativnih strana toga, pozitivne trakodje postoje, vec su ih naveli i one nisu zanemarljive. U mom slucaju se radilo o popularnom blog sajtu sa 6000 korisnika, pa su sve tabele bile manje vise u upotrebi stalno. Ti imas malo drugaciji slucaj jer ce u istom trenutku biti u funkciji samo mali broj svezih tabela, vecina starih se nece uopste koristiti (sto elimise probleme pod 1) i 2) i cini celu stvar relativno upotrebljivom).

E sad, moj predlog je malkice komplikovaniji (ali samo malkice), ali se pokazao kao izuzetno efikasan u praxi:
1. Kad imenujes tabele napravi im imena kao npr. USER_ID_ime_tabele, a baze imenujes dodajuci redni broj u ime (tipa baza_001, baza_002 itd...)
2. Kad kreiras nove korisnike stavljaj njihove tabele u jednu bazu sve dok se ne napuni do nekog razumnog broja, recimo 15K-20K tabela.
3. Onda kreiras novu bazu i nastavis da nju punis novim korisnicima bas kao sto si radio sa prethodnom, izmena je potpuno transparentna.
4. Da bi to sve lepo radilo uz minimalno menjane koda samo treba u klasi kojom pristupas bazi da napravis switch koji ce da na osnovu ID-ja korisnika izracuna u kojoj bazi se on nalazi i kako treba da se zovu tabele. Tto je vrlo jednostavno odraditi ako ti imena tabela nisu hardkodovana u kodu (a verujem da nisu), bukvalno treba par linija koda da se izmeni...

[mileusna]

Ja sam nedavno imao istu dilemu i odlučio sam se za više tabela u jednoj bazi. Doduše, nije neki veliki broj u pitanju, 3-4 instance jednog istog seta tabela. Lično sam se opredelio za taj model jer sam imao i neke zajedničke tabele koje koriste sve instance aplikacije, pa je tako bilo i zgodnije.

Takodje, Wordpress multiuser radi na tom principu, u jednoj bazi za svaki blog koji napraviš pravi novi set tabela.

[kodi]

Off Topic:

@ivanhoe
jebote bas isto razmisljamo

inace tehnika je u neku ruku "poor mans scaling" jer tako mozes da raspodelis load na vise servera (i uz to molis boga za ravnomernu raspodelu)

[ivanhoe]

Originalno napisao mileusna

Takodje, Wordpress multiuser radi na tom principu, u jednoj bazi za svaki blog koji napraviš pravi novi set tabela.

ono sto sam opisao u prethodnoj poruci (DIY db proxy) je upravo tehnika koju koristi vecina velikih (preko 4-5K blogova) WP Multiuser based sajtova, jer je to jedini nacin da WPMU sajt raste, da pravis nove i nove baze (i servere)..

inace sajt koji sam pominjao je bio baziran na WPMU i na nekih 6000 clanova je jednostavno krenuo da skucava masinu cim se pokrene kreiranje novog usera... WPMU je naprosto hack sa Wordpress kodom, da se uz minimum truda dobije multiuser blog, i nije bas dobar primer kako stvari treba da se rade (IMHO)

[Ilija Studen]

Hvala za informacije. Mene sama pomisao od par hiljada tabela u bazi pomalo straši, da ne govorim o ciframa >50K. Neiskustvo, šta ćeš

Kako stvari trenutno stoje najverovatnije ćemo kreirati bazu za svaki mesec - na dan kreiranja demoa se određuje u koju bazu će da idu tabele. Tako ćemo imati sve fino raspoređeno, plus će čišćenje zastarelih demoa biti mnogo jednostavnije (15. decembra dropujemo oktobrasku bazu, u januaru novembarsku itd).

[Talicni Tom]

Ne znam kakvo je ogranicenje aplikacije, ali zasto svaki korisnik mora da dobije bazu/set tabela?
Da li si razmisljao o tome da svi demoi rade sa istim setom tabela, u jednoj bazi, s tim da postoji posebna tabela koja bi identifikovala sta kome pripada. Drugim recima, imas tabelu koja sadrzi kolonu demo_id a ostale tabele sadrze referencu na ovu tabelu. Tako postizes da baza radi ono za sta je predvidjena: rad sa relativno malim brojem tabela i ogromnim brojem redova u tim tabelama.
Ovakvo resenje prakticno i eliminise problem brisanja demoa...

[kodi]

^ prvo resenje zahteva manje budzenja™