DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)
-   -   MySQL: Više tabela, više baza ili? (http://www.devprotalk.com/showthread.php?t=3800)

Ilija Studen 21. 10. 2007. 21:55

MySQL: Više tabela, više baza ili?
 
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 21. 10. 2007. 23:40

Citat:

Originalno napisao Ilija Studen (Napišite 45037)
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? :1041:

Dejan Topalovic 22. 10. 2007. 00:33

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 22. 10. 2007. 02:00

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 22. 10. 2007. 02:17

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 22. 10. 2007. 02:33

Off Topic:

@ivanhoe
jebote bas isto razmisljamo :D

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) :D :D


ivanhoe 22. 10. 2007. 06:46

Citat:

Originalno napisao mileusna (Napišite 45057)
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 22. 10. 2007. 11:50

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

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 22. 10. 2007. 12:09

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 22. 10. 2007. 12:34

^ prvo resenje zahteva manje budzenja™ :D


Vreme je GMT +2. Trenutno vreme je 01:56.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.