|
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 |
Citat:
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: |
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... |
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... |
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. |
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 |
Citat:
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) |
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). |
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... |
^ prvo resenje zahteva manje budzenja™ :D
|
activeCollab je skripta koju downloaduješ i instaliraš kod sebe na server. Kao takva nema ugrađenu mogućnost da možeš da voziš više instanci iz jedne baze. Može da gura više instanci koristeći samo jednu instalaciju framework i aplikacije, ali ne i baze... Nisam baš hteo da od prvog dana podržim pravljanje web servisa od sistema, bar ne toliko lako ;)
Demo je tu čisto da bi ljudi probali sistem i zahtev je da svako ima instalaciju za sebe. Da ne bismo morali da bužimo sistem da podržava više instanci iz jedne baze napravili smo skript koji svakom instalira instancu i kreira potrebne tabele (podrška za table prefix je ovde bila zlata vredna). |
^ Evo resenjaaaaaaa.....
Samo sam čekao da neko to predloži, ali to zahteva izmene u applikaciji. Ja bih uradio jednu demo verziju u koju može da se uloguje ko god hoće i da radi šta hoće (osim recimo upload) i neka se igra i gleda. Ali, to je ipak samo ono što bih ja... Edit: uvališe mi se 2 posta između. |
^ Ima i takav demo (tu imamo oko 3000 aktivnih naloga za sada), ali tu ljudi nemaju administratorske dozvole pa ne vide šta sve sistem radi.
Obično je ekipi koja je odgovorna za kupovinu bitno da vidi kako se sistem setupuje i šta administratori imaju na raspolaganju - kako role rade (nisam znao da su ljudi TOLIKO opsednuti kontrolom i dozvolama), da li mogu da prerade autentifikaciju, kako se administriraju plugini i slično. Pošto smo imali mnogo zahteva da im damo način da vide to dodali smo fully featured hosted demo (ono o čemu ovde pričamo) i 30 days money back garanciju ako hoće da vide sve kako funkcioniše. Pošto još uvek uhodavamo sistem htedoh da pitam to za broj tabela, da ne naletimo na nezgodne probleme kasnije. Bolje u startu preduhitriti problem nego kasnije ne spavati jer se sve raspada :) |
Off Topic: takvi multiuser demoi su obicno bas bezveze jer zavrsis za par hiljada poruka tipa: helloo test123 testing s druge strane dobijes prazan sistem, pa postoji verovatnoca da se neko nece bas najbolje snaci.. al to vec zalazi u usability |
Citat:
Mada, ocigledno da se to ne uklapa u zahteve Ilijine aplikacije da ogranici korisnike na jednu instancu pa je stoga budzenje jedino sto mu preostaje uz shared demo. |
Citat:
Svaki korisnik ce da napuni u bazu gomilu djubreta kako bi nesto isprobao... Recimo projekat sa nazivom "nja nja bla 049xlli" i takvih 10. Kada se jedanaesti korisnik uloguje mislis da ce mu biti prijatno da vidi tu kolicinu besmislenih stvari ? :) |
Citat:
|
Citat:
A šta će taj user da upisuje u svojoj bazi kada dobije nice and clean? Možda će da upiše kompletan business plan? Ili će i on da upiše "lnja nja bla 049xlli" i takvih 10? A kada imaš jedan demo sajt i jednu demu bazu, ne postoji ništa lakše nego da jednom dnevno (ili jednom na sat) obrišeš sve što su se useri igrali i još bolje, imaš neki script koji automatski popuni "demo data" pa umesto "nja nja bla 049xlli" imaš "Demo project #1" ili nešto smislenije sa nekoliko taskova, files, dummy usera.... Po meni je vrlo bitno da korisnik ukapira kako sve funkcioniše i da ne potroši previše vremena, ako ćeš svakoga da teraš da upisuje sve od nule (a obično upiše "nja nja bla 049xlli") onda em gubi vreme em imaš situaciju gde se ne snađu svi sa relacijama, funkcionalnosti... Opet kažem, ja bih tako uradio, ali to je samo moje mišljenje... |
Velika je razlika da li si ti napravio djubre ili si ga zatekao.
To ti je kao kada otvoris tudji kod, da bi napravio sitnu izmenu, i zateknes gomilu djubreta... odmah gubis motivaciju.... e sad da je to tvoje djubre... |
Ako žele da vide kako je u koži admina, ostaviš jedan admin nalog na testu (user + pass) da mogu svi da koriste, pa nek se igraju do mile volje. Podesiš cron da resetuje bazu na svakih ... (proceni sam) i završio si posao za demo. Ok, verovatno bi morao da zavrneš par funkcionalnosti, ali ostavljaš im dovoljno da skontaju o čemu se radi.
|
Svakako nije loše imati skript koji u praznu bazu dodaje neke "example" podatke - šta inače koristite kad radite unit testing?
|
Sve se moze uraditi na vise nacina...
Moje licno misljenje je da je scheduled brisanje sadrzaja baze veoma prljavo i da se moze uraditi mnogo cistije i lepse (neka resenja vec nabrojana)... naravno ako je cilj uradti sto pre bitniji od uraditi kako treba onda... |
Po meni, blues je total u pravu.
Treba imati online demo koji se resetuje na svakih sat-2, i koji ima dizejblovane submite za neke extra stvari (da bas ne spamuju sistem, i ne menjaju general settings, recimo). A svako ko zeli vise od toga, neka lepo skine sebi trial i neka ga instalira kod sebe. Demo je i tako samo za prvu loptu. Ostali ce da furaju trial, uglavnom inhouse. Samo ti njima ponudi trial, i procvetace ti. ;-) |
| Vreme je GMT +2. Trenutno vreme je 18:38. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.