Inbunatatirea performantei - baza de date

Inbunatatirea performantei - baza de date

Fiecare din aceste transformari intre tabele si relatii de baza incearca sa inbunatateasca performanta bazei de date, reducand volumul datelor transferate la/ de la memoria secundara si reducand cerintele de comunicatii intr-o retea de calculatoare.

Atunci cand se dezvolta o structura eficienta a bazei de date fizice mai trebuiesc luate si alte decizii:

Accesul la atribut: care atribute trebuie sa aiba cai de acces rapide preconstruite?

Reuniuni preconstruite: care reuniuni intre relatiile de baza trebuie sa aibe cai de acces rapide preconstruite?

Buffere: cat de mare trebuie sa fie spatiul buffer pentru a transfera relatiile de baza intre memoria principala si cea secundara?

Gruparea relatiilor fizice: ce relatii de baza ar trebui memorate impreuna in acelasi fisier?

1. Accesul la atribut.

Multe in DBMS-urile relationale permit proiectantului bazei de date sa specifice care atribute vor avea cai de acces rapide preconstruite. Aceste atribute sunt acelea pentru care utilizatorii specifica valori atunci cand ei doresc sa acceada anumite linii din tabela.

Proiectantul bazei de date analizeaza patternurile de acces la tabela, determinand cat de frecvent urmatorul tip de acces este specificat:

SELECT lista de nume de atribute

FROM nume tabela

WHERE nume atribut1 = valoare1

AND nume atribut2 = valoare2

AND

Cu cat apare mai frecvent un nume de atribut in clauzele WHERE a cererilor de regasire si de actualizare, cu atat mai mult trebuie spre el o cale de acces rapida preconstruita. Prezenta unei astfel de cai poate afecta semnificativ performanta bazei de date.

Prelucrarea unei cereri care califica liniile pe baza valorilor atributelor pentru care nu exista cale de acces rapid implica tipic o analiza secventiala a portiunii bazei de date continand tabela ceruta.

Intr-o incercare de a inbunatati performanta pentru cererile urmatoare, anumite DBMS-uri construiesc si memoreaza automat cai de acces rapid atunci cand o cerere califica liniile pe baza unui atribut care nu a avut deja o cale preconstruita.

Caile de acces rapid preconstruite sunt implementate fie prin structuri de indecsi, fie prin "hashing" pe valorile atributului desemnat. Structurile de indecsi sunt, in general, variante ale structurilor B-arbori (vezi cap.10). Structurile hash sunt calcule de adrese pe bucati sau pe blocuri dintr-un fisier (de asemenea prezentate in cap.10). In majoritatea DBMS-urilor comerciale, numai un atribut al unei relatii de baza poate avea o cale de acces rapid preconstruita prin hashing. Valorile acestui atribut determina locatiile de memorie ale liniilor relatiei. In contrast, multe din atributele unei relatii de baza pot avea cai de acces rapid preconstruite implementate prin structuri de indecsi. Fiecare structura de index pointeaza la o multime de linii din relatie, in concordanta cu valorile de atribut ale acestor linii.

Atributele care cer cel mai adesea cai de acces rapid preconstruite sunt atributele de cheie primara, atributele de cheie alternata si atributele de cheie straina.

Atributele de cheie primara trebuie sa aiba aproape intotdeauna cai de acces rapid preconstriute. Identificatorul unic al unei linii al tabelei este in general folosit in cererea de acces la acea tabela. Daca o relatie de baza are calea de acces rapid preconstruita implementata ca si o functie hash, atunci acea cale de acces este intotdeauna implementata pe atributul de cheie primara.

Daca cheia primara este compusa, atunci calea de acces rapid este construita pe multimea de atribute care alcatuiesc cheia primara. De exemplu, daca cheia primara este COD_DIVIZIE, ID_DEPARTAMENT atunci hashingul sau indexarea se face pe combinatia celor doua atribute. Calea de acces cheie primara nu ar fi implementata corect cu un index pe COD_DIVIZIE si un alt index pe ID_DEPARTAMENT.

Atributele de cheie alternata pot avea cai de acces rapide, daca ele sunt folosite in comun in loc de cheie primara pentru accesul la tabela. De exemplu, ANGAJAT# este cheia primara a tabelei ANGAJAT, dar cheia alternata SSN# este mai folosita pentru a califica liniile, atunci pot exista o cale de acces la ANGAJAT# si una la SSN#. Utilizatorii pot astfel accesa usor datele din ANGAJAT bazandu-se pe oricare din cele doua atribute.

Atributele de cheie straina pot avea cai de acces rapid preconstruite daca  valorile lor sunt folosite uzual pentru a califica liniile tabelei si/sau daca tabela este reunita frecvent cu tabela in care atributul de cheie straina apare ca si cheie primara. Cele doua tabele pot fi reunite mai eficient daca exista indecsi pentru atributele de reuniune.

Alte atribute pot avea cai de acces rapide daca indeplinesc toate conditiile urmatoare:

valorile lor sunt folosite in mod obisnuit pentru a califica linii.

valorile lor nu sunt actualizate frecvent.

valorile lor sunt discriminatorii.

Mentinerea unei cai de acces rapid pentru un atribut ale carui valori se actualizeaza des este costisitoare. Daca un atribut este indexat, atunci de fiecare data cand valoarea lui se schimba pentru linie, structura de index trebuie modificata. Daca liniile sunt in "hashing", atunci schimband valoarea atributului hash aproape intotdeauna apare necesara si o mutare a inregistrarii liniei.

Un atribut discriminator este unul pentru care un procent relativ mic din liniile tabelei au o valoare particulara a acelui atribut. De exemplu, in relatia ANGAJAT, atributul COD_SEX nu este un atribut discriminator, caci exista doar doua valori posibile pentru acest atribut. Astfel construind un index dupa COD_SEX ar fi costisitor si nu va reduce numarul de inregistrari analizate ca raspuns la o cerere utilizator. Pe de alta parte, COD_JOB probabil sa este un atribut discriminator. Daca exista 100 de valori posibile pentru COD_JOB, atunci un index care suporta accesul direct pe COD_JOB reduce o cautare la 1% din inregistrari.

2. Reuniuni preconstruite.

Un alt mod de a inbunatati performanta este de a construi cai de acces rapide la tabele JOIN (reuniune) inainte de a primi cererea utilizatorului pentru reuniune. Reuniunea a doua tabele mari poate fi un proces consumator de resurse, caci pentru fiecare valoare a atributului de reuniune dintr-o tabela trebuie gasita linia cu valoarea atributului de reuniune din cealalta tabela. Daca aceasi reuniune va fi ceruta in viitor, atunci retinand corespondenta dintre cele doua tabele, evitam refacerea potrivirilor.

Corespondenta dintre tabelele reunite poate fi retinuta in mai multe moduri, incluzand:

un director cu valori atribut - reuniune, cu pointri la liniile pertinente din fiecare din cele doua tabele (fig.11.8).

liste inlantiute, cu un lant de pointeri de la fiecare linie dintr-o tabela la liniile potrivite din cealalta tabela (fig.11.9).

Nu toate DMBS-urile relationale suporta reuniuni preconstruite. Proiectantul bazei de date fizice trebuie sa determine care reuniuni ar putea fi preconstruite, pe baza beneficiilor prezise.

DIRCTOR

R

S

B	D	E
b1	d1	e1
b2	d2	e2
b3	d3	e3
b4	d4	e4
b5	d5	e5

Fig.11.8. Director continand valorile atribut - reuniune cu pointeri la doua tabele de baza. Relatiile R si S sunt reunite prin atributul B.

S

R

Fig.11.9. Lista inlantiuta de reuniuni preconstruite pe atributul B in relatiile de baza R si S.

3. Buffere.

O alta cerinta este gestionarea bufferelor pentru transferul relatiilor de baza intre memoria principala si cea secundara. Multe DBMS-uri relationale dau proiectantului bazei de date posibilitatea de a specifica marimea fiecarui buffer si numarul de buffere. Obisnuit, marimea unui buffer este aceasi cu marimea unei pagini din memoria principala, care este determinata de catre sistemul de operare. Numarul de buffere trebuie sa fie suficient de mare pentru a pastra in memoria principala setul de lucru de linii folosite in servirea unei cereri, aceasta depinzand de caracteristicile cererii si de continutul bazei de date.

4. Gruparea relatiilor de baza.

Un DBMS relational foloseste posibilitatile sistemului de gestiune a fisierelor din sistemul de operare pentru a memora si accesa relatii de baza. Un fisier este intr-un spatiu de adrese compus dintr-o colectie de pagini de aceasi marime si poate sa fie rezident in memoria principala sau secundara. Astfel de fisiere se folosesc pentru a memora datele utilizator, structurile de date pentru caile de acces, date din directorii interni, rezultate intermediare generate ca raspuns la interogatii.

Managerii bazelor de date relationale difera prin modul in care ei mapeaza aceste relatii in fisiere:

o relatie de baza - un fisier. Fiecare fisier contine linii dintr-o relatie de baza si o relatie de baza apare intr-un singur fisier.

N relatii de baza - un fisier. Fiecare fisier contine linii din mai multe relatii de baza, dar fiecare relatie de baza apare intr-un singur fisier.

N relatie de baza - M fisiere. Fiecare fisier contine linii din mai multe relatii de baza si fiecare relatie de baza poate apare in mai multe fisiere.

o relatie de baza - M fisier. Fiecare fisier contine linii dintr-o relatie de baza, dar o relatie de baza poate apare in mai multe fisiere.

Schema care este folosita este determinata de catre DBMS si nu de catre proiectantul bazei de date fizice. Cunoasterea ei ajuta proiectantul in luarea de decizii.

Daca un fisier contine linii din mai multe relatii de baza, atunciproiectantul bazei de date poate grupa acele date care se pare ca se vor accesa impreuna. De exemplu, daca tuplele din doua relatii de baza sunt frecvent accesate impreuna, sa spunem din cauza unui join intre ele, atunci proiectantul trebuie sa ia in considerare posibilitatea de a le memora impreuna. Astfel vor fi necesare mai putine accese la memoria secundara pentru a raspunde cererilor de date.

Daca tuplele din doua relatii de baza sunt numai rar accesate impreuna, atunci ele trebuie memorate in fisiere separate. Obiectivul este de a grupa pe o pagina tuplele care par a fi accesate impreuna. O alta posibilitate pentru gruparea fizica este de a plasa pe o aceasi pagina liniile care par a fi accesate impreuna. Aceste linii pot fi de la aceasi relatie sau de la relatii diferite, presupunand ca un fisier poate memora mai multe de o relatie. Gruparea fizica este facuta uzual, de:

valoare atribut, astfel ca liniile cu valori similare pentru un atribut desemnat sunt memorate impreuna.

timpul de memorare, astfel ca liniile pot fi regasite fie in secventa FIFO, fie in sceventa LIFO.

asociatie, astfel incat ocurentele entitatii fiu sa fie memorate aproape de ocurenta entitatii lor tata.

5. Dimensionarea fisierelor.

Fiecarui fisier trebuie sa i se aloce suficient spatiu pentru a incapea relatiile sale in viitorul imediat plus cel putin 20% spatiu liber. Alocarea de spatiu aditional la un fisier poate fi scumpa, in special daca utilizatorilor li se interzice sa acceada datele in timpul reorganizarii. Prea mult spatiu inseamna a plati pentru exces de capacitate, iar prea putin spatiu inseamna a nu gasi spatiu pentru noile tuple si a manui depasirile din pagini pline.