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?