DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 21. 10. 2007.   #1
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default 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
Ilija Studen je offline   Odgovorite uz citat
Staro 21. 10. 2007.   #2
benjamin
omladinac
Certified
 
Datum učlanjenja: 03.09.2006
Lokacija: beograd
Poruke: 78
Hvala: 17
4 "Hvala" u 4 poruka
benjamin is on a distinguished road
Pošaljite poruku preko Skype™ za benjamin
Default

Citat:
Originalno napisao Ilija Studen Pogledajte poruku
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?
__________________
I hate signatures on IT forums
benjamin je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #3
Dejan Topalovic
old school
Professional
 
Datum učlanjenja: 15.02.2006
Lokacija: Wien, Austria
Poruke: 304
Hvala: 121
47 "Hvala" u 26 poruka
Dejan Topalovic će postati "faca" uskoro
Pošaljite poruku preko MSN za Dejan Topalovic
Default

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...
__________________
Blog: Baze podataka
------------------------
Oracle OCP DBA
Oracle OCE SQL Expert
Oracle OCP Developer
Certified MySQL DBA
Dejan Topalovic je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #4
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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...
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 22. 10. 2007.   #5
mileusna
Super Moderator
Knowledge base
 
Datum učlanjenja: 21.03.2006
Lokacija: Kragujevac
Poruke: 1.878
Hvala: 291
1.210 "Hvala" u 354 poruka
mileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobarmileusna je jednostavno dobar
Default

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.
mileusna je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #6
kodi
133t
Master
 
Avatar kodi
 
Datum učlanjenja: 08.01.2006
Lokacija: Beograd
Poruke: 714
Hvala: 16
37 "Hvala" u 28 poruka
kodi is on a distinguished road
Pošaljite ICQ poruku za kodi
Default

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)

__________________

Poslednja izmena od kodi : 22. 10. 2007. u 02:36.
kodi je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #7
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

Citat:
Originalno napisao mileusna Pogledajte poruku
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)
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #8
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

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).
Ilija Studen je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #9
Talicni Tom
novi član
 
Datum učlanjenja: 22.10.2007
Poruke: 5
Hvala: 0
0 "Hvala" u 0 poruka
Talicni Tom is on a distinguished road
Default

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...
Talicni Tom je offline   Odgovorite uz citat
Staro 22. 10. 2007.   #10
kodi
133t
Master
 
Avatar kodi
 
Datum učlanjenja: 08.01.2006
Lokacija: Beograd
Poruke: 714
Hvala: 16
37 "Hvala" u 28 poruka
kodi is on a distinguished road
Pošaljite ICQ poruku za kodi
Default

^ prvo resenje zahteva manje budzenja™
__________________
kodi je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
SEO, više domena, ... kickloop Marketing i SEO 13 18. 10. 2010. 22:50
MySQL import - više upita iz fajla ili stringa Ilija Studen PHP 6 09. 07. 2006. 17:07


Vreme je GMT +2. Trenutno vreme je 13:18.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, 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.