Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

MySQL (relativno) velika baza

[es] :: MySQL :: MySQL (relativno) velika baza

[ Pregleda: 2434 | Odgovora: 13 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Skaarj
Novi Sad

Član broj: 21463
Poruke: 365
93.86.127.*



+3 Profil

icon MySQL (relativno) velika baza23.03.2009. u 17:06 - pre 182 meseci
Imam bazu u kojoj jedna tabela trenutno ima 90 miliona slogova (beleze se neke statistike i nasledjena je tako) i sada gledam nacin da optimizujem malo tu strukturu.

U pomenutu tabelu se upisuje oko 100-200k slogova dnevno. Problem nastaje sa pretragom podatka koja traje predugo (tabela je dobro indeksirana i upiti idu po indeksima).

Razmisljam da podelim tabelu na vise manjih i da ih onda spojim merge (MRG_MYISAM) tabelom. Pitanje je da li je to mudra strategija i kako to najbolje izvesti tako da se ubrza upis a i upiti nad ostatkom podataka.
 
Odgovor na temu

ihti
Jasmin I

Član broj: 3794
Poruke: 30
92.36.214.*

Sajt: www.inservio.ba


Profil

icon Re: MySQL (relativno) velika baza23.03.2009. u 18:39 - pre 182 meseci
Pogledaj ovu temu: http://www.elitesecurity.org/t356921-Organizacija-tabela
mislim da ce ti bit od koristi

Da li si razmisljao o kesiranju rezultat pretrage?
NO FATE. ONLY THE POWER OF WILL.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza23.03.2009. u 20:36 - pre 182 meseci
sve zavisi sta radis ... i kakvi su podaci u tabeli .. nad kojim podacima pravis upit i slicno. merge ce ti pomoci u nekim specificnim slucajevima, partitioning ce ti pomoci u drugim (manje specificnim) slucajevima ... ovako napamet,
- mozes da reorganizujes db model (neka prica je na linku koji si dobio u prethodnom postu - naravno postoje i dodatne opcije a sve je to app specific)
- mozes da reorganizujes upite
- mozes da pravis summary tabele koje odrzavas trigerima

ne postoji "najbolje resenje" ... trigeri koji bi odrzavali summary tabele mogu znacajno da uspore brzinu inserta, etc etc etc ... dakle sve zavisi kakvi su ti tacno podaci i kako ih tacno koristis ... 200K slogova dnevno nije mnogo (2-3 inserta u sekundi) ako su pravilno rasporedjeni, ali ako tih 200K inserta dodje u pola sata, onda je druga prica

 
Odgovor na temu

Skaarj
Novi Sad

Član broj: 21463
Poruke: 365
93.86.127.*



+3 Profil

icon Re: MySQL (relativno) velika baza23.03.2009. u 23:21 - pre 182 meseci
Evo malo vise detalja o situaciji.

Tabela se pise ravnomerno tokom celog dana (ima pikova ali nista znacajno). Tabela se relativno retko cita, ugavnom kad neko hoce da pogleda izvestaj o trenutnom stanju. Problem je sto ljudi koji to citaju ne vole bas da im se duznia ucitavanja stranice meri u minutima, a oni daju pare za ovu zavrzlamu. :)

Za jedan izvestaj koji obuhvata 50 stavki (od mogucih 90k) potrebno je proci kroz tu tabelu do 50 puta. Statistike koje se tu beleze nisu relevantne za sve stavke izvestaja tako da je broj upita uglavnom oko 50% od broja stavki za koje se izvestaj trazi. Tabela inace sadrzi kratke stringove i brojeve nista glomazno.

Aplikacija je operatvina tako da za sada ne mogu da izvodim neke velike promene u semi bez da je ugrozim. Na zalost prilicno je lose napisana pa cak i jednostavne izmene zahtevaju dosta provera po kodu.

Trenutno baratam sa idejom da u udarnoj tabeli drzim samo upise za dati dan i da svakih 24 sata prebacujem podatke u drugu tabelu koja bi cuvala ostatak. Da tu udarnu tabelu prakticno iskljucim iz generisanja izvestaja (tj da podaci budu sa danom zaostatka), eventualno da radi brzine oslobodim tabelu i indeksa jer ce se u nju samo pisati bez citanja. Ako se sistem pokaze dobrim postepeno bih skracivao vreme zaostatka podataka na recimo 4-6 sati. To bi mi omogucilo da malo bolje raspolazem kesevima koje MySQL pruza, jer su sada zbog jako cestih izmena neupotrebljivi.

Ostale podatke bih podelio u 3-4 tabele i to po godinama. Ti podaci ostaju fiksni i ne menjaju se. Dobio bih tabele od 20-40m slogova sto mi se ne cini jako strasnim za povremeno iscitavanje.

Inace koristim memcahce kojekude u aplikaciji ali ovde nisam nasao neku primenu barem ne jos.

Server je inace Xeon Quad x2 sa 8Gb rama i trenutno izvrsava oko 1600 upita u sekundi.


 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 00:13 - pre 182 meseci
Citat:

Tabela se pise ravnomerno tokom celog dana (ima pikova ali nista znacajno). Tabela se relativno retko cita, ugavnom kad neko hoce da pogleda izvestaj o trenutnom stanju. Problem je sto ljudi koji to citaju ne vole bas da im se duznia ucitavanja stranice meri u minutima, a oni daju pare za ovu zavrzlamu. :)


:D ... retko citas, al kad citas oces da bude brzo :) - jasno

Citat:

Za jedan izvestaj koji obuhvata 50 stavki (od mogucih 90k) potrebno je proci kroz tu tabelu do 50 puta. Statistike koje se tu beleze nisu relevantne za sve stavke izvestaja tako da je broj upita uglavnom oko 50% od broja stavki za koje se izvestaj trazi. Tabela inace sadrzi kratke stringove i brojeve nista glomazno.


vidi, ako kroz tabelu prolazis vise od jednom - nesto si ******** .... ili ti je los upit koji generise taj izvestaj, ili ti je model mnogo los

Citat:

Aplikacija je operatvina tako da za sada ne mogu da izvodim neke velike promene u semi bez da je ugrozim. Na zalost prilicno je lose napisana pa cak i jednostavne izmene zahtevaju dosta provera po kodu.


vidi, konfiguracijom mysql-a neces resiti problem. problem se tu resava redizajnom baze i upita. ako ne mozes (ne isplati ti se, ne umes, ne smes, nemas kad ...) da menjas aplikaciju / db model, sve sto mozes je da odradis sto optimalniji setup mysql-a ( pogledaj ovde za neke generalne smernice ) i to je to... odma mogu da ti kazem da ugasis query cache posto ce samo da ti uspori celu stvar (imas puno upisa i malo upita) ...

Citat:

Trenutno baratam sa idejom da u udarnoj tabeli drzim samo upise za dati dan i da svakih 24 sata prebacujem podatke u drugu tabelu koja bi cuvala ostatak. Da tu udarnu tabelu prakticno iskljucim iz generisanja izvestaja (tj da podaci budu sa danom zaostatka), eventualno da radi brzine oslobodim tabelu i indeksa jer ce se u nju samo pisati bez citanja. Ako se sistem pokaze dobrim postepeno bih skracivao vreme zaostatka podataka na recimo 4-6 sati. To bi mi omogucilo da malo bolje raspolazem kesevima koje MySQL pruza, jer su sada zbog jako cestih izmena neupotrebljivi.


pazi, sve zavisi koliko smes da menjas app / db model... dakle da ponovim, ako moras 50 puta da prodjes kroz tabelu od 100M slogova - nesto si gadno lose uradio ... 100M slogova nije nista "preterano veliko da bi ti neki report trajao duze od par sekundi"


Citat:

Ostale podatke bih podelio u 3-4 tabele i to po godinama. Ti podaci ostaju fiksni i ne menjaju se. Dobio bih tabele od 20-40m slogova sto mi se ne cini jako strasnim za povremeno iscitavanje.


:)

i dalje pricam vrlo uopsteno ... mozda je za tebe partitioning resenje, mada, rekoh da nije bas "istestiran" .. ali mi se i dalje cini da tu mogu druge stvari da pomognu vise.

Citat:

Inace koristim memcahce kojekude u aplikaciji ali ovde nisam nasao neku primenu barem ne jos.

memcached ti je ok ako imas dosta upita .. ovde bi mogao da napravis "scheduler" koji ti na svakih 1h na primer napuni memcached sa "podacima" a iz aplikacije samo citas iz memcached i ne sljivis bazu uopste ... to je potpuno upotrebljivo i izvedivo resenje ako
- ne moras da imas realtime data
- mozes da promenis aplikaciju

Citat:
Server je inace Xeon Quad x2 sa 8Gb rama i trenutno izvrsava oko 1600 upita u sekundi.

1. koji os?
2. da li teras 64bitni mysqi?
3. jesu tabele myisam ili innodb?
4. ako su tabele myisam - koliki je innodb_buffer
5. da li je to server dedicated za mysql?
6. koliki ti je innodb_concurency?
7. koliko tredova upisuje podatke?

 
Odgovor na temu

Skaarj
Novi Sad

Član broj: 21463
Poruke: 365
93.86.127.*



+3 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 06:04 - pre 182 meseci
Svestan sam da iskljucivo konfigurisanjem mysqla mogu da postignem ogranicene rezultate ali pre nego sto pocnem da menjam semu baze i aplikaciju hteo sam da vidim sta mogu da uradim da popravim trenutno stanje. Aplikaciju svakako moram da menjam samo moram da postupam pazljivo jer ne sme da bude downtimea pa sad gledam sta mi je najbolje da cinim.

Citat:

vidi, ako kroz tabelu prolazis vise od jednom - nesto si ******** .... ili ti je los upit koji generise taj izvestaj, ili ti je model mnogo los

Ako mozes malo da elaboriras na ovu temu? Skript generise upite za svaku stavku koja je potrebna tipa
SELECT * FROM tab_a WHERE name='stavka' AND datum BETWEEN '2009-01-01' AND '2009-03-01'
Da li je bolje napraviti nesto ovako:
SELECT * FROM tab_a WHERE name IN ('stavka1', 'stavka2'...) AND datum BETWEEN '2009-01-01' AND '2009-03-01' GROUP BY name; ?

Sudeci po explainu upiti idu po indeksima u oba slucaja. + drugi korsiti temp tabelu + filesort.

Citat:

1. koji os?

Linux 64bitni (ne znam koja distribucija jer ne kontrolisem sam server, samo pristupam bazi)
Citat:

2. da li teras 64bitni mysqi?

Da, Mysql 5.1.29 kojem je iskljucena podrska za particionisanje.
Citat:

3. jesu tabele myisam ili innodb?

Iskljucivo MyISAM, InnoDB nije dozovoljen (ne pitaj me zasto takva je politika firme)
Citat:

4. ako su tabele myisam - koliki je innodb_buffer

Nisam znao da ovo ima veze jedno sa drugim; innodb_buffer_size = 8388608
Citat:

5. da li je to server dedicated za mysql?

Da, plus je master u replikaciji
Citat:

6. koliki ti je innodb_concurency?

Opet, ima li veze ako je MyISAM iskljucivo? innodb_concurrency_tickets = 500 ; innodb_commit_concurrency =0
Citat:

7. koliko tredova upisuje podatke?

Nisam siguran koji je parametar za ovo nadlezan: thread_handling = one-thread-per-conenction; thread_stack = 262144
Ako nije ovo reci kako da saznam pa cu naci podatak.

btw. Hvala za utroseno vreme. :)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 06:43 - pre 182 meseci
Citat:
Svestan sam da iskljucivo konfigurisanjem mysqla mogu da postignem ogranicene rezultate ali pre nego sto pocnem da menjam semu baze i aplikaciju hteo sam da vidim sta mogu da uradim da popravim trenutno stanje. Aplikaciju svakako moram da menjam samo moram da postupam pazljivo jer ne sme da bude downtimea pa sad gledam sta mi je najbolje da cinim.


ok, onda smo se razumeli :)

Citat:

Ako mozes malo da elaboriras na ovu temu? Skript generise upite za svaku stavku koja je potrebna tipa
SELECT * FROM tab_a WHERE name='stavka' AND datum BETWEEN '2009-01-01' AND '2009-03-01'
Da li je bolje napraviti nesto ovako:
SELECT * FROM tab_a WHERE name IN ('stavka1', 'stavka2'...) AND datum BETWEEN '2009-01-01' AND '2009-03-01' GROUP BY name; ?

Sudeci po explainu upiti idu po indeksima u oba slucaja. + drugi korsiti temp tabelu + filesort.


ne znam na sta ti lici baza ali velika je verovatnoca da ce ovaj group by upit da bude brzi od X*prvi upit.. cim imas group by mora da koristi temp tabelu sto nije problem.. to sto koristi filesort znaci da ne moze da odradi sortiranje po indexu - jel ti kolona "name" indexirana (po njoj radis group by) ?


Citat:

Mysql 5.1.29

sedi sysadmu na vrat da upgradeuje MALOPRE!!!!
ja ne volim da predlazem upgrade nikome kao resenje za bilo sta ali odradite upgrade na 5.1.32 ODMA!! ne zezam se ... nema nikakve veze sa brzinom vec sa par ozbiljnih bagova koji su reseni tek u .31


Citat:

Iskljucivo MyISAM, InnoDB nije dozovoljen (ne pitaj me zasto takva je politika firme)


Ako su ti silni upisi "append" .. MyISAM je znacajno brzi od InnoDB-a, MyISAM je "jednostavno licenciran", InnoDB je vlasnistvo Oracle-a (vec 2 godine) i licenciranje je kompleksno .. (ako ti uopste trebaju licence)

Citat:

Citat:
4. ako su tabele myisam - koliki je innodb_buffer


Nisam znao da ovo ima veze jedno sa drugim; innodb_buffer_size = 8388608


Lapsus :D ... nemaju veze jedno sa drugim :) tedoh napisat "ako su tabele innodb koliki jeinnodb_buffer" :)
ako nemate uopste innodb tabele
1. zabodi taj bafer na 0
2. startuj mysql bez podrske za innodb ( http://dev.mysql.com/doc/refma...html#option_mysqld_skip-innodb ) sa --skip-innodb

nema potrebe da trosis resurse na taj engine ako ga ne koristis, zabosces njegova workera i osloboditi malo rama

ovo za tredove .. koliko konekcija na bazu pravi tvoja aplikacija koja unosi podatke / koliko aplikacija unosi podatke ... to nije parametar na mysql-u nego prosto koliki broj konekcija koje pisu po bazi imas u proseku i koliko max ...

LM, par stvari koje treba sysa da odradi ako nije
1. da upgradeuje to pod hitno na 5.1.32 (neka napravi bekap pre upgrade-a)
2. ja se iskreno nadam da je to turio na LVM posto u kombinaciji sa myisam tabelama i mysqllvmbackup-om backup ide 1/1, brzo i sigurno
3. imas dosta rama, odseci parce (1G na primer) i napravi ram disk za mysql tmpdir (mozes da koristis i tmpfs) ubrzaces upite koji koriste temp tabele na disku drasticno


e sada .. sto se menjanja kako sve to radi tice .. promena db modela je kompleksna rabota na aplikaciji koja nije dovoljno dobro dokumentovana tako da ti je sigurna varijanta da ides sa menjanjem upita (kako si krenuo) i malo boljom konfiguracijom sistema .. bilo bi iskusno da mozete da poterate merlin :( ali ... no .. za pocetak mozes da upalis "slow query log" koji setujes na 5 sekundi i pokupis sve upite duze od 5 sekundi i onda vidis sta mozes da uradis sa njima da uh ubrzas.... realno ima mnogo fora da se to ubrza, onaj upit koji si ovde bacio je jednostavan ali ga izvrsis mnooogo puta, onaj alternativni je bolji ali ako ima mnogo elemenata u IN()-u to ce da bude onda jos sporije .. jedan join tabele same sa sobom bi mozda bolje odradio posao .. sve zavisi kakva je sama tabela ..





 
Odgovor na temu

Skaarj
Novi Sad

Član broj: 21463
Poruke: 365
93.86.122.*



+3 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 07:31 - pre 182 meseci
Citat:

ne znam na sta ti lici baza ali velika je verovatnoca da ce ovaj group by upit da bude brzi od X*prvi upit.. cim imas group by mora da koristi temp tabelu sto nije problem.. to sto koristi filesort znaci da ne moze da odradi sortiranje po indexu - jel ti kolona "name" indexirana (po njoj radis group by) ?


upit ide po multicolumn indeksu definisanom sa
create index `idx_a` on `tab_a` (`name`(7),`datum`);

Ocigledno da GROUP BY ne koristi multicolumn indekse.

Sad sam dodao jos jedan index na test tabeli sa 10M redova
create index `novi` on `tab_a` (`name`) i sada u explain za GROUP BY upitu pise da koristi samo where, nema ni temp tabele ni filesorta...

Iskren da budem nisam obracao paznju na ovaj 'detalj' a moze da cini celiku razliku u nekim upitima.

Sad bas gledam neku statistiku koju generise phpMyAdmin (koji inace ne koristim ali nemam gde da vidim tako lepo prezentovane podatke) i ispada da je prosek na serveru nekih 50k konekcija na sat. E sad koliko njih pise a koliko cita to vec ne mogu da odredim.

Danas kad krene posao cu da gnjavim admine da postupe kako si predlozio pa cemo da vidimo kako ce da ispadne...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 07:53 - pre 182 meseci
Citat:

Ocigledno da GROUP BY ne koristi multicolumn indekse.


nije da ne moze, samo je optimizer odlucio da mu se ne isplati ... u svakom slucaju ovako je bolje


Citat:
Sad bas gledam neku statistiku koju generise phpMyAdmin (koji inace ne koristim ali nemam gde da vidim tako lepo prezentovane podatke) i ispada da je prosek na serveru nekih 50k konekcija na sat. E sad koliko njih pise a koliko cita to vec ne mogu da odredim.

imas u show global status razne podatke, koliko si imao ovakvih i onakvih upita .. nemas bas koliko kojih konekcija ali nije ni preterano bitno ... sa 50K konekcija na sat, sta da kazem, mnooogo bi vam znacio merlin :( .. al znam da vam se ne daje 8000E godisnje .. posto je jedini nacin da se dobije merlin uz support paket .. (ok, tu bi dobili ekstra support za optimizaciju i servera i upita, i enterprise binaries i .... i .... ali vama treba samo merlin :( )

Citat:
Danas kad krene posao cu da gnjavim admine da postupe kako si predlozio pa cemo da vidimo kako ce da ispadne... :)

reci im da odrade upgrade - to je bitno, sve ostalo je mnogo manje bitno

inace, ima fora za myisam tabele kada se kreiraju da se kaze da indexi bufu na drugom mestu .. to je u slucaju da ima vise spindlova mnooogo iskusna stvar, al to ne mozes da radis na live serveru
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 10:40 - pre 182 meseci
zaboravih, pre upgrade-a pogledaj:

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-28.html
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-29.html
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-30.html
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-31.html
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-32.html

posto ne koristis InnoDB vecina stvari te ne dotice, ali posto koristis replikaciju, moraces da odradis update na oba servera .. pogledaj promene od tekuce verzije do .32 pre upgrade-a
 
Odgovor na temu

Skaarj
Novi Sad

Član broj: 21463
Poruke: 365
93.86.122.*



+3 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 11:16 - pre 182 meseci
Stvarno si od velike pomoci. :)

Bas sam sada proveravao da li ima tabela koju se u InnoDB u bazama na serveru jer mi global status prikazuje da Innodb_row_inserted i Innodb_rows_read nisu nula ali kako stvari stoje nema nijedne. Moguce da je u nekom momenu u zadanjih 100 (koliko je trenutni uptime) dana postojala neka tabela kratko koja je ili obrisana ili konverotvana. Tako da cu da preoprucim adminima da eliminisu InnoDB kao opciju.

Ono sto nisam znao je da je u MySQL 5.1 moguce dinamiciki iskljucivati i ukljucivati slow_log i general_log pri tome ih jos pisati u tabelu u bazi. To je za mene stvarno velika novost i odlicna stvar.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 11:49 - pre 182 meseci
Citat:

Ono sto nisam znao je da je u MySQL 5.1 moguce dinamiciki iskljucivati i ukljucivati slow_log i general_log pri tome ih jos pisati u tabelu u bazi. To je za mene stvarno velika novost i odlicna stvar.


obrati samo paznju na to da to utice na performanse i da nije bas extra brzo ... ali ... radi dinamicki :)
 
Odgovor na temu

Skaarj
Novi Sad

Član broj: 21463
Poruke: 365
93.86.122.*



+3 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 12:18 - pre 182 meseci
To mi je potpuno jasno. Ali je velika stvar da mogu po potrebi da ukljucim logovanje makar na 10-15 minuta da vidim sta se desava bez da cimam admine za to.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: MySQL (relativno) velika baza24.03.2009. u 12:22 - pre 182 meseci
kako bih ti rekao, to je stvar za koju support tim kuka godinama i koju smo najzad dobili u 5.1 tako da ... sta reci ... ne radi dobro kao sto smo mi predlagali, ne radi sve sto smo trazili, ali je mnoooooooooooooooooooooooooogo bolje od resetovanja servera da bi se upalio log :)
 
Odgovor na temu

[es] :: MySQL :: MySQL (relativno) velika baza

[ Pregleda: 2434 | Odgovora: 13 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.