OK, najupecatljivije iskustvo sa particionisanjem sam imao pre jedno pet godina na SQL 2000 u reinsurance firmi. Sve transakcione informacije sa berze (nije stock beza ali ipak je bilo oko 50,000 transakcija dnevno, skoncentrisanih tokom radnog vremena) su se slivale u OLTP bazu gde su se vezivale za ostale sirove analiticke podatke i to je posle sluzilo kao osnova za razne analitcke primene, od reportinga do OLAPa. Problem im je naravno bio taj sto su cesti inserti do zla boga usporavali bilo kakvu analizu, ceste analize su eskalirale u table S lockove i blokirale inserte, itd. i hteli su resenja ali nisu hteli nikako da imaju read uncommited transakcije na toj OLTP bazi.
Mi smo se nazalost svi poveli tom pricom o particionisanju na SQLu koja je tad bila u povoju i koja je obecavala taj sveti gral, jeftine S lockove na istoriji. Sa tim sto je u ono doba to bilo jos gore jer SQL 2000 nije imao fabricku podrsku za particionisanje. Radilo se tako sto sam pravis istorijsku i aktivnu tabelu, upis radis direktno nad aktivnom particijom a select radis nad view koji radi union baziran na WHERE koji sece opseg. Ni danas particiona funkcija ne radi nista drugacije iza kulisa sem sto imas bar neku pomoc oko reparticionisanja sto smo mi sve morali da radimo "rucno". Medjutim, uprokos teoriji i operativnim problemima, praksa je pokazala da nije bas sve tako sareno ni u resavanju osnovnog problema.
1. Query optimizer NE MOZE da iskljuci particiju iz execution plana ako WHERE sekcija nije direktan podset partition raspona, pa se svi queryji koji to striktno ne ispune svode na duplo vise aktivnost da se skeniraju indexi i tabele obe particije, cime se vracas na pocetak. Situacija se dalje pogorsava svim mogucim analizama koje nisu bazirane na vremenu vec na ostalim entitetima (npr analiza bazirana na kupcu) i dodatno pogorsava sa svim queryjima koji imaju datumski opseg u OR operaciji. Bukvalno smo dosli do toga da smo morali da teramo analiticare da unose <danas(0:0) za datetime u izdvojenoj AND stavci za svaki report bez obzira dal je baziran na datumima (sto nije bas docekano sa odusevljenjem jer neki reporti nisu bili uopste jednostavni). Ali ne lezi vraze, nisu oni svi kucali SQL nego su koristili analiticke aplikacije pa je dosao sledeci problem:
2. Dok god postoji iole mogucnost da where sekcija pokrije obe particije i sam execution plan ce pokrivati obe particije, cak iako je output iz jedne particije 0 redova. A to je problem sa ustaljenom praksom pisanja parametrizovanih query-a (a gro analitickih aplikacija to radi) i precompiled planova. Dakle cak iako aktuelna vrednost parametra uvek pada samo u jednu particiju obe ce ucestvovati, sto smo otkrili na tezi nacin. Samim tim particionisanje nije uradilo nista jer iako je execution plan radio union praznog seta da bi uopste dobio prazan set morao je da pravi IS/S lockove u aktivnoj tabeli i opet je morao da ceka na U,D,X i njihove derivate. Sad, moram da se ogranicim da nisam proverio ovaj problem na SQL 2005+, moze da se desi da je problem resen, ali jedino resenje koje postoji je da se execution plan ponovo kompajlira svaki put za query-je koji imaju vise od jedne particije sto onda kompletno ubija celu poentu execution plan kesiranja, tako da sumnjam.
E sad najbolji deo price. Problem se na kraju ispostavio da i ne postoji, samo je trebalo vratiti se na dizajn sistema i saslusati use-cases. Kad smo konacno uspeli da popricamo sa stakeholderima utvrdjeno je da apsolutno niko od korisnika podataka NE koristi aktivni set podataka (nisu traderi i ne rade midday analize). Problem je resen bukvalno razvodom istorije i aktivnog seta i primenom "rucnog" federated server principa
. Job je tokom noci posle zatvaranja berze pretabao sve dnevne transakcije u dnevni backup i u batch operaciji dodao na ostale podatke u drugu istorijsku bazu koja je bila odskocna daska za sve ostale analize, aktivni set se onda resetuje i ceka sledeci dan. Posto vise nije bilo dnevnih UDX lockova na istorijskoj bazi nisu nam trebali ni S lockovi (dakle ova baza je mogla da ide u read uncommited) i sve je prosljakalo kako treba i optimalnom brzinom.
Samim tim zazirem od internih particija i smatram da postoji veoma mali broj slucajeva kad su one zaiste primenljive i neophodne. Za federated servere bih jos i nasao primenu u nekim scenarijima (za gornji priemer bi mi dobro dosao) ali ovako interno cepanje na filegrupe po samo jednom opsegu (najcesce istorijski po datumu) i u situacijama kad nemas puno istorisjkih selecta mi deluje kao vise problema nego koristi. Ljudi misle da im je interno particionisanje resenje a u stvari imaju na raspolaganju mnogo bolja, efikasnija i kvalitetnija resenja, samo treba trezvenije da pridju problemu. Da ne ulazimo u situacije kad problem uopste i ne postoji tipa transkacionih tabela sa 100 transakcija dnevno u kojima se izvestaj pravi jednom mesecno i slicno.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Horizontalno Particioniranje
