[ bjevta @ 30.03.2012. 19:33 ] @
imam jednu InnoDB tabelu u kojoj ima kolona `status`. ti (workflow) statusi se menjaju tokom life-cycle entiteta da bi na kraju postali `processed` posle toga skoro nikad vise ne menjaju status (ostaju `processed`).

status nikako nije deo primarnog kljuca, jedino sto bi mogao da bude deo nekog unique kljuca. statusa moze da bude 15-ak i definisani su u kodu (enumerator).

primarni kljuc tabele je autoincrement. colona `status` je varchar(20).

pitanje: da li je moguce isprarticionisati tabelu tako da u jednoj particiji budu samo zapisi sa statusom `processed` a u drugoj svi ostali zapisi?
[ bogdan.kecman @ 30.03.2012. 22:38 ] @
ako hoces da particionioses po status - moras da dodas status u pk

treba da napravis tabelu status sa status_id i status_name a u tvojoj tabeli da imas stamo status_id i to da ti bude deo pk-a (da ne bi gurao bespotrebno varchar u pk)
[ cheetah @ 11.04.2012. 19:48 ] @
Lepo objasnjeno.

Svakako procitaj dokumentaciju o particionisanju, po kojim kriterijumima moze da se particionise itd. jer ces lako naci primenu, kao sto je Bogdan rekao.

Mi smo uspeli da u tabelu sa preko 600.000.000 rekorda (da, 600 miliona), isparticionisemo po datumu, jer smo imali zahtev da se dnevno importuje oko 10.000.000 novih rekorda, i da se obrisu stari, tako da u bazi uvek ostane samo zadnjih 60 dana podataka.

Pre partticionisanja, brisanje (where date < nekovreme) je trajao preko 3h ! Nakon particionisanja trajajo je nesto vise od 0 sec, jer radimo truncate cele particije.
Select nesto where datum od-do, je trajao podosta, nakon particionisanaja, traje nesto vise od 0sec :)
Uz sve to velicina baze od blizu 100GB, InnoDB, a server svega 8GB rama...

Cudno je sta sve moze da se postigne uz malo truda...

[ bjevta @ 12.04.2012. 08:07 ] @
nisam ovih dana radio na tome ali, hvala, na info.

problem je sto sada imam primarni kljuc koji je autoincrement i taj status po kome bih zeleo da particionisem.

status polje se menja tokom vremena (kako tece workflow) da bi dospelo u neku, skoro nepromenljivu fazu (nesto kao 'completed').

status polje treba da postane deo primarnog kljuca. u tom slucaju ne vidim svrhu autoincrement polja. ispada da je bolje da napravim kompozitni PK po koloni status i jednom od FK-ova, na primer: TARGET_ID + TARGET_PHASE_STATUS = PK

U pitanju su 2 tabele, TARGET (1) i TARGET_PHASE (many). TARGET_ID je autoincrement PK TARGET tabele.

sve ovo deluje prihvatljivo.

sad pitanje: da li ima smisla zadrzati autoincrement kolonu i kombinovati je sa STATUS kolonom u PK i napraviti efikasno particioniranje? ako da, kako treba organizovati PK i particije?

[ bogdan.kecman @ 12.04.2012. 08:17 ] @
auto_inc kolona ti ne treba ako sa ta dva druga polja mozes da jednoznacno definises slog, ako ne mozes onda moras da imas i auto_inc

pritom je znacajno da kada radis promenu

PK(auto_inc) -> PK(auto_inc, int)

dodas UNIQUE(auto_inc) da ti se ne bi desilo da imas dva sloga sa istim ID-om (auto_inc) a razlicitim statusom posto kapiram da bi to bilo pogresno stanje baze
[ bjevta @ 12.04.2012. 09:41 ] @
kako ja shvatam, ili autoincrement u PK bez particionisanja ili composite PK sa particionisanjem?