SAVJETI

Optimizacija baza podataka

Particioniranje podataka
Ako standardne
metode
optimizacije više
nisu dovoljne,
vrijeme je za
particioniranje kao
posljednju liniju
obrane

RIKARD PAVELIĆ

B
aze podataka su ključ-
ni dio poslovnih su-
stava. Velike količine
podataka koje sadrže zahti-
jevaju sve više računalnih
resursa. Česta je pojava da
sustav toliko naraste da nje-
govo opterećenje prijeđe pri-
hvatljive granice. Najčešći je
uzrok neiskustvo ili neznanje Raspodjela podataka po
programera i arhitekata tog particijama i potparticijama.
sustava, čiji se dizajn i im- Svaka particija ide na
plementacija ne mogu nositi zasebni disk
za zahtjevima postavljenima
sustavu. Uglavnom se skoro
mjenama nekih metoda optimiza-
svi problemi mogu riješiti primjenama optimiza se baza nalazi može se otprilike zaključiti koliko je razvijeno
cije, ali one zahtijevaju znanje i iskustvo u rješavanju raznih particioniranje u pojedinom SQL serveru. U DB2 i Oracleu, koji
optimizacijskih problema. Također je vrlo bitno poznavanje prevladavaju na vrlo velikim bazama, particioniranje je daleko
baze podataka jer zbog različitosti arhitektura neke optimizacije razvijenije nego u MS SQL Serveru i PostgreSQL-u, koje često
primjenjive na jednoj bazi nisu primjenjive na drugim bazama. barataju s bazama manjima za red veličine.
Particioniranje je metoda optimizacije koja se uglavnom po-
sljednja primjenjuje. Ona se primjenjuje tek kada se pojavi Vrste particioniranja
potreba za njom, tj. kad ostale optimizacije više nisu dovoljne Particioniranjem zovemo podjelu baze ili njenih elemenata na
da bi se obrada podataka mogla smatrati dovoljno brzom. Zbog različite nezavisne dijelove. Prema načinu podjele postoje hori-
različitih arhitektura baza i stupnjeva razvijenosti particioniranje zontalno i vertikalno particioniranje. Vertikalno particioniranje
nije moguće jednostavno izvesti na mnogim sustavima, a često se često ni ne smatra particioniranjem, već samo normalizaci-
implementacija particioniranja zahtijeva odustajanje od nekih jom tablice. Da bi particioniranje bilo uspješno, prilikom upita
kritičnih mehanizama osiguranja koje baze pružaju (poput refe- baza mora moći isključiti nepotrebne particije iz analize podata-
rencijskog integriteta). U skladu sa segmentom tržišta na kojem ka. Time će se smanjiti skup podataka koji je potrebno obraditi,

PREDNOSTI I MANE PARTICIONIRANJA

Prednosti particioniranja mogu se podijeliti na nekoliko osnovnih grupa: Prilikom particioniranja, treba biti svjestan i raznih mana:

Brzina upita - ako se većina pretraživanja nad podacima izvodi nad manjim
skupom podataka, stvaranjem particija po tim skupovima upiti će se brže
izvoditi i manje opterećivati server.
Brisanje podataka - particije se mogu dijeliti na aktivne i pasivne, s
tendencijom da se pasivne particije s vremenom gase. Brisanje podataka
uklanjanjem particija brzo je i bezbolno.
Dodavanje podataka - dodavanje novih podataka kroz dodavanje novih
particija ne smanjuje performanse upita koji trenutno rade nad podacima.
Održavanje - ako postoji procedura za održavanje particija, održavanje baze
podataka postaje puno brže i jednostavnije. Paralelno defragmentiranje tablica
ili indeksa mnogo slabije utječe na performanse sustava.
Kompleksnost - ako ne postoji ugrađen način ili je potreban neki specifični
način za održavanje particija, potrebno je izgraditi podršku za izgradnju i izmjenu
particija. Particioniranje je potrebno testirati na stvarnim podacima da bi se
mogao odrediti najbolji način za particioniranje. Iz tog se razloga particioniranje
radi tek kada se pojavi potreba.
Ograničenja upita - da bi upiti iskoristili particije na najbolji mogući način,
potrebno je u njih ugraditi particijske ključeve, inače će raditi nad cijelim
skupom podataka, pa particioniranje neće imati utjecaja (ili će dodatno
smanjiti performanse).
Denormalizacija dizajna - particioniranje uglavnom pretvara normalizirani
dizajn u denormalizirani, tako da je potrebno voditi računa o određenim
redundancijama, gubljenima ograničenja ili ručnim implementacijama
određenih ograničenja.

92 veljača 2009. MREŽA

 Particioniranje u primjeni: POSTGRESQL
PostgreSQL koristi nasljeđivanje kao osnovu za particioniranje. Particioniranje
što će za posljedicu imati manje opterećenje diska, memorije i se uključuje postavljanjem postavke constraint_exclusion na vrijednost on.
procesora. Stvaranje osnovne tablice “računi” i dvije particije:
Horizontalno particioniranje ili particioniranje po redcima jest
podjela podataka u kojoj se različiti redci nalaze u različitim ta- CREATE TABLE racuni
blicama (koje nazivamo particijama tablice). Korištenjem unije (
nad razdvojenim podacima dolazimo do ukupnog seta podataka. godina INT,
Kod spajanja podataka unijom performanse će biti skoro identične redni_broj INT,
kao i kod čitanja iz jedne velike tablice ako se particioniranje radi datum DATE,
unutar istog servera. Česta je primjena horizontalnog particionira- ukupni_iznos NUMERIC(20,2)
nja razdvajanje podataka po serverima, što se u praksi zove distri- );
buirano particioniranje. Distribuirano particioniranje nije pogodno
za upite gdje je potrebno unirati sve podatke, ali zato drastično CREATE TABLE racuni_2007
ubrzava upite kod kojih se upit usmjerava na samo jednu particiju. (
Vertikalno particioniranje ili particioniranje po kolonama jest PRIMARY KEY(godina, redni_broj),
podjela podataka u kojoj se stvaraju dodatne tablice da bi se za- CHECK(godina=2007)
pisali svi redci određenih kolona. Česta je praksa da se stvaraju ) INHERITS (racuni);
tablice grupirane po namjeni i vrsti kolona, npr. podjela tablice
na aktivne i arhivske podatke. U aktivnim podacima zapisuju CREATE TABLE racuni_2008
se svi “živi” podaci, a u arhivsku tablicu zapisuju se “trenutne (
kopije” podataka (u aktivnu tablicu zapisujemo šifru klijenta, a u PRIMARY KEY(godina, redni_broj),
arhivsku naziv i adresu klijenta). Prilikom vertikalnog particionira- CHECK(godina=2008)
nja mora se paziti da spajanje tablica ne bude skupa operacija na ) INHERITS (racuni);
toj bazi te da razni izračuni i obrade koriste što manji broj tablica.
Postoje tri glavna kriterija za podjelu podataka po kojima se Plus pravila za unos:
radi horizontalno particioniranje: raspon podatka, lista i hash
funkcija. Kombiniranje različitih metoda zove se kombinirano CREATE RULE unos_racuna_2007 AS
particioniranje. Primjerice, može se prvo particionirati po ras- ON INSERT TO racuni
ponu, a zatim pomoću hash funkcije. Usporedba mogućnosti WHERE (godina = 2007)
pojedinih baza pokazuje da MS SQL Server i PostgreSQL mo- DO INSTEAD INSERT INTO racuni_2007 VALUES(NEW.*);
gućnostima zaostaju particioniranja iza Oraclea. Particioniranje
je moguće izvesti u MS SQL-u 2000 izradom pogleda koji uni- CREATE RULE unos_racuna_2008 AS
raju tablice. U MS SQL-u 2005 uvedena je mogućnost particio- ON INSERT TO racuni
niranja u rasponu, dočim MS SQL 2008 nije unio velike novosti WHERE (godina = 2008)
u particioniranje, već je samo popravio neke interne probleme DO INSTEAD INSERT INTO racuni_2008 VALUES(NEW.*);
koji su se pojavljivali. PostgreSQL ostaje vjeran BSD idealima,
pa tako podržava sve tri metode particioniranja i kombinirano Nakon toga se upiti ovog tipa mogu optimizirati:
particioniranje, ali nema out of the box rješenja, već su pro-
grameri primorani raditi skripte za svaku metodu. To ponekad select * from racuni where godina < 2008
ima i svojih prednosti, primjerice kod detaljnih prilagodbi po-
našanja pojedinih dijelova particija. Oracle, osim što podržava a unosi završavaju na pravom mjestu:
sve metode i kombinirano particioniranje, pruža programerima
i mogućnost referencijskog particioniranja. Vjerojatno najveća INSERT INTO racuni VALUES(2008, 1, current_date, 10200);
razlika jest postojanje globalnih indeksa u Oracleu koji se mogu
rasprostranjivati preko nekoliko tablica, tako da razna ograniče-
nja u particioniranju zbog matematičke točnosti implementacije
kod drugih baza nisu prisutna u Oracleu.

Particionirati ili ne?

Podaci se ne bi trebali particionirati dok se za to ne ukaže po-
treba. Nakon što se pojavi potreba za particioniranjem podataka,
potrebno je pronaći najbolji način za primjenu particioniranja.
Često se nad istim sustavom kod različitih klijenata različito
particionira ista vrsta podataka. Postoji i nekoliko pravila kojih
se dobro držati da bi se kasnije moglo particionirati. Recimo,
poželjno je stvarati poglede nad tablicama tako da se interne
izmjene u pogledu ne vide izvana. Potrebno je poznavati mo-
gućnosti i ograničenja SQL servera u korištenju particioniranja.
Primjerice, u MS SQL Serveru 2000 i PostgreSQL-u moraju se ra-
diti alternativni načini za održavanje referencijskog integriteta. U
MS SQL-u particijska kolona mora biti dio jedinstvenih (unique)
ključeva, što u praksi znači izmjenu velikog broja relacija. Neke
aplikacije (poput Microsoft Dynamics NAV nad MS SQL Serve-
rom) ne održavaju referencijske integritete u bazi (što stručnjaci
uglavnom ne preporučuju), čime pokušavaju ubrzati izmjenu
podataka, pa se njihova baza može jednostavno particionirati Isključivanje nepotrebnih particija iz upita. U planu nema analize particije
jer razna ograničenja za particioniranje više ne postoje. racuni_2008.
Postoji velik broj optimizacija koje treba iskoristiti prije nego
što se krene u particioniranje. Ako ni uza sve te optimizacije
brzina sustava nije zadovoljavajuća, vrijeme je za particionira- ji planiranjem
jim l i j i izvršavanjem
i š j i Ako
upita. Ak veličina
liči baze
b ne pre-
nje. Treba biti svjestan da nema univerzalnog načina ispravnog lazi raspoloživu memoriju, particioniranje vjerojatno neće imati
particioniranja, ali i da je prethodno iskustvo u particioniranju značajnog utjecaja na sustav. S količinom memorije dostupne
presudno da bi se particioniranje uspješno implementiralo. današnjim serverima, velika većina sustava spada u tu katego-
Određena kompleksnost koja se uvodi u sustav vjerojatno će biti riju. Ipak, nije loše eksperimentirati, ako ni zbog čega drugog, a
puno manja od pozitivnih promjena koje će se dogoditi drukči- onda zbog prikupljanja znanja i iskustva.
MREŽA veljača 2009. 93