particioniranje po koloni

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?

Potpis

Acta, non verba!

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)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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...

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?

Potpis

Acta, non verba!

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/