[ farmaceut @ 03.12.2011. 19:42 ] @
Veca transakciona tabela, prati poslovne promejne (klasicna struktura - id, datum, id_proizvoda, id_skladista, id_klijenta, kolicina, itd..., 2M redova godisnje, sa tendencijom na 5M. oko 400 korisnika kroz web aplikaciju)

Trenutno je particionisana po "id_skladista" skladista na ~50tak particija, jer se veliki broj upita odnosi na pojedinacno skladiste, i to odlicno radi. (mysql 5.5)

E sad, javlja se potreba za intenzivnijim upitima po drugom kriterijumu - "id_klijenta", te bi se sad javila potreba za dodatnim particionisanjem. Posto ne vidim da bi podparticije na postojecim particijama pomogle (jer se podaci koji ispunajvaju drugi kriterijum javljaju u najvecem broju postojecih particija ), pada mi na pamet:

1.) dodatni slave server - sa tabelom particionisanom po "id_klijenta", na koji bi preusmjerio sve selecte koji su pogodni. Ovo mi se cini najbolje rjesenje i znam da bi radilo ok, ali mi trazi jos jedan server, ups, sto povlaci javnu nabavku i silne komplikacije.... (vec postoji replikacija i slave, ali je preko spore veze prema drugoj lokaciji, vise kao backup)

2.) kopija transakcione tabele u istoj bazi, koja je drugacije particionisana i na koju bih opet preusmjerio odgovarajuce "select" upite, te "akrobacija" kroz aplikaciju ili sa trigerima, da kod inserta/update-a punim obe tabele. Ovo mi se cini kao jeftinije rjesenje (eventualno dodati jos 2 hdd-a za novu tabelu), ali nisam tako nesto probao...

Ima li neko bolje iskustvo/ideju/prijedlog?
[ bogdan.kecman @ 03.12.2011. 20:20 ] @
resenje sa dodatnim serverom je zanimljivo :D .. dupliciranje baze u lokalu - nije ..

a zasto ne odradis subparticionisanje? optimizer ce vaditi podatke iz samo onih particija koje rade posao to bi trebalo da ti sljaka skroz dobro

procitaj: http://dev.mysql.com/tech-reso...les/mysql_55_partitioning.html

obrati paznju na segment: "The counter-intuitive part: multiple columns"

[ farmaceut @ 03.12.2011. 22:33 ] @
Sistem predstavlja evidenciju potrosnje materijala u bolnici.
Prvi uslov "id_skladista" je 46 fiksnih vrijednosti (integer) i u stvari predstavlja odjele jedinice bolnice (kardio, djecija hirurgija, oftalmologija,...).
Trenutno je particinisano "BY LIST" nad "id_skladista", posto se uglavnom vrse upiti po kriterijumu odjeljenja (stanje, potrosnja, ulazi, izlazi).

Drugi uslov koji ce se uskoro poceti masovno koristiti (kada se sistem integrise sa medicinskim evidencijama) je "id_klijenta" (integer) i u stvari predstavlja pacijenta, i trenutno ima ~15.000 razlicitih vrijednosti, te bi po bogdanovoj preporci isla na "HASH" subparticije.

Pacijent se tokom boravka krece po razlicitim odjelima, ali karton i izvjestaj po pacijentu se uzima zbirno za sve, np.:

SELECT sum(kizlaz) FROM tabela WHERE id_pacijenta = 5455

Malo sam testirao, i u explain dobijem da koristi p1_p1sp4,p2_p2sp4,p3_p3sp4,p4_p4sp4,p5_p5sp4,..... p46_p46sp4

Tj. dobijem da je pretrazio u subparticiji svake particije koja ciji je HASH odgovarao uslovu (sto je i logicno, i po definiciji :).

Posto je maximalan broj particija po dokumentaciji 1024, prakticno bi se uklopio u:
46 part. x 20 subpart.= 920 subparticija
....
....
PARTITION BY LIST (id_skladista) SUBPARTITION BY HASH(id_klienta) SUBPARTITIONS 20
PARTITION p1 VALUES IN (1),
PARTITION p2 VALUES IN (2) ,
PARTITION p3 VALUES IN (3) ,
....
....
PARTITION p46 VALUES IN (46)

Prilikom upita po kriterijumu nad "id_klienta", za sva skladista, kostalo bi me 1/20 hard disk i/o u odnosu na sadasnje stanje, sto i nije tako lose.

Da li je "way to go", ili se moze nesto bolje?

(Moja ideja sa drugim serverom je bila da se maksimalno iskoristi HASH particionisanje nad "id_klijenta" za takve upite, sto bi mi u teoriji dalo 1/1024 hard disk i/o, ali bi to ostavio kao opciju za kasnije.)

svaki komentar dobro dosao, i hvala unaprijed!
[ bogdan.kecman @ 03.12.2011. 22:49 ] @
ja bi radio tako ...


SELECT sum(kizlaz) FROM tabela WHERE id_pacijenta = 5455

to ce uvek ici kroz pun kofer particija osim ako ne particionises po id_pacijenta, ali po nekom mom iskustvu bi trebalo da je varianta id_skladista, id_pacijenta ispod 10% losija od kombinacije da particionises direkt po id_pacijenta sto je po meni vise nego prihvatljiv overhead obzirom na dobitak koji dobijas za where id_skladista ..