Sisteme de Baze de Date Distribuite

DDoorriinn CCÂÂRRSSTTOOIIUU

EDITURA CONSPRESS

2013

Copyright © 2013, Editura Conspress şi autorul

EDITURA CONSPRESS este recunoscută de

Consiliul Naţional al Cercetării Ştiinţifice din Învăţământul Superior Lucrare elaborată în cadrul proiectului: "Reţea naţională de centre pentru dezvoltarea programelor de studii cu rute flexibile şi a unor instrumente didactice la specializarea de licenţă şi masterat, din domeniul Ingineria Sistemelor"

Descrierea CIP a Bibliotecii Naţionale a României

CÂRSTOIU, DORIN Sisteme de baze de date distribuite / Dorin Cârstoiu – Bucureşti : Conspress, 2013 Bibliogr. ISBN 978-973-100-272-9 004.43

Carte universitară

CONSPRESS B-dul Lacul Tei nr.124, sector 2,

cod 020396, Bucureşti Tel.: (021) 242 2719 / 300; Fax: (021) 242 0781

Sisteme de baze de date distribuite – Dorin Cârstoiu

1

Cuprins

1. Introducere ............................................................................................................................... 2

1.1. Regulile Date .................................................................................................................... 2

1.2. Avantaje si dezavantaje baze de date distribuite .............................................................. 8

2. Arhitectura unui Sistem de Gestiune pentru Baze de Date Distribuite (SGBDD) ................ 10

3. Proiectarea unei baze de date relationale distribuite ............................................................. 19

3.1. Fragmentarea .................................................................................................................. 19

3.2. Alocarea datelor ............................................................................................................. 22

3.3. Distribuirea datelor ......................................................................................................... 23

3.4. Considerente legate de transparenta ............................................................................... 25

4. Executia cererilor distribuite ................................................................................................. 27

4.1. Implicatiile fragmentarii asupra executiei cererilor ....................................................... 30

4.2. Executia tranzactiilor...................................................................................................... 32

4.3. Instructiuni SQL distribuite ............................................................................................ 39

4.4. Modalitati de ascunderea locatiei ................................................................................... 43

5. Replicarea in baze de date distribuite .................................................................................... 45

5.1 Capturarea actualizarilor ..................................................................................................... 51

5.2. Aplicarea actualizărilor .................................................................................................. 53

6. Baze de date distribuite NoSQL ............................................................................................ 55

6.2. Scurtă clasificare a bazelor de date NoSQL ................................................................... 56

6.3. Nivelul de stocare ........................................................................................................... 59

6.4. Baze de date orientate document .................................................................................... 60

6.4.1. MongoDB ............................................................................................................... 60

6.4.1.1. Operatii in MongoDB ...................................................................................... 61

6.4.1.2. Aspecte privind distribuirea ............................................................................. 63

6.5. Baze de date orientate coloana ....................................................................................... 64

6.5.1. HBase ...................................................................................................................... 66

Bibliografie ................................................................................................................................... 74


2

1. Introducere

Se constata in ultima perioada in tehnologia informatiei si implicit in domeniul bazelor de date

existenta a doua curente aparent contradictorii: centralizarea si respectiv distribuirea. Chiar daca

ambele urmaresc obtinerea unor avantaje, este cunoscut faptul ca pentru orice avantaj se plateste

un pret. Pentru baze de date centralizate avantajele majore sunt determinate de o buna integritate

a datelor cu redundanta minima, asigurarea consistentei prelucrarilor, gestiunea facila a

tranzactiilor cu respectarea stricta a proprietatilor ACID. Din perspectiva bazelor de date

distribuite, ca efect al descentralizarii, integritatea datelor, redundanta minima si indeplinirea

proprietatilor ACID trebuiesc relaxate fiind foarte greu de indeplinit, insa cresterea disponibilitati

constituie un avantaj major. Decizia de utilizarea a uneia sau alteia dintre solutii poate fi luata

doar dupa o atenta analiza a cerintelor aplicatiei, a dimensiunii bazei de date, a caracteristicilor

infrastructurii disponibile impreuna cu evaluarea performatelor globale pentru intregul sistem.

O baza de date distriuita (BDD) este reprezentata de o colectie de date partajate ce sunt

distribuite fizic pe nodurile unei retele de calculatoare. Gestiunea unei baze de date distribuite

este realizata de un sistem de gestiune al bazei de date distribuite (SGBDD), capabil sa opereze

cu baza de date similar cu un SGBD centralizat, fara ca utilizatorii sa cunoasca unde sunt

localizate datele pe care le acceseaza. Se mai spune ca baza de date este constituita din insule de

informatii distribuite. Dintre primele sisteme de baze de date distribuite amintesc

INGRES/STAR, versiunea distribuita a sistemului INGRES, SQL*STAR versiune distribuita a

sistemului ORACLE si R* versiune distribuita a sistemului DB2, toate versiunile fiind bazate pe

modelul traditional de baza de date relationala. In ultimul deceniu au fost dezvoltate baze de date

distribuite ce nu se bazeaza pe modelul SQL, numite si baze non SQL, prima implementare fiind

proprietara Google, cunoscuta si sub numele de BigTable, urmata de o serie de implementari

open source ca: framework Hadoop cu Hbase, Casandra, Dynamo, TorentDB, MongoDB etc.

1.1. Regulile Date

Pentru ca un sistem de gestiune al bazei de date sa fie cu adevarat distribuit, el ar trebui sa

respecte in totalitate cele 12 reguli introduse de C.J. Date in 1987 [Dat87]. Putem afirma ca

aceste reguli sintetizeaza motivele principale pentru care este necesara distribuirea datelor pe mai

multe calculatoare intr-o retea si constituie in acelasi timp si obiectivele principale ale unui

SGBDD. Cele 12 reguli formulate de Date se constituie ca o metrica de evaluarea a bazelor de

date distribuite, cu toate ca nu se cunoaste inca nici un produs care sa satisfaca toate aceste

cerinte. Sintetizate cele 12 reguli sunt:

Autonomia locala. Un sistem de baze de date distribuit trebuie sa ofere pentru fiecare

locatie implicata un grad inalt al autonomiei locale. Ca urmare, fiecare locatie trebuie

sa-si gestioneze propriile date si sa ofere functionalitate independent de celelalte

locatii. Chiar daca uneori, pentru o completa functionare, o locatie are nevoie de

datele pastrate la alte locatii, nu inseamna ca propria functionare este conditionata de

acele locatii. Existenta dependentelor functionale stranse duce la propagarea


3

conditionalitatilor astfel incat intregul sistem devine inoperabil. In realitate, acest

obiectiv nu este indeplinit 100%. Uzual, intre locatii exista o anumita ierarhie si intr-o

oarecare masura conditioneaza principiul autonomiei. De regula, sunt asigurate local

securitatea, functiile de backup si refacre.Conceptul este totusi putin relaxat chiar de

autor prin formularea: “autonomia locatiilor trebuie respectata in cea mai mare

masura posibila”.

Absenta unei dependente de o locatie centrala.Este de dorit ca toate locatiile sa aiba

aceleasi capabilitati. Chiar daca intre locatii exista o anumita ierarhie, nu trebuie

exagerat. Intr-un sistem distribuit nu trebuie sa existe o locatie raspunzatoare in

totalitate de realizarea unei anumite functii sau activitati. Nu putem avea un nod in

care sa se realizeze controlul centralizat al tranzactiilor, gestiunea centralizata a

interogarilor, gestionrea accesului concurent pentru intreg sistemul, rezolvarea

problemelor de concurenta etc. Absenta dependentei de locatia centrala poate fi

rezumata prin inexistenta unui singur dictionar de date. Dependenta totala fata de un

anumit nod este nedorita pentru ca ar supraincarca nodul si nu se asigura o

functionare normala, atat a nodului, cat si a intregului sistem. Locatiile dedicate duc

la cresterea cheltuielilor globale ale sistemului, dar si la disfunctionalitati pentru

intreg sistemul atunci cand un astfel de nod devine nefunctional.

Operare continua sau independenta la defectare. Obiectivul operarii continue se

refera la doua aspecte majore ce privesc indeaproape performantele sistemelor

distribuite, si anume: fiabilitatea si disponibilitatea. Fiabilitatea reprezinta capacitatea

unui sistem de a functiona fara intrerupere cu asigurarea unor parametri de calitate.

Sistemele distribuite, spre deosebire de sistemele tranzactionale, nu urmaresc

principiul atomicitatii. Acestea opereaza neintrerupt, chiar si in cazul aparitiei unei

defectiuni la componente sau la mediul de comunicatie. Disponibilitatea se refera la

aspectul functionarii sistemului pe o perioada prestabilita, fara posibilitatea ca, din

anumite motive, o parte din date sa fie inaccesibile. In principal cerinta presupune

capabilitatea de ajustare a bazei de date fara a necesita trecerea acesteia offline.

Multe baze de date permit actualizarea schemei locale si backup pentru date chiar cu

baza online. Faptul ca un nod s-a defectat nu inseamna ca datele care erau stocate pe

acesta nu vor mai putea fi accesate, intrucat prin relaxarea redundantei datele se

gasesc si la alte locatii. Este de dorit ca sistemul sa nu fie afectat de nici un incident si

capabilitatea de functionare sa fie mentinuta chiar si in timpul procedurilor de

mentenanta.

Independenta de localizare. Locul in care au fost stocate sau de unde sunt accesate

datele trebuie sa fie transparent, atat pentru utilizator, cat si pentru aplicatiile care

ruleaza. Utilizatorul trebuie sa se comporte in aceeasi maniera si sa fie servit de catre

sistem in consecinta, chiar daca el lanseaza cereri de pe nodul A, iar datele solicitate

se afla la nodul A, X sau Y. Acest principiu poarta uneori numele de “transparenta la

localizare”. Acesta se constituie in nivelul mediu de transparenta la distribuire, ceea


4

ce inseamna ca utilizatorul va sti ca relatia globala este fragmentata, si ce anume

contine fiecare segment, fara insa a cunoaste locul unde fragmentele sunt plasate.

Asadar, nu mai este suficienta o cerere adresata schemei globale, utilizatorul trebuind

sa precizeze si denumirea fragmentelor din care se vor extrage informatiile. Totusi,

operatorul nu trebuie sa fie preocupat de locul in care sunt distribuite fragmentele si

nici de faptul ca ar putea exista replici ale acestora.

Independenta de fragmentare. Spre deosebire de bazele de date centralizate, destinate

unui nod central, baza de date distribuita este impartita in fragmente ce sunt

distribuite pe toate locatiile sistemului. Aceste portiuni ale bazei globale se numesc

fragmente si datorita dimensiunii lor in raport cu sursa din care provin vor duce la

cresterea performantelor sistemului. Fragmentarea bazei de date are impact direct

asupra cresterii concurentei bazei de date, intrucat in momentul in care un utilizator

doreste sa faca o actualizare, va bloca pentru o scurta perioada de timp doar o mica

parte a unui fragment, deci o parte nesemnificativa a bazei de date globale.

Fragmentarea se poate face dupa diferite criterii, iar fragmentele rezultate trebuiesc

dispersate pe statiile de lucru astfel incat sa fie atribuite locatiilor la care este cea mai

mare nevoie. Mai mult, din fragmente in orice moment se va putea recompune baza

de date initiala. Daca aceste deziderate sunt realizate, utilizatorul nu va simti

niciodata ca ceea ce acceseaza el sunt de fapt fragmente stocate in diferite locuri si nu

baza de date in totalitate, aflata pe nodul local. Independenta de fragmentare

reprezinta elementul central al transparentei la distribuire. Chiar daca utilizatorul stie

ca datele sunt fragmentate, el nu trebuie sa se comporte diferit fata de un utilizator al

unei baze de date centralizate. El trebuie sa lanseze cereri identice cu cele de la bazele

centralizate, fara a trebui sa faca un efort suplimentar in a cauta si mentiona explicit

in interogare ce fragmente solicita si evident locatia acestora. Pentru acces la baza de

date distribuita se va consulta schema globala fara implicarea utilizatorului.

Transparenta la distribuire este asigurata prin transparenta la fragmentare. Din

punctul de vedere al utilizatorului nu prezinta importanta modul in care s-a facut

fragmentarea, locul unde sunt amplasate fragmentele si nici faptul ca unele dintre

fragmente pot avea replici in diverse locatii. In general bazele de date ofera suport

pentru fragmentarea pe orizontala, insa suport ineficient pentru fragmentare pe

verticala.

Independenta la replicare.Atat din motive de securitate cat si de disponibilitate a

datelor, anumite fragmente trebuie sa fie copiate la mai multe locatii. Aceste copii se

numesc replici sau reproduceri. Utilizarea replicilor si alocarea lor pe diferite locatii

trebuie sa fie facuta transparent fata de utilizator. Acesta trebuie sa fie in continuare

convins ca lucreaza de fapt pe intreaga baza care se afla stocata local. Acest lucru este

posibil daca replicile sunt plasate acolo unde sunt directionate frecvent cererile

specifice. Independenta de replicare se mai numeste si transparenta la replicare.

Conform acesteia, utilizatorul va trebui sa transmita cereri catre fragmente bine


5

delimitate, fara a fi obligat totusi sa cunoasca localizarea si nici faptul ca fragmentele

consultate ar mai avea si alte amplasari posibile in retea. Replicarea datelor scade

performantele atunci cand cererile trebuie sa se propage prin retea. Existenta

replicilor locale creste performanta accesului la date intrucat nu necesita comunicare

in retea. Daca se face actualizarea unei replici sunt posibile mai multe modalitati

pentru actualizarea tuturor replicilor. O replica poate fi actualizata sincron, prin

protocolul numit si commit in doua faze,cu efect actualizarea tuturor replicilor sau

asincron, atunci cand nu este necesar ca modificarile sa fie reflectate imediat in toate

replicile. Unele medii de baze de date ofera suport doar pentru replicare asincrona,

altele cer ca aplicatiile sa includa triggeri pentru actualizarea replicilor. Acest tip de

transparenta reprezinta ultimul nivel al transparentei la distribuire, foarte apropiat de

nivelul fizic.

Prelucrarea distribuita a interogarilor. De cele mai multe ori, atunci cand se

formuleaza o interogare, oricat de bine ar fi plasate fragmentele si replicile, rareori se

vor obtine interogari pur locale. Datele pe care in general, o cerere le solicita sunt

plasate in cel putin doua locatii diferite. Pentru a raspunde unei astfel de solicitari in

mod eficient trebuiesc executate cat se poate de multe operatii asupra datelor stocate

la fiecare locatie, in conformitate cu principiul autonomiei. In vederea optimizarii

interogarilor, problema trebuie tratata atat la nivel global prin stabilirea strategiei

functie de datele problemei, coordonarea tuturor operatiunilor aferente, transmiterea

si preluarea de mesaje catre si dinspre locatii, cat si la nivel local prin strategia interna

de prelucrare a interogarilor, comunicare rezultate partiale si verificari. Daca cererea

a fost emisa de locatia X, acesta o va transmite si locatiei Y pentru a executa

operatiile necesare dupa care va returna un rezultat partial. In functie de cardinalitatea

rezultatelor partiale, a dimensiunii unui n-uplu cat si a vitezei de transfer pe

infrastructura fizica sau virtuala de comunicatie, una dintre locatii va trimite catre

cealalta rezultatul partial pentru efectuarea prelucrarilor finale. In cazul distributiei la

doua locatii este necesara transmiterea a doar doua mesaje (cererea de prelucrare si

rezultatul in sens invers). Cu cat numarul de locatii creste numarul de mesaje creste

datorita cererilor multiple catre locatii si a raspunsurilor de la acestea. O alta

problema vine de la multitudinea modalitatilor de rezolvare a interogarii, stiut fiind

faptul ca pot exista mai multe solutii de procesare a unei cereri. Cu toate ca

prelucrarea unei interogari intr-un mediu distribuit presupune o activitate mai

complexa, asta nu presupune ca raspunsul este intarziat, ci poate fi chiar mai prompt

decat in cazul sistemelor centralizate datorita puterii crescute de calcul distribuit.

Algoritmii de optimizare pentru executia tranzactiilor trebuie sa tina cont suplimentar

de viteza retelei de comunicatie. In general, se urmareste ca tratarea cererilor sa fie

cat mai apropiata, ca performante,de cea a cererilor locale.

Gestionarea distribuita a tranzactiilor. Gestiunea tranzactiilor are ca obiect de studiu

controlul accesului concurent si problematica tolerantei la defecte. Fata de abordarea


6

cu un singur nod central, in cazul sistemelor distribuite lucrurile devin mult mai

complicate. O tranzactie lansata in sistemul distribuit are nevoie de agenti, care sa

verifice rezultatul finalizarii tranzactiei in fiecare din locatiile implicate. Evident ca si

in mediul distribuit proprietatile tranzactiilor (ACID - Atomicitate, Coerenta, Izolare,

Durabilitate) trebuie sa fie respectate. Pentru ca o tranzactie sa corespunda pretentiilor

de atomicitate trebuie ca fiecare agent al tranzactiei sa-si indeplineasca sarcina, in caz

contrar toti sunt nevoiti sa execute o tranzactie in compensare pentru a pastra

consistenta bazei. Similar cu bazele de date centralizate metoda cea mai raspandita de

control al accesului concurent se bazeaza pe blocare. Gestionarea distribuita a

tranzactiilor este strans legata de problematica transparentei tranzactiilor. Fara a lua in

considerare aspectele privitoare la controlul concurentei si a rezistentei la defecte,

intr-un mediu distribuit, descompunerea unei tranzactii in subtranzactii duce la

cresterea performantelor atat la nivelul vitezei de executie, cat si din punctul de

vedere al concurentei. Referitor la transparenta la defectare si capacitatea de refacere,

trebuie sa se tina cont de atomicitatea tranzactiilor si de caracterul durabil al

modificarilor facute. Un SGBD distribuit trebuie sa garanteze ca tranzactia globala

este atomica, adica toate tranzactiile locale pe care le implica fie s-au terminat cu

succes, fie au fost toate anulate. Nu putem avea situatii de compromis, deoarece

datorita caracterului durabil al subtranzactiilor se poate ajunge la inconsistente. Pe

langa problemele cu care se confrunta sistemele centralizate (caderea sistemului, pene

de comunicatie, erori software, neglijenta, dezastre fizice, naturale sau sabotajul) un

sistem distribuit trebuie sa tina cont si de: pierderea unui mesaj, defectarea legaturilor

de comunicatie, defectarea unui nod sau de partitionarea retelei. Un sistem distribuit

trebuie sa furnizeze un mecanism de refacere, care indiferent de aparitia unor posibile

accidente, de genul celor enumerate, trebuie sa sustina atomicitatea tranzactiei

globale. In general, aceasta cerinta este asigurata prin protocolul commit in doua faze

(two phase commit).

Independenta de hardware. De mai mult timp aplicatiile software trebuie sa satisfaca

criteriul transparentei fata de hardwareul utilizat. Nici sistemele distribuite nu trebuie

sa faca rabat de la aceasta caracteristica. Infrastructura hardware poate fi compusa din

echipamente de la diferiti producatori in configuratii si cu performante diferite.

Utilizatorul nu trebuie sa sesiseze vreo diferenta in functionarea sistemului nici chiar

daca lucreaza alternativ pe masini cu tehnologii de fabricatie diferite. Multe baze de

date opereaza pe o varietate de platforme.

Independenta de sistemul de operare. Un sistem distribuit trebuie sa poate functiona

atat pe masini diferite din punct de vedere al tehnologiei hardware, cat si pe

calculatoare pe care sunt instalate sisteme de operare diferite. Utilizatorul nu trebuie

sa resimta amprenta sistemelor de operare diferite, instalate pe masini diferite, sau

chiar pe acelasi echipament. Indiferent ca e vorba de sistemul de operare Unix,

Windows, OS/2, de versiuni diferite, sistemul distribuit trebuie sa poata rula pe


7

oricare dintre acestea, fara ca operatorul sa sesiseze diferente de utilizare intre masini

cu sisteme de operare diferite.

Independenta de infrastructura de comunicatie. Nodurile sistemului distribuit sunt

conectate logic la aceeasi retea de comunicatie. Chiar daca topologiile, vitezele de

transfer, dimensiunile pachetelor, metodele de acces la mediu sau tehnologia

subretelelor, peste care acesta se intinde, sunt diferite, acestea nu trebuie sa devina un

impediment in buna functionare a sistemului.

Independenta de sistemul de gestiune al bazei de date. Acest deziderat este unul

dintre cel mai greu de atins. Ideal ar fi ca pe toate masinile sistemului distribuit sa

ruleze acelasi SGBD. Nu intotdeauna acest lucru poate fi pus in practica datorita

eterogenitatii echipamentelor si a sistemelor de operare, fara a ne putea detasa si de

latura financiara. Chiar daca SGBD-urile sunt diferite, ar fi cel putin recomandat ca sa

nu existe problema incompatibilitatii canalelor de comunicare intre locatiile avand

SGBD-uri diferite. Pentru acessta, fiecare locatie ar trebui sa recunoasca acelasi

standard SQL. Sistemul distribuit ideal ar fi acela care ar putea asigura transparenta

fata de orice SGBD utilizat. In general, cerinta este asigurata prin instalarea unui

gateway (componenta software) pentru adaptarea de la un SGBD la altul.

Din punctul de vedere al sistemului fizic ce constituie suportul pentru o baza de date distribuita

se includ: calculatoare personale, minicalculatoare, statii de lucru, dispositive mobile etc, toate

conectate intr-o retea de comunicatie si numite generic noduri, site-uri sau locatii. Cu aceste

precizari definitia unui sistem de baze de date distribuite poate fi reformulata ca “o colectie de

noduri, fiecare putand participa la executarea tranzactiilor care acceseaza datele stocate la un

nod sau la mai multe noduri”.

Regulile formulate de Date sunt destul de restrictive, motiv pentru care acestea trebuiesc relaxate

in sistemele de baze de date distribuite. Principalele cerinte ce trebuie asigurate intr-un sistem de

baze de date distribuite sunt:

autonomia locala in organizarea si prelucrarea datelor;

neutilizarea unei centralizari pentru evidenta si accesarea datelor;

posibilitatea operarii continuea nodurilor independent de schimbarile in configuratiile de

lucru (adaugarea sau eliminarea unor noduri);

independenta fata de localizarea si modul de fragmentare a datelor sau altfel spus

transparenta fizica;

asigurarea de facilitati pentru copierea sau replicarea datelor cu pastrarea independentei

copiiilor;

cresterea performantelor prin prelucrarea distribuita pe nodurile sistemului a cererilor;

capabilitatea de administrare distribuita a executiei tranzactiilor;

independenta sistemului de componentele hardware, de sistemul de operare, de topologia

retelei si de sistemul de gestiune a bazelor de date ce ruleaza pe nodurile sistemului.

Intr-un sistem de baze de date distribuitbaza de date este descompusa in fragmente, unele

fragmente pot fi multiplicate, astfel ca un fragment sau o copie a acestuia este stocat pe unul sau


8

mai multe noduri sub controlul unui SGBD local. La fiecare nod pot fi procesate interogari

localecerute de utilizator fara a implica alte noduri ale retelei, sau nodul participa la procesarea

unor date gazduite de alte noduri din retea, indiferent de SGBD-ul instalat pe acestea. Atunci

cand o cerere implica si date distante spunem ca este o cerere globala iar din punctual de vedere

al executiei avem o executie distribuita. Similar cu sistemele de baze de date cetralizate

operatiile asupra bazei de date sunt grupate in tranzactii. Intr-o baza de date distribuita

tranzactiile se impart in:

tranzactii locale– acele tranzactii pentru executia carora nu sunt necesare resurse stocate

pe un alt nod si tranzactia este ceruta de un utilizator conectat la baza de date locala

tranzactii distante (remote) – sunt tranzactii cerute de un utilizator conectat la baza de

date de la alt nod, dar pentru executia sa sunt necesare numai resurse aferente unui singur

nod distant;

tranzactii distribuite – tranzactii lansate de un utilizator conectat la baza de date aferenta

unui nod pentru a caror executie sunt necesare resurse gazduite de cel putin doua noduri,

indifferent daca ambele sunt distante sau unul este local;

Obs. Pentru executia tranzactiilor remote si a tranzactiilor distribuite se impune ca fiecare nod

sa stie de existenta celorlalte noduri si de capabilitatea acestora de a participa la executia

tranzactiilor.

1.2. Avantaje si dezavantaje baze de date distribuite

In primul rand prin distribuirea datelor unei baze de date pe mai multe noduri obtinem o extensie

a spatiului de stocare si in acelasi timp oferim resurse de procesare multiple. Chiar daca puterea

de calcul a crescut foarte mult in ultimii ani, la prelucrarea volumelor mari de date performantele

devin inacceptabile. Prin distributia datelor pe mai multe centre de procesare se obtin avantaje

considerabile privind performantelein principal datorata prelucrarii paralele pe mai multe noduri,

dar garantarea indeplinirii proprietatilor ACID este mult mai greu de realizat. Pe langa acestea

sistemele de baze de date distribuite ofera o serie de avantaje aditionale:

Se identifica cu structura organizationala a multor organizatii, pe care o modeleaza mult

mai bine, avand in vedere ca multe companii sunt localizate "distribuit" din punct de

vedere geografic;

Cu toate ca datele sunt partajabile, administrarea lor se bucura de un grad inalt de

autonomie locala. Datele pastrate pe fiecare site pot fi administrate independent de catre

administrator diferiti;

Ofera o disponibilitate ridicata pentru accesul la baza de date fata de sistemele

centralizate. Chiar si in cazul in care apar erori de comunicatie sau defectari de noduri

sistemul poate continua sa functioneze in conditii satisfacatoare;

Se imbunatateste fiabilitatea sistemului intrucat pot fi refacute rapid fisierele distruse

utilizand replici gazduite de alte noduri;

Diminuarea costurilor de implementare si intretinere prin utilizarea de echipamente

uzuale in nodurile de prelucrarea fata de un sistem centralizat care sa ofere aceeasi putere


9

de prelucrare. Prin realizarea a cat mai multe prelucrari locale, arunci cand aplicatiile

permit acest lucru, scade costul de exploatare prin diminuarea costului comunicatiilor.

Cresterea scalabilitatii sistemului prin posibilitatea de adaugare sau extragere a noi

noduri, functie de necesitatile de exploatare. Ajustarea puterii de calcul la sistemele

centralizate este mult mai costisitoare si in plus necesita timpi de oprire a

functionalitatilor;

Nu trebuie insa sa minimalizam efectele negative ale distributiei, dintre care principalele sunt:

Cresterea complexitatii cu efecte in ceea ce priveste complicatiile de implementare si

gestionare, necesitatea existentei unui personal specializat, necesitatea unei infrastructuri

de comunicatie;

Sensibilitatea la erori datorata algoritmilor de procesare distribuita pentru care consistenta

datelor este greu de mentinut;

Necesitatea unor prelucrari suplimentare pentru asigurarea schimburilor de mesaje intre

noduri si pentru coordonarea activitatii acestora;

Deschiderea de noi brese de securitate in comparatie cu un sistem centralizat. Sistemul,

prin distributia sa geografica nu poate fi ascuns in spatele unui firewall, o serie de date

sensibile sunt schimbate intre noduri pe infrastructura de comunicatie;

Existenta mai multor entitati de administrare cu politici de administrare diferite;

Asigurarea integritatii datelor este greu de realizat fata de sistemul centralizat. Din cauza

costurilor mari de comunicatie, dar si atimpilor de raspuns, de cele mai multe ori se

renunta la o parte din regulile ce trebuie verificate pentru datele din baza.

Probleme legate de standardizare. Chiar daca nu se poate vorbi de o lipsa totala de

standardizare putem afirma ca nu sunt inca standarde internationale unanim acceptate

care sa garanteze comunicarea eficienta, proiectarea, gestionarea si exploatarea datelor in

sisteme distribuite.

Este posibilaaparitia unui flux mare de informatii intre noduri care sa necesite rezolvarea

problemelor legate de sincronizarea mesajelor, detectarea erorilor, inconsistenta datelor

redundante.


10

2. Arhitectura unui Sistem de Gestiune pentru Baze de Date

Distribuite (SGBDD)

Pentru a defini o arhitectura pentru un sistem de gestiune a bazei de date distribuit este necesar

mai intai sa identificam principalele functii ce trebuie indeplinite de acesta. Noile functionalitati

se bazeaza pe functionalitatile sistemelor de baze de date centralizate sicel putin la nivel local

fiecare componenta trebuie sa asigure functionalitatile sistemelor centralizate. Dintre

functionalitatile suplimentare amintesc:

Sa se comporte pe ansamblu in acelasi mod in care se comporta un SGBD centralizat;

Sa ofere acces la nodurile din retea si sa permita transfer de date, controlat si minimal

pentru realizarea interogarilor;

Sa poata gestiona un dictionar de date extins care sa contina detalii legate de modul de

distribuire a datelor;

Sa permita si sa ofere servicii pentru procesarea distribuita a interogarilor;

Sa asigure controlul concurentei in scopl mentinerii unui grad cat mai ridicat al

consistentei datelor;

Sa ofere servicii de refacere (recovery) peste toate nodurile care sa resincronizeze

intreaga baza de date dupa defectari ale nodurilor sau pierderea comunicatiei.

O prima arhitectura de referinta pentru SGBD distribuit a fost elaborate de ANSI. In cazul

sistemelor distribuite, arhitectura tip ANSI este conceputa pe doua niveluri: un nivel global si un

nivel local (fig. 2.1).

Schema

globala

Schema de

fragmentare

Schema de

alocare

Nivel

global

(nod coordonator)

Schema

locala

SGBD

local

BD

locala

Nivel

local

(nod cooperant)

Schema

locala

SGBD

local

BD

locala

……...

Fig. 2.1 Arhitectura SGBDD tip ANSI

In aceasta arhitectura de SGBDD exista un singur nod pe nivelul global si mai multe noduri pe

nivelul local. In totalitate, sistemul distribuit trateaza o schema globala, referitoare la toate datele

distribuite in retea, si are in vedere mai multe scheme locale, referitoare la datele de la fiecare

locatie. Fiecare dintre niveluri are componente bine precizate. Nivelul global are rolul de a

asigura o tratare de ansamblu a bazei de date distribuite. Aici sunt integrate unitar toate datele


11

din bazele de date locale. Integrarea se realizeaza cu ajutorul celor trei tipuri de scheme care sunt

implementate la nivelul global: schema globala, schema de fragmentare si schema de alocare.

Schema globala defineste si descrie toate informatiile din baza de date distribuita. Pentru

descriere se foloseste unul din modelele de date fundamentale utilizate in bazele de date:

arborescent, retea, relational, orientat pe obiecte. In sens general, vom spune ca schema

globala descrie un set de colectii globale si legaturile dintre ele. Daca consideram ca

SGBD-ul distribuit implementeaza modelul relational, atunci schema globala descrie un

set de tabele numite globale si legaturile dintre ele. Fiecare dintre tabelele globale este

impartita logic in fragmente. Fragmentele sunt parti disjuncte ale unei tabele globale, un

fragment nu poate proveni din mai multe tabele.

Schema de fragmentare descrie legaturile dintre colectia globala si fragmentele sale. Ea

este de tipul unu la mai multi si are forma unei ierarhii. Scopul fragmentarii logice a

colectiilor globale este de a se putea face o alocare fizica corespunzatoare a datelor ce

sunt gestionate de nodurile sistemului distribuit. De exemplu, fragmentele unei tabele pot

fi toate alocate pe un singur calculator sau fiecare pe un alt calculator din arhitectura. In

acest fel, o tabela globala poate fi alocata fizic pe mai multe calculatoare, deci va fi

distribuita in retea.

Schema de alocare descrie modul de distribuire a fragmentelor pe statiile din retea. In

acest mod fiecare segment va avea o alocare fizica pe una sau mai multe statii. Rezulta ca

schema de alocare introduce o redundanta controlata: un anumit segment se poate regasi

fizic pe mai multe calculatoare. Pe de alta parte, pe un calculator pot exista fragmente din

mai multe tabele globale. In aceste conditii, schema de alocare este de tipul multi la mai

multi avand o forma de retea.

F1 F2 F3

N1

…...

N2 Nm…..

Fragmente

ale tabelei T

Alocare fizica

Noduri in retea

Fig. 2.2 Schema de alocare

In exemplul considerat in fig. 2.2, fragmentul F1 va fi alocat fizic atat pe calculatorul N1 cat si

pe N2, fragmentul F2 pe calculatoarele N1, N2 si Nm si asa mai departe. Totalitatea

fragmentelor dintr-o anumita tabela globala care sunt alocate pe acelasi calculator formeaza

imaginea fizica a tabelei date, pe calculatorul respectiv. In exemplul de mai sus, imaginea fizica

a tabelei T pe calculatorul N1 este data de fragmentele F1, F2 si F3, iar pe calculatorul N2 avem

o alta imagine data de fragmentele F1 si F2. Localizarea optima a datelor in nodurile unei retele


12

revine proiectantului si administratorului bazei de date distribuite. Ei vor construi schema de

alocare tinand cont de: volumul de date necesar a fi utilizat in fiecare nod, performantele

calculatoarelor din noduri, performantele retelei, volumul tranzactiilor din fiecare locatie, tipul

tranzactiilor.

Nivelul local al unui SGBD distribuit reuneste toate bazele de date locale distribuite pe

calculatoarele din retea. Fiecare dintre aceste baze de date este tratata ca o baza centralizata cu

ajutorul a trei componente: schema locala, SGBD-ul local si baza de date locala propriu-zisa.

Detaliem rolurile componentelor:

Schema locala are rolul de a realiza legatura dintre imaginea fizica si datele stocate local

si este dependenta de tipul SGBD-ului local.

SGBD-ul local implementeaza schema locala si are rolul de a descrie si gestiona datele

stocate pe respectivul nod. La nivelurile locale putem avea situatia in care toate SGBD-

urile utilizate sunt de acelasi tip, de la acelasi producator (cazul omogen), respectiv

autipuri diferite (cazul eterogen).

Baza de date locala contine datele propriuzise alocate conform imaginilor fizice si este

organizata dupa modelul de date acceptat de SGBD-ul local.

Firma IBM, dezvoltatorul bazei de date DB2, are un puternic colectiv de cercetare in domeniul

bazelor de date si a elaborat o arhitectura de referinta pentru baze de date distribuite numita

DRDA (Distributed Relational Database Arhitecture). Arhitectura propusa promoveaza ideea de

deschidere a bazelor de date distribuite spre dezvoltari succesive. In acest scop sunt prevazute

patru niveluri posibile de dezvoltare progresiva.Cele patru niveluri corespund diferitelor tipuri de

tranzactii ce pot aparea intr-o baza de date distribuita:

Cererile la distanta semnifica faptul ca fiecare cerere este o tranzactie separata care se

indreapta spre un singur nod. O cerere lansata de un nod ce este adresata pentru o baza de

date stocata pe un nod se numeste cerere la distanta. O cerere care face acces la date la

distanta este considerate ca fiind o tranzactie distincta.

Tranzactiile la distanta permit ca fiecare trazactie sa poata accesa un singur nod de mai

multe ori. Altfel spus, mai multe accese la fiecare baza de date locala, situata pe un nod la

distanta fata de nodul de unde s-a declansat tranzactia, sunt tratate ca fiind o singura

tranzactie.

Tranzactiile distribuite sunt cele care permit ca intr-o singura tranzactie sa se acceseze

mai multe baze de date situate pe noduri diferite. Acest nivel permite actualizarea bazelor

de date gestionate de noduri diferite.

Cererile distribuite semnifica faptul ca printr-o singura cerere se pot accesa date aflate pe

mai multe noduri din retea.

Figura 2.3 ilustreaza cele patru niveluri propuse de IBM.


13

Cerere 1

Cerere 2nod

Nod

date

Nod

date

Nivel 1

Cereri la

distanta

Nod

date

Nod

date

Nivel 2

Tranzactii la

distanta

Tranzactie 1

Tranzactie 2

nod

Nod

date

Nod

date

Nivel 3

Tranzactii

distribuite

Tranzactie 1

Tranzactie 2

nod

Nod

date

Nod

date

Nivel 4

Cereri

distribuite

Tranzactie 1

Tranzactie 2

nod

Fig. 2.3 Arhitectura tip IBM

Pentru baze de date distribuite arhitectura ANSI-SPARC pe trei niveluri este ilustrata in fig 2.4,

in care schema conceptuala globala este o descriere logica a intregii baze de date, fara a se

evidentia aspectul distribuit [Con05]. Este nivelul la care se definesc entitatile, relatiile,

restrictiile de integritate, informatiile generale de securitate a datelor. Schemele de fragmentare

descriu modelul logic al partitionarii bazei de date iar alocarea descrie repartizarea fragmentelor

si a eventualelor copii ale acestora pe nodurile retelei. Schemele locale de mapare redau

fragmentele din schema de alocare in "obiecte" externe bazei de date locale. Aceasta descriere

este independenta de SGBD-ul ales si datorita acestui fapt se poate vorbi de SGBD-uri

eterogene.

Oricare ar fi modelul de referinta este obligatorie asigurarea transparentei la toate nivelurile.

Astfel, pentru transparenta distributiei la o arhitectura tip ANSI se poate asigura transparenta

distribuita pe trei niveluri: fragmentare, alocare si local, in ordine de la nivelul cel mai inalt la cel

mai scazut.

1. Transparenta la nivel de fragmentare este asigurata de SGBD-ul distribuit in sensul ca

utilizatorii lucreaza utilizand colectiile globale. Din punctul lor de vedere acestea sunt

datele pe care le acceseaza fara sa stie unde si cum sunt ele stocate in realitate in retea.

Acest lucru ramane la sarcina SGBD-ului distribuit care descompune fiecare dintre

colectiile globale accesate in fragmente, pe care in continuare, le identifica fizic pe


14

calculatoarele din retea. Acesta este nivelul cel mai inalt de transparenta a distributiei pe

care-l poate asigura un SGBD distribuit.

2. Transparenta la nivel de alocare este asigurata de SGBD-ul distribuit in sensul ca

utilizatorii lucreaza cu fragmente. Asadar, ei trebuie sa cunoasca schema de fragmentare,

conform careia, de exemplu, o colectie globala este descompusa in mai multe fragmente.

Utilizatorul lucreaza cu aceste fragmente darnu cunoaste localizarea fizica, pe

calculatoarele din retea, a acestora. Este posibil ca un anumit fragment sa fie multiplicat

(replicat) pe mai multe calculatoare din retea. Ca o prelungire a transparentei de alocare

SGBD-ul distribuit poate asigura transparenta de replicare. Acest lucru inseamna ca

utilizatorul poate lucra cu un fragment alocat pe un anumit calculator, dar nu stie daca

acesta este replicat sau nu. Este sarcina SGBD-ului distribuit ca, de exemplu, la

actualizarea unui fragment alocat pe un anumit calculator sa actualizeze automat toate

alocarile aceluiasi fragment pe alte calculatoare. Este posibil ca SGBD-ul distribuit sa

asigure numai transparenta de alocare sau numai transparenta de replicare sau ambele.

Avantajele transparentei alocarii sunt date de faptul ca se simplifica accesul la datele

situate la distanta si datele pot fi mutate fara a afecta in nici un fel utilizatorii.

Schema externa

globala

Schema externa

globala

Schema conceptuala

Schema de

fragmentare

Schema de alocare

Schema;locala de

mapare

Schema;locala de

mapare

Schema;conceptuala

locala

Schema;conceptuala

locala

Schema;interna

locala

Schema;interrna

locala

Da

ta

ba

se

Da

ta

ba

se

Fig.2.4. Arhitectura ANSI-SPARC pe trei niveluri


15

3. Transparenta la nivel local este asigurata de SGBD-ul distribuit in sensul ca utilizatorii

lucreaza cu un SGBD local. Ei utilizeaza pe un anumit calculator din retea SGBD-ul local

existent, fara a cunoaste modelul de date implementat pentru baza de date locala. Aceasta

va fi sarcina SGBD-ului local. Prin acest tip de transparenta SGBD-ul distribuit asigura

independenta fata de SGBD-urile locale. Din acest motiv, acestea pot fi de acelasi tip,

adica omogene sau de tipuri diferite (eterogene).

Se observa ca modelul pe trei niveluri este compus din vederea externa (schema externa globala),

vederea conceptuala (schema conceptuala), vederea interna (materializata prin schema de

fragmentare, alocare si apoi transpusa baza de date locala). Modelele arhitecturale pentru baze

de date distribuite se impart in trei categorii [Silb]:

Autonome – caracterizata de tipul independentei datelor;

Distributie – nivelul distribuirii;

Eterogene –caracterizate prin diferenteledintre sistemele suportate.

Pentru autonomie au fost elaborate diferite definitii. Astfel, dupa Gligor si Popescu-Zeletin un

model este autonom daca operatiile locale nu sunt afectate de participarea la un sistem global de

baza de date, procesarea si optimizarea cererilor nu sunt afectate de cererile globale si

consistenta sistemului nu este compromisa atunci cand baza de date este adaugata sau retrasa

la/de la baza de date globala. Pe de alta parte Du si Elmagarmid caracterizeaza autonomia prin

trei componente:

design – baza de date poate utilizeza modele de date si gestiunea tranzactiilor pe care le

doreste;

comunicatie – baza de date decide ce date furnizeaza la alta baza de date sau la aplicatii;

executie – fiecare baza de date executa cererile in propriul mod.

Din punctual de vedere al nivelului distributiei avem arhitecturi client/server prin care se

distribuie functionalitati ale bazei de date, arhitecturi peer-to-peer ce pot fi complet distribuite

sau pot coopera cu oricare alta.Din punctul de vedere al eterogenitatii aceasta se manifesta prin

urmatoarele aspecte: hardware diferit, modele de date diferite, limbaje de cereri diferite, modele

de gestiunea tranzactiilor diferite.

O baza de date distribuita poate fi definita ca o colectie de date integrate din punct de vedere

logic dar fizic distribuite pe mai multe masini ce pot comunica printr-o infrastructura (de regula,

retele de calculatoare). Prin aceasta definitie se pun in evidenta doua aspecte importante ale

bazelor de date distribuite si anume: integrarea logica a colectiilor de date (pentru utilizator

exista o singura baza de date cu care acesta interactioneaza), distribuirea fizica (partitionarea si

stocarea fizica a bazei de date pe mai multe masini).

Aceste caracteristici sunt destul de vagi pentru a surprinde deosebirile dintre o baza de date

distribuita si un set de baze de date locale. In figura 2.5 este prezentata o baza de date distribuita

pe trei servere intr-o retea globala, iar in fig. 2.6 o baza de date distribuita pe 3 masini intr-o retea

locala. Fiecare dintre masini se constituie ca nod al bazei de date distribuita si poate comunica cu

celelalte noduri prin reteaua de comunicatie. La fiecare din nodurile retelei ce stocheaza baza de


16

date pot fi conectate alte echipamente pe post de terminale de la care se efectueaza operatii

asupra bazei de date, sau chiar de la masina alocata ca nod al bazei de date. Este momentul sa

facem distinctia clara intre un set de baze de date locale si un sistem distribuit in care exista

aplicatii care necesita accesarea datelor pastrate pe statii diferite. Astfel de aplicatii sunt numite

aplicatii globale sau aplicatii distribuite. In concluzie, o baza de date distribuita reprezinta o

colectie de date integrate, din punct de vedere logic, care sunt fizic distribuite pe statii ale unei

retele de calculatoare. Fiecare statie a retelei are o anumita autonomie de prelucrare care ii

permite sa efectueze prelucrari pentru aplicatii locale, si in plus poate participa la executia

aplicatiilor globale care necesita accesarea datelor stocate in alte locatii.

Nod 1 Nod 1

BD2

Retea globala

Nod 1

BD3

T

T

T

T

T

T

T

T

T

BD1

Fig 2.5 Baza de date distribuita in retea WAN

Modelul corespunde structurii organizationale a multor companii.Acestea isi desfasoara

activitatea in sedii distribuite geografic in mai multe zone din aceeasi tara sau plasate in mai

multe tari. Fiecare sediu isi are propria organizare si activitati care se desfasoara local. La

perioade de timp determinate sau ori de cate ori este nevoie, sediile trebuiesc sa comunice fie

intre ele sau cu sediul central, pentru schimb de informatii. Aplicatiile intr-o astfel de companie

sunt tipice pentru baze de date distribuite. Bazele de date locale (din noduri) avand un mare grad

de independenta asigura un nivel de protectie suplimentar impotriva avariilor ce pot sa apara la

calculatoarele din alte noduri. Se obtine astfel in retea, o protectie reciproca fata de avariile

celorlalti. Avem o administrare la nivel local similara cu cea pentru o baza de date concentrata si

un nivel de administrarea globala mult mai greu de realizat.


17

Nod 1 Nod 1

BD1 BD2

Retea locala (LAN)

Nod 1

BD3

T

T

T

T

T

T

T

T

T

Fig 2.6 Baza de date distribuita intr-o retea LAN

Functie de mediul de baze de date instalat la fiecare locatie avem baze de date distribuite

omogene, atunci cand la toate locatiile opereaza acelasi DBMS, respectiv eterogene daca exista

locatii la care mediul de baze de date este diferit. In acest context pentru bazele de date

distribuite eterogene apar o serie de probleme de interconectare din cauza formatului datelor,

particularitatilor legate de definirea constrangerilor, dar si particularitati legate de platforma

hardware si software gazda. In acest caz intre DBMS si infrastructura de comunicatie este

necesara o componenta software pentru adaptare. Aceasta componenta este numita uzual

gateway si reprezinta o piesa software care accepta cereri pentru a le trimite la DBMS local,

respectiv returneaza raspunsul celui care a formulat cererea (fig. 2.7).

Infrastructura

Gateway

DBMS1

Gateway

DBMS2

Gateway

DBMS3

Fig. 2.7 Structura baza de date distribuita eterogena (Gateway)


18

Ingres

(SQL)

Oracle

(SQL)Gateway

BD

Ingres

BD

Oracle

Baza de date

Oracle Ingres distribuita

Utilizator

Ingress

Fig. 2.8 O poarta de la sistemulIngres catre sistemul Oracle

In sistemul din fig. 2.8 avem doua locatii in care sunt implementate o baza Ingres si o baza

Oracle. Un utilizator de la locatia unde ruleaza Ingres doreste sa lanseze o interogare care

necesita informatii atat de la locatia proprie, cat si de la locatia la care ruleaza Oracle. In cazul in

care sistemul ar fi omogen solutionarea cererii n-ar intampina nici o problema la executie. In

cazul de fata, pentru asigurarea transparentei fata de sistemul de gestiune al bazei de date va avea

nevoie de o interfata intre cele doua sisteme care sa furnizeze raspunsul dorit fara a crea in nici

un moment senzatia ca sistemele sunt eterogene. Aceasta interfata poarta numele de poarta sau

wrapper si este un program special care va face ca sistemul Oracle sa arate si sa se comporte

identic cu sistemul din interiorul caruia se lanseaza cererea. Aceasta piesa software este specifica

fiecarui sistem si are o implementre mult mai naturala decat utilizarea unui API ODBC (Open

DataBase Connectivity). ODBC a fost construit astfel incat sa fie independent de sistemul de

baza de date si sistemul de operare cu scopul portatii aplicatiilor ce utilizeaza ODBC de pe o

platforma pe alta. Un SGBD distribuit utilizeaza o serie de componente specifice unei arhitecturi

distribuite. Aceste componente sunt:

Infrastructura de comunicatie de regula retea de calculatoare - un ansamblu de

componente hardware si software care asigura legatura intre nodurile retelei.

Nodul este un sistem de calcul (calculator) dintr-o retea ce indeplineste unul din rolurile

server, client sau ambele.

Serverul este un produs software care se instaleaza pe un calculator mai puternic dintr-o

retea si gestioneaza baza de date. Exemplu : Server Oracle.

Clientul este o aplicatie, dispusa intr-o retea de calculatoare, care solicita date de la un

server. Calculatorul pe care este instalata aplicatia client poate fi orice tip de masina de

prelucrare.


19

3. Proiectarea unei baze de date relationale distribuite

Pentru proiectarea unei baze de date distribuita avand ca model al datelor modelul relational se

parcurg de regula, in prima faza aceleasi etape ca si pentru o baza de date centralizata prin care

se obtine schema relationala sau modelul relational al bazei de date. Daca la o baza de date

centralizata, schema relationala se particularizeaza functie de SGBD si se transpune apoi in

modelul intern care defineste structura tabelelor bazei de date, la sistemele distribuite principale

problema de proiectare ce trebuie rezolvata consta in luarea deciziei privind plasarea datelor si a

programelor pe nodurile de calcul sau eventual chiar reproiectarea retelei de calculatoare [Gam].

Un astfel de process presupune decizii privind SGBD-ul ce ruleaza pe fiecare nod, a datelor ce

vor fi stocate pe fiecare nod si a aplicatiilor care ruleaza baza de date. La acest moment discutam

doar despre distributia datelor. Desigur ca in proiectarea bazei de date distribuite sunt posibile

mai multe strategii determinate in principal de situatia actuala concreta. Daca baza de date este

nou proiectata se va porni de la cerinte si are ca rezultat, de cele mai multe ori un sistem omogen,

pe cand daca anumite componente ale bazei de date exista deja pe un numar de locatii acestea

trebuie conectate pentru a rezolva sarcinile cerute.

Partea centrala, specifica pentru baze de date distribuite, este cea privind proiectarea distributiei,

celelalte activitati fiind similare ce cele ale proiectarii bazelor de date centralizate. Principalul

obiectiv pentru proiectarea distributiei consta in decizia privind modul de alocarea a relatiilor sau

a subrelatiilor pe noduri. Doua aspecte sunt importante si trebuie abordate cu mare atentie:

Fragmentarea – operatia prin care o relatie este impartita intr-un numar de subrelatii ce

urmeaza a fi distribuite;

Alocarea – determinarea locului in care un fragment este stocat pentru o distributie

optima si eventual a numarului de copii ale fragmentului pe mai multe noduri. In situatia

in care se decide ca un fragment sa fie stocat intr-un numar de copii pe langa problema

alocarii intervine si problema replicarii.

3.1. Fragmentarea

O intrebare obisnuita vrea sa dea un raspuns la intrebarea “Cum este mai rezonabil sa distribuim

o relatie sau un fragment al unei relatii?” Desigur ca raspunsul este greu de stabilit, intrucat sunt

motive intemeiate pentru a distribui relatii si la fel de intemeiate pentru a distribui fragmente. O

analiza este necesara pentru a determina situatiile in care este avantajoasa distributia relatiei,

respectiv a fragmentelor. In cazul in care se distribuie intreaga relatie sunt posibile urmatoarele

situatii:

O intreaga relatie replicata intr-un numar mare de copii va genera probleme la

actualizarea datelor pentru sincronizarea tuturor replicilor, mai ales in situatia in care

datele se modifica la mai multe locatii;

Daca relatia nu este replicata, pentru accesul la date de la distanta se va genera un volum

mare al traficului si datele vor fi disponibile cu mare intarziere. Sunt situatii in care

intreaga tabela trebuie transmisa unui alt nod;


20

Relatia se pastreaza la un singur nod daca cererile necesita toate datele stocate in relatie si

datele se stocheaza pe nodul care utilizeaza datele;

Un principiu universal valabil arata ca este mult mai usor sa distribuim programe in

sensul ca datele sa se gaseasca in acelasi loc cu programele decat sa transportam date.

Descompunerea relatiilor in fragmente si distribuirea fragmentelor este rezonabila daca:

Aplicatiile acceseaza usual numai anumite subseturi de date ale relatiei;

Descompunerea relatiiilor in fragmente si distributia lor permite executarea de tranzactii

in paralel intrucat fiecare operatie are nevoie de acces la un set deferit de date din relatie;

Cererile contin subcereri ce pot fi executate in paralel.

Cu toate aceste avantaje pastrarea integritatii unei relatii descompuse in fragmente si distribuite

intre mai multe noduri este greu de asigurat. Din cele analizate rezulta ca atat fragmentele cat si

relatiile sunt unitati corespunzatoare pentru distributie, insa decizia privind distributia trebuie

foarte bine analizata. Fragmentarea bazei de date asigura suplimentar o serie de alte avantaje

cum sunt: cresterea fiabilitatii, cresterea performantelor, scaderea costurilor de comunicatie,

cresterea securitatii prin politici de securitate diferite la noduri, utilizarea eficienta a capacitatii

de stocare. Alte criterii ce trebuie luate in consideratie la decizia de fragmentare constau in

analizarea locului in care o cerere se executa, ce seturi de date necesita, care este fvrecventa de

executie a unor cereri specifice, modul in care datele sunt accesate: read sau write.

Se cunosc mai multe tipuri de fragmentare, indiferent de modul in care fragmentarea este

efectuata trebuie sa existe o succesiune de operatii prin care relatia fragmentata sa poate fi

refacuta. Fragmentarea poate fi:

Orizontala– atunci cand n-uplurile relatiei sunt segmentate in mai multe fragmente

fiecare dintre acestea avand aceleasi attribute cu cele ale relatiei originale. In aceasta

situatie sunt puse intr-un fragment n-uplurile care indeplinesc o anumita conditie,

respectiv celelalte in alt fragment. Din punctul de vedere al reconstructiei o simpla

operatie UNION reface relatia initiala. In principal, fragmentarea orizontala decupeaza o

tabela pe orizontala pastrand in fiecre fragment inregistrarile satisfacand o anumita

conditie ce defineste setul de inregistrari. Fragmentarea orizontala nu afecteaza

redundanta in sensul ca fragmentele pot sa contina date distincte si nu sunt pastrate

aceleasi n-upluri in mai multe fragmente. Pentru descompunerea unei relatii in fragmente

se executa operatii similar cu operatiaSELECT din algebra relationala. Daca o relatie R a

fost fragmentata orizontal in fragmentele R1, R2, R3, putem a recompune relatia initiala

prin 𝑅 = 𝑅1 ∪ 𝑅2 ∪ 𝑅3;

Verticala – partitonarea relatiei dupa atributele sale. Un fragement contine toate n-

uplurile relatiei, insa numai anumite atribute ale acesteia. Pentru refacerea relatiei initiale

este necesara o operatie de tip join insa pentru realizarea acesteia fragmentele trebuie sa

contina ca informatie redundanta macar atributul cheie al relatiei initiale. Se observa ca

fragmentarea pe verticala necesita un grad mai mare de redundanta pentru pastrarea in

fiecare fragment a atributului cheie. Fie o relatie R si S1, respectiv S2 doua subseturi de

atribute ale lui R, ambele subseturi contin cel putin un atribut cheie si reuniunea celorlalte


21

atribute contine toate atributele lui R, prin fragmentarea pe verticala vom obtine

fragmentele R1 si R2 astfel: 𝑅1 = 𝑃𝑆1(𝑅) si 𝑅2 = 𝑃𝑆2(𝑅), iar 𝑅 = 𝑅1 ∗ 𝑅2, in care am

notat cu * simbolul operatiei NATURAL JOIN.

Hibrida – vazuta ca o combinatie intre fragmentarea orizontala si verticala sau invers. In

functie de ordinea in care fragmentarea a fost facuta refacerea relatiei initiale se face fie

printr-o operatie JOIN urmata de UNION, fie UNIONurmate de JOIN. Daca consideram

relatia Angajat in care am facut fragmentarea pe orizontala avand in relatia Ang1

angajatii cu un salariu mai mare de 1000 lei si in relatia Ang2 angajatii cu un salariu mai

mic de 1000 lei dupa care angajatii din Ang1 sunt impartiti dupa D_nr in doua relatii,

cei care apartin D_nr 2 sau 5 si restul, respectiv cei din Ang2 ca apartinand

departamentelor 6 sau 4, respective ceilalti se va obtine structura din fig. 3.1.

Angajat

Ang1 (Salariu >1000) Ang2 (Salariu <1000)

Ang11 Ang12 Ang21 Ang22

(D_nr 2 sau 5) (D-nr 4 sau 6)

Fig.3.1 Fragmentarea mixta a relatiei Angajat

Indiferent de modul de fragmentare pentru proiectarea unei baze de date distribuite se au in

vedere urmatoarele:

Realizarea pe cat posibil a accesului la date local, adica plasarea fragmentelor pe nodurile

care utilizeaza datele si eventual utilizarea de copii ale fragmentelor daca aplicatia

permite;

Replicarea fragmentelor astfel incat sa se asigure o fiabilitate si o disponibilitate cat mai

mare;

Optimizarea utilizarii resurselor astfel incat incarcarea nodurilor sa fie cat mai

echilibrata;

Diminuarea pe cat posibil a costurilor comunicatiei prin minimizarea interogarilor ce

implica mai multe noduri. Realizarea dezideratului duce la cresterea redundantei prin

replicarea fragmentelor, dar are dezavantajul major al costurilor si complicatiilor privind

asigurarea consistentei datelor.

Indiferent de modul de fragmentare, baza de date initiala trebuie sa poata fi refacuta din

fragmente printr-un set de operatii. Fragmentarea unei baze de date trebuie sa satisfaca un set

minimal de reguli:

Completitudinea – prin descompunerea in fragmente a unei relatii sa nu se piarda date.

Daca o relatie R se descompune in fragmentele R1, R2, …, Rk, orice data care se gaseste

in relatia R trebuie sa poata fi gasita in fragmentele descompunerii;


22

Reconstructia – Daca o relatie R este descompusa in fragmentele R1, R2, …, Rk, exista un

operator (un set de operatii) prin care relatia R este reconstruita din fragmentele sale fara

a pierde nici o informatie;

Disjunctia – acceasi informatii nu se gaseste in mai multe fragmente. Exceptie la

fragmenatarea verticala atributul cheie primara.

3.2. Alocarea datelor

Pentru a rezolva problema alocarii in baze de date distribuite pornim de la urmatoarele:

Baza de date este descompusa intr-un numar de fragmente 𝐵𝐷 = 𝐹1, 𝐹2 , …𝐹𝑛 ;

Baza de date se distribuie pe un numar de noduri 𝑆 = 𝑆1, 𝑆2, . . , 𝑆𝑝 ;

Asupra bazei de date se aplica setul de operatii 𝑂 = 𝑂1, 𝑂2, . . , 𝑂𝑚 .

Rezolvarea problemai alocarii presupune determinarea nodurilor la care se distribuie fragmentele

in contextul efectuarii operatiilor specificate, cu restrictia ca fiecare fragment este alocat macar

unui nod, dar poate sa fie gazduit de mai multe noduri. Pentru determinarea distributiei optime a

fragmentelor trebuie definite cateva criterii. In principal se ia in consideratie minimizarea

costurilor exprimata uzual prin timpul de utilizare(incluzand comunicatie, stocare si procesare),

timpul de raspuns si o serie de constrangeri impuse de nodul pe care se distribuie fragmentul din

punctual de vedere la spatiului de stocare si a capacitatii de procesare. In literatura de specialitate

sunt prezentati o serie de algoritmi de distributie pe baza costurilor totale, insa modelele sunt

destul de simpliste neluand in consideratie operatorii aplicati in cereri.

Se cunosc mai multe tehnici de alocare, nu toate duc la o baza de date distribuita:

Alocare centralizata – toata baza de date este gazduita de un singur nod, celelalte noduri

accesand baza de date pentru prelucrarea distribuita. Un astfel de model are

disponibilitate scazuta intrucat defectarea nodul care gazduieste baza sau pierderea

comunicatiei afecteaza toate serviciile;

Alocare fragmentata (partitionata) – baza de date descompusa in fragmente disjuncte este

stocata pe mai multe noduri. In acest caz fara replicarea unor fragmente se reduce costul

de stocare, poate imbunatatii interogarile locale, are o disponibilitate mai mare si poate

reduce costurile de comunicatie daca distribuirea este riguroasa;

Alocare complet replicata – atunci cand pe fiecare nod se gaseste o copie completa a

bazei de date. Efectele constau in cresterea disponibilitatii, interogarile sunt efectuate

local, insa cresc costurile pentru stocare si creaza mari probleme la actualizarea datelor

atat din punctual de vedere al consistentei dar si cresterea costurilor comunicatiei pentru

replicare;

Alocare selectiv replicata – este o tehnica prin care se incearca sa se imbine cat mai

armonios avantajele celorlalte metode in paralel cu diminuarea dezavantajelor;

Daca raportul 𝐼𝑛𝑡𝑒𝑟𝑜𝑔𝑎𝑟𝑖 𝑐𝑒 𝑎𝑐𝑐𝑒𝑠𝑒𝑎𝑧𝑎 𝑑𝑎𝑡𝑒𝑙𝑒 (𝑛𝑢𝑚𝑎𝑖 𝑟𝑒𝑎𝑑 )

𝐼𝑛𝑡𝑒𝑟𝑜𝑔𝑎𝑟𝑖 𝑐𝑢 𝑎𝑐𝑡𝑢𝑎𝑙𝑖𝑧𝑎𝑟𝑒 (𝑤𝑟𝑖𝑡𝑒 )> 1 replicarea este avantajoasa.

Atunci cand raportul este subunitar, adica numarul interograrilor ce au ca efect


23

actualizarea este mai mare, replicarea constituie o complicatie pentru pastrarea

consistentei datelor.

Fragmentarea si alocarea, respectiv definirea replicilor este realizata in faza de analiza, faza in

care se incearca optimizarea operatiilor frecvent executate tinand cont si de locul in care sunt

pastrate datele de interes si de accesul la date cere operatii read sau write.

3.3. Distribuirea datelor

Una dintre principalele sarcini ale unui SGBD distribuit este cea de distribuirea tuturor datelor,

atat a celor de baza cat si a celor auxiliare. Functie de tipul dateor distribuite avem:

Distribuirea datelor de baza –Prindate de baza intelegem informatiile din baza de date propriu-

zisa, care in cazul modelului relational inseamna tabelele de baza. Tehnicile specifice pentru

distributie sunt:

o Distributie prin fragmentare. Am aratat ca fragmentarea este operatia de descompunere

logica a colectiilor globale, dintr-o baza de date distribuita, in parti disjuncte numite

fragmente. SGBD-ul distribuit realizeaza fragmentarea prin intermediul unor operatori

speciali aplicati colectiilor globale. De exemplu, daca se implementeaza un model

relational de organizare a datelor, SGBD-ul va folosi operatorii relationali aplicati

tabelelor globale si vor rezulta framgentele;

o Distributie prin replicare. Replicarea este operatia de stocare (memorare) a unor

portiuni dintr-o baza de date, sub forma de copii, pe mai multe calculatoare dintr-o retea.

SGBD-ul distribuit asigura automat sincronizarea tuturor copiilor in caz de actualizare a

datelor. Acest lucru inseamna ca daca un anumit utilizator actualizeaza o copie locala,

SGBD-ul distribuit va trebui sa actualizeze automat toate copiile acelorasi date, oriunde

s-ar afla in retea;

o Distributie mixta. Aceasta tehnica de distribuire a datelor, asa cum indica si numele ei,

presupune aplicarea succesiva a replicarii si fragmentarii pentru aceeasi colectie de date

dintr-o baza de date. Presupunand ca o colectie globala este mai intai fragmentata,

ulterior unul sau mai multe fragmente pot fi replicate. Invers, presupunand ca o colectie

de date este mai intai replicata, ulterior una sau mai multe dintre copii pot fi fragmentate.

Tehnica incearca sa maximizeze avantajele celorlalte doua dar este mai greu de

implementat.

Distribuirea datelor din catalog.Functiile de administrare trebuie extinse datorita problemelor

ce apar prin distribuirea datelor, in comparatie cu o baza de date locala. Daca sistemele de la

nivelul local au autonomie redusa atunci administrarea distribuita nu se deosebeste prea mult de

administrarea centralizata normala si functiile de administrare sunt influientate foarte mult de

procedurile de distributie utilizate. In opozitie, daca sistemele de la nivel local au o autonomie

ridicata, atunci administrarea distribuita va avea sarcini limitate la nivel local, ocupandu-se mai

mult de problemele globale la nivel de retea.

Catalogul bazei de date distribuite. Considerand arhitectura pe niveluri pentru o baza de date

distribuita, catalogul aferent bazei de date distribuite va contine o serie de informatii necesare


24

optimizarii accesului la date si asigurarii integritatii si securitatii datelor. Aceste informatii se

refera la schema globala, la schema de fragmentare, schema de alocare, la controlul accesului la

date. Dupa cum se observa, catalogul bazei de date distribuite contine informatii obisnuite unui

catalog la care se adauga altele informatii specifice distribuirii. Vor fi prezentate in continuare

cele mai importante informatii ce sunt continute intr-un astfel de catalog:

informatiile despre schema globala: numele colectiilor globale, numele campurilor din

fiecare colectie;

informatii despre fragmentare: calificarea fragmentelor, coloanele fragmentelor, arborele

de fragmentare prin calificare si descrierea fragmentelor prin campuri;

informatii despre alocare: legaturile dintre fragmentele si imaginile fizice ale colectiilor

globale, precum si legaturile dintre imaginile fizice si datele memorate pe fiecare locatie

distribuita;

informatii despre accesul la date: metadatele de acces utilizate la fiecare locatie (index,

hash, pointeri), restrictiile de integritate impuse la descrierea datelor, elemente referitoare

la securitatea datelor;

informatii statistice: reprezentate prin indicatori statistici care dau profilul bazei de date.

Rolul catalogului bazei de date distribuite este de a furniza, in orice moment, informatii

actualizate despre starea bazei de date. Catalogul este creat si actualizat automat de SGBD-ul

distribuit, el fiind accesibil utilizatorilor numai pentru operatii de citire. Catalogul bazei de date

distribuite ajuta la procesarea datelor datorita urmatoarelor aspecte:

Baza de date distribuita este accesata de diferitii utilizatori in cadrul anumitor aplicatii.

Un SGBDD asigura pentru acestia diferite niveluri de transparenta avand acces la datele

fizice prin intermediul informatiilor din catalog;

Un SGBDD distribuit realizeaza o utilizare eficienta a datelor prin implementarea unor

algoritmi de optimizare a alocarii si accesului la date. Acesti algoritmi, declansati

automat sau la cererea utilizatorului, au nevoie de informatii ce se gasesc in catalogul

bazei de date distribuite;

Cand un utilizator doreste sa acceseze baza de date in cadrul unei aplicatii, SGBDD

verifica drepturile de acces si, in caz favorabil, realizeaza conectarile corespunzatoare.

Distribuirea catalogului. Similar cu administrarea unui SGBDD, catalogul bazei de date

distribuite depinde de gradul de autonomie locala al statiilor din configuratie. Astfel, daca exista o

autonomie locala ridicata, atunci gestiunea datelor, inclusiv cele din dictionar, se realizeaza pe

statia respectiva, independent de celelalte masini pe care este stocata baza de date. Daca, de

exemplu, in sistem se adauga un nou obiect, in catalogul distribuit se adauga un nume unic fara a

se accesa toate cataloagele locale. Din contra, daca nu exista autonomie locala, iar in sistem se

adauga un nou obiect, atunci se vor consulta toate cataloagele locale. Rezulta ca distribuirea

catalogului depinde de autonomia locala si atunci ea poate fi realizata in urmatoarele variante:

replicat, local, centralizat, mixt.


25

Prin catalog replicat intelegem multiplicarea lui pe toate masinile din retea. Solutia este

avantajoasa intrucat duce la scaderea timpului de acces pentru consultarea catalogului,

dar are si dezavantajul cresterii spatiului de stocare si a timpului consumat pentru

actualizarea sa.

Catalogul centralizat presupune alocarea lui la o singura locatie. Are avantajul reducerii

spatiul de stocare si simplificarea implementarii, dar si dezavantajul complicarii accesului

concurent la catalog cat si scaderea fiabilitatii sistemului avand un singur punct de

defectare ceea ce face intreg sistemul nefunctional.

Catalogul local presupune fragmentarea si alocarea lui in acelasi mod cu datele din

colectia globala pe care le refera. Prezinta avantajul reducerii spatiului de stocare si a

timpului de actualizare, dar si dezavantajul cresterii timpului de consultare.

Catalogul mixt presupune combinarea a doua sau a toate trei variantele de mai sus. Un

astfel de catalog are avantajul ca pot fi valorificate facilitatile oferite de diversele

variante, dar si dezavantajul implementarii mai greoaie a solutiei, datorita complexitatii

mari.

3.4. Considerente legate de transparenta

Intr-o baza de date distribuita trebuie asigurata transparenta fata de utilizatorul sistemului pentru

care operarea trebuie sa fie identica cu operarea intr-un sistem centralizat. Cu alte cuvinte

utilizatorul nu trebuie sa cunoasca unde sunt stocate datele accesate si nici faptul ca o tranzactie

initiata de el necesita modificarea datelor ce se gasesc pe un alt nod. In mod uzual utilizatorul nu

specifica accesul la fragmente, ci se adreseaza bazei de date similar cu cererile pentru o baza de

date centralizata. Similar cu operarea in baza de date centralizata, intr-o baza de date distribuita

fiecare obiect are un identificator (nume) unic. Referirea la orice obiect de tip tabela va fi facuta

prin numele sau sinu pot exista pe doua noduri obiecte cu nume identice. Utilizarea unui server

central de nume nu este o solutie acceptabila intrucat acesta constituie un singur punct de

defectare. O solutie acceptabila ce a fost imbratisata si de Oracle este cea prin care identificatorul

de nume global este format prin prefixarea numelui obiectului cu numele de domeniu al

serverului din retea ce gazduieste obiectul. Printr-un astfel de identificator se pierde transparenta

la alocare, insa poate fi recapatata prin utilizarea se sinonime (sectiunea 4.4). Chiar daca

utilizatorul stie ca baza de date este fragmentata si utilizeaza la un anumit moment un anumit

fragment, faptul ca nu cunoaste localizarea constituie un avantaj pentru orice operatie de

reorganizare a bazei de date si implicit a realocarii fragmentelor.

Foarte importanta este transparenta la executia tranzactiilor distribuite si pastrarea integritatii

bazei de date. In mod obisnuit o tranzactie distribuita necesita accesarea si/sau modificarea

datelor stocate la mai multe noduri. Pentru pastrarea proprietatilor ACID o serie de mecanisme

suplimentare trebuie sa gestioneze executia tranzactiilor distribuite. De regula o tranzactie este

impartita in subtranzactii sau agenti, cate unapentru fiecre nod ce participa la tranzactie. Sistemul

de gestiune al bazei de date distribuit trebuie sa asigure indivizibilitatea atat a tranzactiei globale


26

cat si a tuturor subtranzactiilor. Asigurarea atomicitatii si durabilitatii tranzactiei globale

presupune ca fie toate subtranzactiile tranzactiei globale sunt rezlizate, fie toate sunt revocate.

Din punctul de vedere al performantelor, acestea nu trebuie sa fie afectate de arhitectura

distribuita sau sa duca la cresterea costurilor pentru executia cererilor. Procesorul de cereri

mapeaza datele cerute intr-o secventa de operatii ordonate la baza de date locala ca apoi sa poata

lua in consideratie fragmentarea, replicarea si schema de alocare. El va trebui sa decida ce

fragmente sau copii ale acestuia acceseaza si de la ce locatii.

Operatiile specifice ce trebuiesc realizate de un astfel de sistem sunt:

Interogarea de la distanta - regasirea de date dintr-una sau mai multe tabele ale unei baze

de date, date care sunt pastrate pe un nod situat la distanta fata de nodul de unde s-a emis

cererea de regasire.

Tranzactia la distanta- este o secventa de una sau mai multe instructiuni care face referire

la acelasi nod situat la distanta fata de nodul de unde a fost lansata tranzactia in executie.

Actualizarea la distanta- este o operatie de aducere la zi a datelor dintr-una sau mai multe

tabele situate pe acelasi nod, nod situat la distanta fata de nodul de unde a fost initiata

actualizarea.

Interogarea distribuita- este operatia prin care se regasesc date ce sunt pastrate pe doua

sau mai multe noduri distincte.Un caz tipic este cel in care intre tabele gazduite de noduri

diferite se efectueaza o operatie join.

Tranzactia distribuita- este o secventa de una sau mai multe instructiuni care face referire

la date gazduite de doua sau mai multe noduri distincte.

Actualizarea distribuita- este operatiaprin care datele gazduite de doua sau mai multe

noduri distincte sunt modificate.

Un exemplu de SGBD distribuit care gestioneaza o arhitectura distribuita de baze de date este

Oracle. Acesta integreaza toate bazele de date membre ale unei arhitecturi distribuite sub forma

unei singure baze de date logice. Fiecare baza de date este autonoma ca intretinere si

administrare dar beneficiaza de posibilitatea de a accesa date din celelalte baze de date. Sisteme

de gestiune baze de date distribuite aflate curent in exploatare nu au o arhitectura unica. Multe

dintre ele implementeaza diferite variante ale unei arhitecturi de referinta. Astfel de arhitecturi de

referinta au fost elaborate de ANSI/SPARC si IBM.


27

4. Executia cererilor distribuite

Am vazut ca cererile catre baza de date pot fi executate local daca obiectele invocate sunt

gazduite pe nodul local, executate distant daca obiectele invocate se gasesc pe un singur nod

distant sau sunt cereri distribuite daca invoca obiecte dispuse pe cel putin doua noduri. In oricare

dintre cazuri pentru executia unei cereri este necesara mai intai localizarea datelor. Daca o cerere

este adresata unui singur nod atunci acea cerere va fi procesata de nodul care detine datele

solicitate. Sunt insa situatii in care cererea necesita date de la mai multe noduri caz in care

cererea se descompune in subcereri ce sunt executate de nodurile ce detin datele dupa care

rezultatele vor fi agregate. Pentru exemplificare, consideram fragmentarea pe orizontala a tabelei

Angajat (Nume, Titlu, Salariu, Dep_nr, Adresa, Functia, Varsta,

Angajat_id) in doua fragmente, unul pastrat la Bucuresti in care sunt pastrate n-uplurile

pentru care valoarea campului salariu este mai mare de 1000 si altul la Iasi in care sunt pastrate

n-uplurile pentru care valoarea campului salariu este mai mica sau egala cu1000.

Obs: Campul Varsta introdus in tabela Angajat indica e eroare de proiectare intrucat trebuie

sa fie actualizat dupa ziua de nastere a persoanei, dar am dorit focalizarea pe executia cererilor

distribuite. Uzual intr-o baza de date nu se pastreaza date ce pot fi calculate sau care necesita

actualizare permanenta. O buna proiectare pastreaza in tabela o coloana Data_nasterii, iar

varsta se obtine printr-o operatie intre data curenta si data nasterii, ca de exemplu

YEAR(date())-YEAR(data_nasterii).

Daca tabela Angajat nu ar fi fost fragmentata si distribuita la doua noduri, cererea ce produce

media varstei angajatilor ce au salariu cuprins intre 800 si 1200 se scrie:

SELECT AVG(Varsta)

FROM ANGAJAT

WHERE Salariu >800 AND Salariu <1200

Pentru baza de date fragmentata nu poate fi obtinut un rezultat corect daca se cere determinarea

mediei varstei la fiecare nod dupa care sa se faca agregarea rezultatului, ca in exemplul:

SELECT AVG(Varsta)

FROM ANG1

WHERE Salariu >800

cerere care executata de nodul de la Iasi, respectiv urmataoarea cerere executata de nodul de la

Bucuresti.

SELECT AVG(Varsta)

FROM ANG2

WHERE Salariu <1200


28

urmata de calculul mediei celor doua rezultate. Pentru executie corecta este necesara executia la

fiecare locatie a cate unei cereri prin care se calculeaza SUM(Varsta) si COUNT(*) si cu

aceste informatii se va calcula rezultatul final ca (sum(Varsta) +

sum(Varsta))/(count(*)+count(*)). O alta varianta presupune calculul la fiecare

locatie a Avg(Varsta) si a Count(*) si la agregarea rezultatului se va face o medie

ponderata. Pot exista cereri similare ce pot fi executatela o singura locatie (nod). Daca o cerere

similara cere determinarea mediei varstei angajatilor cu salariu mai mare de 1100 procesarea se

realizeaza de o singura locatie.

Sa consideram situatia in care tabela Angajat a fost fragmentata pe verticala pastrand la

Bucuresti campurile Angajat_Id, Titlu, Salariu, Functia si la Iasi campurile:

Nume, Varsta, Angajat_Id, Adresa. Pentru reconstractia tabelei initiale este

necesara o operatie natural join prin care se combina inregistrarile din cele doua fragmente pe

baza campului Angajat_Id. In acest caz se pune problema unde se executa operatia de join,

intrucat daca se executa la Iasi trebuie transmis fragmentul pastrat la Bucuresti sau pentru

executia la Bucuresti se transmite fragmentul stocat la Iasi. Urmarind un criteriu de performanta

cum ar fi costul comuncatiilor pentru transportul fragmentului si pentru rezultat putem sa luam o

decizie functie de cantitatea de informatie transportata de la o locatie la alta. Un astfel de criteriu

nu este complet acoperitor intrucat executia este influientata si de puterea masinii care o

proceseaza si de gradul de incarcare al acesteia.

Consideram un caz mai general in care avem tabela Angajat si o tabela Lucreaza care

evidentiaza numarul de ore efectuate de fiecare angajat la un proiect, tabela ce are structura

Lucreaza(Angajat_id, Proiect_id, Ore).Cele doua tabele nu sunt fragmentate

dar una dintre ele este stocata pe un nod si cealalta stocata pe alt nod, iar cererea formulata

necesita o operatie de tip join intre cele doua tabele. Pentru a putea face calculul eficientei

operatiilor vom considera o unitate standard pentru volumul datelor,dimensiunea unei paginii si

functie de dimensiunea inregistrarilor putem determina numarul de inregistrari pe pagina pentru

fiecare tabela. Astfel, consideram ca tabela Angajat necesita pentru stocare 500 pagini, fiecare

pagina contine 80 de inregistrari, iar tabela Lucreazaare 1000 pagini cu cate 100 inregistrari

pe pagina. Ca urmare in tabela Angajat avem 80*500 = 40000 inregistrari si este stocata la

Bucuresti,pe cand tabela Lucreazacontine 100*1000 = 100000 inregistrari este stocata la Iasi.

Daca notam costul operatiei de citire/scriere pentru o pagina cu D si costul transportului unei

pagini cu S, operatia de join realizata la Bucuresti va avea costul:

Cost = 500*D+500*1000*(D+S)

Similar se poate calcula costul de operatiei facuta la cealalata locatie. Oricare dintre variante este

neeconomica intrucat trebuiesc transportate si date ce nu sunt de interes si nu se regasesc in

rezultatul final. Vom analiza doua posibilitati prin care volumul datelor transportate intre siteuri

se diminueaza:

Semijoin – are ca obiectiv reducerea volumului de date transportat de la o locatie la

cealalta. Astfel la una dintre locatii se efectueaza o operatie PROJECTpentru a pastra


29

numai coloanele de interes si rezultatul se transporta la cealalta locatie unde se face

operatia join. In multe situatii volumul datelor ce se transfera de la o locatie la ata poate fi

diminuat prin efectuarea de operatii SELECT-PROJECT, desigur daca cererea initiala

contine in clauza WHERE si conditii de tip SELECT.

Blommjoin – este o operatie prin care se diminueaza foarte mult volumul datelor

transportate de la un site la altul. Desigur ca, nu orice cerere se preteaza pentru o astfel de

tratare. Pentru a putea invoca operatie de tip blommjoin este nevoie ca datele de interes

ce trebuie incluse in rezultatul final sa fie disponibile pe siteul care efectueaza operatia si

o tabela ce se gaseste pe un site distant participa la operatie doar pentru validarea unei

conditii equjoin fara sa necesite alte coloane ale tabelei distante in rezultat. Deci,

operatia impune numai o conditie de join de tip egalitate ce se realizeaza intre campuri

aflate la locatii diferite. Sa presupunem ca datele de interes sunt localizate la Iasi dar

conditia de join presupune egalitatea dintre campul Angajat_Id al tabelei

Lucreazastocate la Iasi cu cel al tabeleiAngajat, stocata la Bucuresti, iar cererea

este initiata de catre nodul de la Iasi. In acest caz toate datele de interes se gasesc la nodul

Iasi dar trebuiesc luate in consideratie doar acele inregistrari ce indeplinesc conditia de

join cu inregistrarile tabelei stocata la Bucuresti sau altfel spus avem nevoie doar de

validarea conditiei de join cu o tabela de la alta locatie. O solutie care duce la

minimizarea volumului datelor transportate la Iasi se bazeaza pe definirea unei functii

hash care se aplica la fiecare valoare a campului Angajat_Id al tabelei stocate la

Bucuresti. Consideram ca rezultatul functiei hash asupra campului Angajat_Id are valori

numere naturale in gama [0,N-1]. Construim un vector de biti avand dimensiunea N,

initializat cu toti bitii 0. Se aplica functia hash definita la fiecare dintre valorile coloanei

dupa care se face join pentru tabela aflata pe nodul indepartat. Daca rezultatul functiei

hash pentru o anumita inregistrare este i, atunci bitul i al vectorului de biti este setat la

valoarea 1. Dupa parcurgerea intregii tabele in vectorul de biti avem atatea valori 1, in

pozitii corespunzatoare, cate rezultate a produs functia hash. Desigur ca, functia hash

trebuie sa fie rezistenta la coliziuni, adica sa nu produca acceasi valoare pentru oricare

doua valori distincte ale campului la care se calculeaza. Pentru o pozitie i a vectorului de

biti vom avea valoarea 1 daca rezultatul functiei hash a fost i, respectiv valoarea 0 daca

valoarea i nu a fost un rezultat al aplicarii functiei hash pe valoarea campului dupa care se

face join. Vectorul rezultat se transmite la cealalta locatie, costul comunicatiei fiind

extrem de mic intrucat este un vector de biti. Dupa primirea vactorului la celalalt nod se

calculeaza pentru fiecare inregistrare aceeasi functie hash pe camplul dupa care se face

join. Daca pentru o inregistrare valoarea functiei hash este i si in vector la pozitia i avem

un bit in starea 1 conditia de join este indeplinita si se culege in rezultatul final datele

dorite, iar daca in vector la pozitia corespunzatoare se gaseste valoarea 0 inseamna ca nu

se indeplineste conditia de join si datele respectivei inregistrari nu sunt duse in rezultat.

Blommjoin modificat. Tehnica descrisa poate fi aplicata si in situatia in care sunt

necesare si date gazduite de nodul indepartat. In acest caz se parcurg toti pasii descrisi la


30

bommjoin obtinand o tabela intermediara redusa care se trimite la locatia la care s-a

calculat vectorul initial si se continua operatia pentru a include in rezultat si alte campuri.

Dezavantajul major al metodei consta in faptul ca poate fi aplicata numai la operatia join

cu egalitate si eficienta depinde de gradul de reducere al tabelei. Pe de alta parte sunt rare

cazurile in care operatiile de join nu au conditii de tip egalitate, intrucat asa este construit

modelul relational prin legatura intre relatii. Raman in continuare problemele privind

constructia functiilor hash rezistente la coliziuni.

4.1. Implicatiile fragmentarii asupra executiei cererilor

Daca pentru distributia bazei de date aceasta se descompune in fragmente ce sunt gazduite de

nodurile componente ale sistemului, operatiile de recompunere se realizeaza functie de modul in

care relatia a fost fragmentata. In figura 4.1 se ilustreaza mai intai cazul fragmentarii pe

orizontala a relatiei R in fragmentele R1 si R2, dupa care R1 este fragmentat pe verticala in R11 si

R12, iar R2 in R21 si R22. Pentru refacerea relatiei R se vor executa operatii de join obtinand R1 si

R2 si prin reuniune se va obtine R. Al doilea arbore descrie procesul de reconstructie a relatiei

initiale.

Fig. 4.1 Fragmentarea si reconstructia unei relatii

Sa luam pentru exemplificare urmatoarea structura a tabelelor in baza de date centralizata:

Angajat(Nume, Ang_Id……)

Lucreaza(Ang_Id,Ore, P_nr, Responsabil, …..)

Cererea prin care se doreste sa se obtina numele angajatilor care lucreaza la proiecte la care

responsabil este Popescu se va scrie:

SELECT A.Nume

FROM Angajat A, Lucreaza L

WHERE A.Ang_Id = L.Ang_Id and Responsabil =”Popescu”

In algebra relationala cererea implica o operatie Project efectuata asupra rezultatului operatiei

Select avand conditia Responsabil=”Popescu” din rezultatul operatiei Join intre Lucreaza si

Angajat, ca in exemplul:

R

R1 R2

R11 R12 R21 R22

H H

V V V V

>< ><

R11 R12 R21 R22

U


31

PNume (SResponsabil = “Popescu” (Lucreaza >< Angajat)

Daca vom considera baza fragmentata orizontal in fragmentele Ang1, Ang2, Lucr1, Lucr2 ce

sunt stocate la locatiile N1, N2, N3, N4 si cererea este formulata de catre un utilizator aflat la

locatia 5 se obtine urmatoarea schema de executie (fig. 4.2):

Fig. 4.2 Exemplu de procesare cerere distribuita

Desigur ca, aceasta nu este singura varianta de executie a cererii. O alta varianta poate fi

reuniunea fragmentelor Ang1 si Ang2, dupa care join cu rezultatul operatiei SELECT avand

conditia responsabil=”Popescu” din rezultatul reuniunii fragmentelor Lucr1 si Lucr2, urmate

de o operatie PROJECT ce are in lista de atribute atributul Nume:

P Nume ((Ang1 U Ang2) >< (Sresponsabil = “Popescu” (Lucr1 U Lucr2)))

In general, o procesare a cererii urmareste executia dupa s schema similara cu cea ilustrata in

figura 4.3.

Fig. 4.3 Executie cerere distribuita

Decompozitie cerere

Conversie cerere in alg. relationala pentru relatii dustribuite

Localizarea datelor

Cerere pe fragment

Otimizare globala

Cerere optimizata pe fragmente

Otimizare locala

Cerere optimizata local

Schema globala

Schema fragmente

Schema locala

Statistica fragmentelor

Locatia 5 Ang11 U Ang21

Ang11=Ang1><Lucr11 Ang21=Ang2><Lucr21

Lucr11= SResponsabil =“Popescu” (Lucr1) Lucr21= SResponsabil =“Popescu” (Lucr2)

Locatia 1 Locatia 2

Locatia 3 Locatia 4


32

O etapa extrem de importanta in executia cererilor distribuite este cea de decompozitie prin care

se procedeaza la: scrierea in forma normalizata (forma conjunctiva), analiza sintactica,

simplificarea (eliminarea predicatelor redondante), restructurare in forma algebrica facuta pe

baza schemei globale a bazei de date. Toate aspectele discutate pana in prezent nu au luat in

consideratie actualizarile datelor din baza de date. Atunci cand punem si problema actualizarii

este foarte importanta consistenta datelor si modul in care se face sincronizarea.

4.2. Executia tranzactiilor

Intr-un sistem de baze de date distribuite se permite aplicatiilor sa acceseze date de la baza de

date locala sau de la o baza de date indepartata. Sistemul este compus din mai multe servere de

baze de date, fiecare server gestioneaza o baza de date locala. Ansamblul bazelor de date,

gestionate de fiecare server formeaza baza de date distribuita. Spre deosebire de baza de date

centralizata care include un singur server de baze de date raspunzator de stocarea, accesul si

prelucrarea datelor local, pentru o baza distribuita trebuie asigurata comunicatia intre serverele

ce pastreaza fragmente ale bazei de date. Arhitectura client/server permite pentru baze de date

centralizate formularea cererilor clientilor catre serverul responsabil de servirea acestora. Pe un

astfel de model se bazeaza si bazele de date distribuite, in plus un server de baze de date

actioneaza ca un client pentru alte servere de baze de date atunci cand cere date stocate de acesta,

deci poate avea rol de server, client sau ambele la diverse momente.

Functie de sistemele de gestiune a bazei de date instalate pe nodurile ce indeplinesc functia de

server de baze de date putem clasifica o baza de date distribuita in:

Sisteme de baze de date distribuite omogene. Un sistem de baze de date distribuit este

omogen daca doua sau mai multe sisteme de gestiune a bazei de date de acelasi timp (ale

aceluiasi producator) sunt instalate pe una sau mai multe masini (noduri). Spre exemplu

un sistem in care toate sistemele de gestiune a bazei de date foloseste mediul Oracle este

un sistem omogen. Intr-un astfel de sistem o aplicatie poate accesa si modifica simultan

date stocate pe diversele componente ale sistemului distribuit printr-o singura cerere sau

o tranzactie fara a necesita cunoasterea locatiei datelor. In figura 5.1. sistemul de baze de

date distribuit este compus din bazele de date Manag(pentru management),

Product(pentru productie), Vanzari ce sunt stocate pe trei noduri ale retelei, pe

fiecare dintre acestea ruland acelasi server de baze de date. Din punct de vedere logic la

fiecare server sunt conectati proprii clienti ce acceseaza baza de date la care sunt

conectati similar cu o baza de date centralizata. Sistemul distribuit trebuie sa asigure o

modalitate de accesare a datelor stocate pe serverele indepartate. Arhitectura nu impune

ca pe servere sa fie instalata aceeasi versiune a SGBD, cu toate ca versiunea instalata

trebuie sa inteleaga functionalitatea distribuita. Astfel, intr-un sistem omogen cu baze de

date Oracle pe fiecare nod trebuie instalata o versiune ce intelege extensiile SQL pentru

baze distribuite disponibile incepand cu versiunea Oracle 9i [ODAG].


33

BD

Manag

BD

Product

BD

Vanzari

BD distribuita

.

.

.

Fig. 5.1 Baza de date omogena distribuita

Sisteme de baze de date distribuite eterogene. Intr-un sistem eterogen cel putin un server

de baze de date ruleaza un SGBD de la un alt producator. Pentru aplicatii o baza

distribuita eterogena este vazuta ca o singura baza de date avand tipul mediului de baza

de date instalat pe masina la care un client este conectat ascunzand distributia si

caracterul eterogen. Pentru ca un server sa acceseze un alt server de baze de date ce

ruleaza un alt SGBD este nevoie sa utilizam un serviciu in conjunctie cu un agent. Spre

exemplu, un server Oracle ce acceseaza un server non-Oracle va utiliza Oracle

Transparent Gateway ca agent. Daca intr-un sistem distribuit Oracle se include o baza de

date Sybase este nevoie de “Sybase-specific transparent gateway” pentru a putea

comunica cu el. Un astfel de agent, specific pentru fiecare sistem de baze de date trebuie

instalat in sisteme eterogene. O alternativa este utilizarea “generic connectivity” daca

sistemul non-Oracle suporta protocoalele ODBC sau OLE DB. Conectivitatea generica

permite conectarea la alte baze de date fie prin Heterogeneous Services ODBC sau

Heterogeneous Services OLE DB. Conectivitatea generica nu cere achizitia si

configurarea unui agent specific, cu toate ca de regula, nu sunt disponibile toate

facilitatile de acces.

Accesul la baza de date in aplicatii multiuser se bazeaza pe arhitectura client/server. In general, o

arhitectura client/server presupune proiectarea unei aplicatii avand doua componente:

componenta server si componenta client, ce pot rula pe aceeasi masina sau pe masini diferite

conectate intr-o retea. Procesul server este un process reactiv ce primeste cereri de procesare de

la procesele client si dupa procesare transmite rezultatele catre client. Procesul client este un

process proactiv care implementeaza interfata utilizator, formuleaza cererile, le trimite la server

si asteapta rezultatele procesarii. Intr-o arhitectura de baza de date distribuita un server de baze

de date poate avea roluri diferite in diferite momente. Un server de baze de date gestioneaza o

baza de date iar clientul este o aplicatie care cere informatii de la server. Un nod poate avea rol

de server atunci cand furnizeaza date clientilor sau are rol de client atunci cand cere date de la un

alt server. Spre exemplu, in figura 5.2 serverul Manag actioneaza ca un server de baze de date

atunci cand o instructiune executata are nevoie doar de date stocate local, dar este vazut ca un


34

client atunci cand instructiunea executata necesita date stocate intr-o baza de date de la alt server

(ex, Product). Asa cum se vede in figura tab ela Dept in care se executa o operatie INSERT

este locala, pe cand tabela Prod la care executa o operatie UPDATE este distanta.

BD

Manag

BD

Product

Database linkCerere formulata

serverului de catre

client

INSERT INTO Dept ...

UPDATE Prod ….

COMMIT

Dept Prod

Server Server

Fig. 5.2 Arhitectura client/server

Conectarea unui client la un server de baze de date poate fi facuta direct sau indirect. Spunem ca

avem o conexiune directa la serverul de baze de date atunci cand clientul este conectat la acea

baza de date si acceseaza informatiile din baza de date gestionata de acel server. Daca serverul

Manag gazduieste tabela Dept si un client conectat la baza de date Manag executa

instructiunea

SELECT * FROM dept;

spunem ca avem o conexiune directa.

O conectare indirecta se produce atunci cand un client conectat la un server doreste sa acceseze

informatii gazduite de un alt server de baze de date. De exemplu, clientul este conectat la baza

Manag si doreste sa vizualizeze continutul tabelei Prod, gazduita de baza de date Product,

formuland cererea

SELECT * FROM prod@product...;

Cerearea este indirecta, prin serverul Manag catre obiectul stocat in baza de date Product.

Vom vedea intr-un paragrafele ulterioare cum se face referirea la obiectul prod al bazei de date

product. Majoritatea mediilor de baze de date relationale au fost dezvoltate pentru operarea cu

baze de date centralizate. Daca luam, ca exemplu,sistemul ORACLE care implementeaza

modelul de date relational, pentru operarea cu baze de date distribuite, constatam ca acesta a fost

extins cu facilitati de distribuirea datelor. Intr-o arhitectura distribuita ORACLE, se integreaza

toate bazele de date membre ale arhitecturii ca o singura baza de date logic distribuita. Fiecare

baza de date este autonoma in ceea ce priveste intretinerea si administrarea ei, dar poate accesa si

partaja date cu celelalte baze de date membre. Pentru conectarea si comunicarea in retea a

calculatoarelor pe care se gasesc date, la ORACLE server a fost introdusa o componenta

specifica, numita SQL*Net, prin care se permite celorlalte componente ORACLE sa comunice

intre ele prin infrastructura de retea. Prin intermediul acestei componente se permite utilizatorilor


35

conectarea, accesarea si actualizarea datele din orice nod. Pentru ca obiectele bazelor de date sa

fie corect referite, trebuie sa aiba asociat un identificator unic. Oracle permite definirea numelor

tuturor obiectelor din baza de date distribuita ca nume globale unice [ODAG]. Pentru fiecare

baza de date, numele global se specifica prin doi parametrii:

bd_nume prin care de precizeaza numele bazei de date ca obiect global si ca obiect local;

bd_domain prin care se indica localizarea bazei de date in structura de retea.

Elementul central in sistemul de baze de date distribuit Oracle este “database link”, o conexiune

logica intre doua baze de date fizice prin care se permite unui client sa acceseze o baza de date

distanta. Principial, un database link este asimilat cu un pointer ce defineste o cale de

comunicatie unidirectionala intre un server de baze de date si un alt server de baze de date.

Pentru a se accesa un link utilizatorul trebuie sa fie conectat la baza de date localasi aceasta sa

contina in dictionar o intrare corespunzatoare pointerului. Daca avem doua baze de date notate X

si Y si un utilizator este conectat la baza de date X ce contine in dictionarul de date o intrare

pentru pointerul catre baza de date Y, utilizatorul poate accesa prin intermediul pointerului

obiecte ale bazei de date Y. Intrucat pointerul este pastrat in baza de date X un alt utilizator

conectat la baza de date Y nu poate sa-l foloseasca pentru accesul obiectelor stocate in baza de

date X. Pentru ca un utilizator al bazei de date Y sa poata accesa date stocate in baza de date X

acesta trebuie sa defineasca un database link care va fi stocat in baza de date Y. Altfel spus, un

database link creaza o conexiune unidirectionala de la baza de date X la baza de date Y. Pentru

ca o conexiune printr-un database link sa fie posibila fiecare baza de date distribuita trebuie sa

aiba un nume global unic in domeniul retelei, nume ce identifica unic o baza de date si serverul

in sistemul distribuit. In figura 5.3 se ilustreaza accesul la un obiect al unei baze de date distante

de catre un utilizator conectat la o baza de date locala prin intermediul unui database link. Marele

avantaj al unui database link este ca el permite utilizatorilor sa acceseze alte obiecte utilizator

dintr-o baza de date distanta cu privilegiile stabilite de proprietarul obiectelor. Practic cererea

este tunelata se serverul local catre serverul la care s-a creat legatura.

BD

Locala

BD

distanta

Prod

SELECT *

FROM Prod

Database

link

Fig. 5.3 Accesul la o baza de date distanta

O caracteristica importanta a unui database link este data de modul in care se realizeaza

conexiunea si din acest punct de vedere avem urmatoareale tipuri de link-uri:

Connected user link. Este o conexiune prin care utilizatorii se conecteaza la baza de date

indepartata ca ei insasi, ceea ce inseamna ca ei trebuie sa aiba un cont la baza de date

indepartata cu acelasi nume de utilizator si parola cu cea a contului aferent bazei de date

locale;


36

Fixed User Link. Este o conexiune prin care utilizatorul se conecteaza folosind numele

de utilizator si parola precizate in definitia link-ului, adica numele si parola sunt fixate

odata cu definirea link-ului. In acest caz utilizatorul ion, care utilizeaza un fixed user

link avand nume utilizator emil si parola a397a ce conecteaza baza de date Manag cu

baza de date Product se va conecta la baza de date Product ca utilizatorulemil si va

avea toate privilegiile si rolurile pe care emil le are la aceasta baza de date. Cu o astfel

de conexiune se creaza utilizatori neglobali la o baza de date distanta cu nume utilizator

si parola pastrate necriptat in dictionarul de date. Un astfel de link este usor de creat,

necesita informatii suplimentare minimale, nu necesita canal de comunicatie SSL, dar

prezinta o vulnerabilitate majora de securitate prin faptul ca parola este stocata in clar.

Exemple:

o CREATE PUBLIC DATABASE LINK product.aii.pub.ro CONNECT

TO emil AS a379c – un link global public ce utilizeaza numele global al

bazei de date product, iar conexiunea cu baza de date distanta este facuta cu

user/pass emil/a379c.

o CREATE DATABASE LINK leg3 CONNECT TO emil IDENTIFIED

BY a379c USING „service‟ – un link privat fixat cu numele leg3 ce

utilizeaza serviciul cu numele service. Linkul conecteaza utilizatorul la baza

distanta cu user/passemil/a379c.

Current user link. Este un link ce conecteaza utilizatorul la baza de date ca un utilizator

global. Un utilizator local se poate conecta la o baza distanta ca un utilizator global in

contextual utilizarii unei proceduri stocate fara a stoca parola utilizatorului in definirea

link-ului. Astfel ion poate avea acces la procedurile scrise de emil accesand contul

emil si schema din baza de date.

Database link permite accesul la obiectele unei baze de date distante de catre utilizatori ai unei

baze de date locale fara ca acestia sa fie utilizatori ai bazei indepartate. Definitia acestuia este

pastrata in scema locala si poate fi utilizat ca orice alt obiect din schema locala in instructiunile

SQL. In tehnologia Oracle “shared database link” este un link intre un proces server local si o

baza de date distanta. Atunci cand o baza de date locala este conectata la o baza distanta printr-

un database link baza de date poate rula in mod dedicate sau in shared server mode. Diferenta

dintre shared database link si un link standard consta in:

Utilizatori diferiti ce acceseaza acelasi obiect din schema printr-un database link pot

partaja conexiunea de retea;

Atunci cand un utilizator stabileste o conexiune cu un server distant de la un process

server specific, procesul poate reutiliza conexiunea deja stabilita cu respectivul server

chiar si in situatia in care conexiunea a fost deja stabilita intr-o alta sesiune.

Intr-un sistem de baze de date distribuite fiecare fragment al bazei de date trebuie sa se identifice

unuic prin numele sau global (global database name). In tehnologia Oracle numele global este

obtinut prin prefixarea numelui de domeniu al retelei cu numele bazei de date. Cele doua


37

componente sunt specificate prin parametrii de initializare DB_DOMAIN si respectiv DB_NAME

specificati la crearea bazei de date. Ca urmare, din punctul de vedere al localizarii bazei de date

se obtine arborele de domeniu conform domeniului retelei, care da numele unic al serverului ce

gazduieste baza de date. Numele este dat similar cu domeniile in Internet, de calea de la frunza

catre radacina arborelui, ca de exemplu pers.aii.pub.ro, daca baza de date pers este

gazduita de serverul aii.pub.ro. Putem avea baze de date ce partajaza acelasi nume ca de

exemplu pers.aii.pub.ro si pers.cs.pub.ro in situatia in care cate o baza cu

numelepers este gazduita de cele doua domenii aii si respectiv cs. Parametrii de initializare

DB_DOMAIN si DB_NAME sunt importanti numai la momentul crearii bazei de date si la acel

moment sunt stocati in dictionarul de date. Daca se doreste schimbarea numelui global al bazei

de date aceasta trebuie facuta prin instructiunea ALTER DATABASE nu prin modificarea

parametrului de initializare. Cu toate acestea Oracle recomanda schimbarea parametrului

DB_DOMAIN pentru a reflecta schimbarea numelui domeniului inainte de o noua pornire a bazei

de date.

Uzual, un database link are acelasi nume cu numele global al bazei de date distantepe care linkul

o refera. Daca numele global este pers.aii.pub.ro, atunci linkul este numit

pers.aii.pub.ro. Daca se seteaza parametrul de initializare GLOBAL_NAMES la TRUE

mediul Oracle asigura ca numele linkului este acelasi au numele global al bazei de date. Oracle

verifica partea domeniu a numelui global pastrat in dictionarul de date nu in fisierul cu

parametrii de initializare. Daca GLOBAL_NAMES este FALSE nu este necesar a se utiliza numele

global si linkul poate fi denumit dupa bunul plac. Cu toate acestea este recomandabil sa se

utilizeze numele global intrucat la alte operatii cum este cea de replicare este obligatorie

utilizarea numelui global.

Un database link poate fi creat ca fiind privat, public sau global, diferenta fiind data de

utilizatorii carora le este permis accesul prin intermediul linkului la baza de date idepartata.

Astfel, avem:

Link privat – este creat in schema specifica a bazei de date locale si numai proprietarul

sau programele din acea schema pot utiliza linkul pentru a accesa obiectele

corespunzatoare bazei de date distante. Exemple:

o CREATE DATABASE LINK product.aii.pub.ro – un link privat ce

utilizeaza numele global al bazei de date distanta product.

o CREATE DATABASE LINK leg1 CONNECT TO emil IDENTIFIED

BY a379c USING “serv1” – un link privat numit leg1 la o baza distanta

cu numele de serviciu serv1 care face conectarea baza de date indepartata cu

user/pass emil/a379c.

o CREATE DATABASE LINK leg2 CONNECT TO CURRENT_USER

USING “serv1” – un link privat numit leg2 la baza de date distanta cu

numele de serviciu serv1, care utilizeaza user/pass a utilizatorului curent pentru

conectarea la baza de date distanta.


38

Link public – creat de utilizator ca link public, ce poate fi utilizat de toti utilizatorii si

toate programele care il apeleaza pentru a accesa obiectele bazei de date distante.

Exemple:

o CREATE PUBLIC DATABASE LINK product.aii.pub.ro – un link

public la baza de date distanta product ce utilizeaza user/pass a utilizatorului

conectat. Daca emil cu parola a379c utilizeaza linkul intr-o cerere acesta

stabileste o conexiune la baza distanta cu user/pass emil/a379c.

o CREATE PUBLIC DATABASE LINK product.aii.pub.ro CONNECT

TO emil IDENTIFIED BY a379c – un link public fixat cu utilizator si

parola specificata in definitia sa, user/pass emil/a379c.

o CREATE PUBLIC DATABASE LINK p_leg CONNECT TO

CURRENT_USER USING “serv1” – un link public numit p_leg la baza

de date distanta cu numele de serviciu serv1, care utilizeaza user/pass a

utilizatorului curent pentru conectarea la baza de date distanta (utilizatorul curent

poate sa nu fie acelasi cu cel conectat, dar trebuie sa fie un utilizator global la

ambele baze de date.

Link global – creat de un utilizator public si toti utilizatorii sau programele ce utilizeaza

linkul pot accesa obiectele din baza de date corespondenta.

Alegerea tipului de database link este depinde de cerintele specifice ale aplicatiei ce utilizeaza

sistemul. Un link privat este mult mai securizat in comparatie cu un link public sau global

intrucat el poate fi utilizat numai de proprietar sau de subprogramele acestuia care se gasesc in

aceeasi schema. Atunci cand mai multi utilizatori necesita o cale de acces la o baza de date

distanta, exista alternativa de creare a unui singur database link public ce poate fi utilizat de catre

toti care acceseaza baza distanta. Pentru a simplifica administrarea centralizata a database link-

urilor de catre un singur administrator se recomanda crearea lor ca database link globale.

Pentru ca aplicatiile sa poata accesa datele si alte obiecte in sistemul distribuit este necesara

crearea database link-urilor necesare. Pentru a crea database link utilizatorul trebuie sa aiba

privilegiile corespunzatoare tipului de database link pe care il creaza. Aceste privilegii sunt:

CREATE DATABASE LINK – permite crearea numai de database link privat;

CREATE PUBLIC DATABASE LINK – permite crearea si de database link public;

CREATE SESSION – Crearea oricarui tip de database link.

Un database link defineste o comunicaie intre o baza de date si o alta distanta. Atunci cand o

aplicatie utilizeaza un database link pentru accesul la o baza de date distanta se stabileste o

sesiune cu baza de date distanta in beneficiul aplicatiei care formuleaza cererea. Tipul de

conexiune este stabilit in momentul in care se creaza database link-ul.In multe situatii se creaza o

multime de legaturi la diverse baze de date, legaturi ce sunt de acelasi tip si vizeaza accesul la

aceeasi baza de date.


39

4.3. Instructiuni SQL distribuite

O interogare distribuita necesita informatii de la doua sau mai multe noduri. Ca exemplu, vom

considera ca utilizatorul emil este conectat la baza de date Manag si formuleaza o cerere in

care acceseaza date din tabela locala dept, dar si date gazduite in tabela comenzi, tabela

stocata in baza distanta vanzari. Consideram ca in schema emil a fost creat un database link

catre baza de date distanta vanzari. Cererea doreste sa obtina comenzile lansate pe baza

cererilor clientilor pentru fiecare department, operatie ce implica join intre tabela locala si o

tabela distanta.

SELECT d.dnume, c.nume, c.cod, c.numar

FROM emil.dept d, [email protected] c

WHERE d.depnr=c.depnr

O operatie de actualizare distribuita, sau operatii de tip insert, delete au ca efect modificarea

datelor stocate la doua sau mai multe noduri. In particular, astfel de operatii sunt posibile in

Oracle prin intermediul subprogramelor PL/SQL cum sunt procedurile sau declansatorii ce

contin operatii de actualizare accesand date de la diverse noduri. De exemplu:

BEGIN

INSERT INTO emil.dept(dnume, depnr, dloc)

VALUES (“proiectare”, 10, „Bucuresti‟);

UPDATE [email protected]

SET depnr=10

WHERE depnr=11;

END;

COMMIT;

In acest caz instructiunile sunt transmise catre nodurile responsabile, iar prin modul de gestiune a

tranzactiilor operatia fie reuseste fie este revocata. Desigur ca o seccesiune de operatii pot fi

inglobate intr-o tranzactie ce refera date de la nodul local sau de la un singur nod distant, sau

simultan de la mai multe noduri. Tranzactiile locale sau remote nu ridica problem deosebite

intrucat sunt gestionate de SGBD-ul ce ruleaza pe respectivul nod. Una dintre chestiunile

delicate in baze de date distribuite SQL este cea de pastrare a consistentei bazei de date cu

respectarea proprietatilor ACID la executia tran zactiilor dostribuite, motiv pentru care a trebuit

gasit un mecanism prin care sa se garanteze ca fie sunt executate toate instructiunile cuprinse in

tranzactie, fie toate sunt revocate, indifferent de localizarea datelor. Pe de alta parte efectele unei

tranzactii trebuie sa fie invizibil pentru alte tranzactii indiferent de nodurile ce sunt implicate in

executia acesteia sau tipurile de operatii asupra datelor. Daca pentru bazele de date centralizate

mecanismele de gestionare a tranzactiilor includ blocarea inregistrarilor implicate la scriere, la

baze de date distribuite tranzactiile trebuiesc coordonate in retea astfel incat sa aiba aceleasi


40

caracteristici sisa mentina consistenta chiar in situatia in care apar defectari ale sistemelor de

comunicare sau ale nodurilor. In acest scop Oracle impune un mechanism numit si commit in

doua faze (two phase commit) prin care garanteaza ca toate serverele ce participa la o tranzactie

distribuita fie executa cu success toate operatiile, fie toate operatiile sunt revocate. Executia

operatiilor se realizeaza tinand cont de constrangerile definite pentru obiectele ce participa la

tranzactie, si daca una dintre constrangeri nu este respectata prin modificarile ce trebuie facute

intreaga tranzactie este revocata.

Am vazut ca numele global al unui obiect este compus din numele obiectului, numele bazei de

date si numele de domeniu. Daca intr-o component a unei tranzactii este invocat un nume global

Oracle va cauta in dictionar un database link cu un nume care se potriveste pentru partea baza de

date si domeniu cu numele global invocat. Astfel pentru cererea:

SELECT * FROM [email protected];

Oracle va cauta un database link cu numele vanzari.aii.pub.ro prin care sa obtina o cale

pentru accesul la baza de date distanta. Cautarea de face mai intai in link-urile private, apoi in

cele publice si daca este disponibil serviciulOracle Names Server se va cauta si in link-urile

globale. In situatia in care numele global nu este complet specificat, lipsind numele de domeniu,

Oracle va apenda valoarea de initializare a parametrului DB_DOMAIN pentru a incerca sa

construiasca numele complet dupa care incearca gasirea unui database link ce se potriveste cu

numele reconstruit. Daca operatia se incheie cu succes cererea va fi lansata in executie, altfel va

returna eroare intrucat instructiunea nu poate fi executata. Ori de cate ori un obiect este referit

doar prin schema.nume fara sa includa semnul @ Oracle considera ca obiectul referit este un

obiect local. Nu este obligatorie oprirea cautarii atunci cand se suprapune cu success numele

link-ului cu cel al obiectului invocat in cerere.

Mecanismul two phase commit asigura modificarea datelor ce sunt stocate la mai multe noduri,

adica modificarea datelor din mai multe baze de date. Mecanismul de gestiune este mult mai

complicat intrucat el trebuie sa asigure modificarea simultana a datelor in mai multe locatii si

daca exista cel putin o locatie la care modificarea nu se poate realiza, obligatoriu ea trebuie

revocata in totalitate. In principal mecanismul realizeaza tranzactia in doua faze: faza prepare si

faza commit propriuzis. Fazele mecanismului commit:

Faza prepare (prepare phase) – nodul initiator numit si coordonator global cere

nodurilor participante sa pregateasca si sa promita executia tranzactiei, iar daca nu poate

sa garanteaze executia tranzactiei sa declanseze revocarea.

Faza commit – daca toti perticipantii raspund coordonatorului ca promit executia

tranzactiei, adica ea este preparata, coordonatorul cere nodului care are rol de commit site

point sa incheie tranzactia pe nodul sau si dupaincheiere cere truturor celorlalte noduri sa

faca comiterea tranzactiei.

Cu toate ca documentatia Oracle mai specifica inca o faza, faza forget in opinia mea acest lucru

este superflu pentru ca orice operatie incheiata nu mai poate sa ramana in atentia sistemului.


41

Practic, dupa ce operatia s-a incheiat fie prin commit sau rollback ea trebuie considerata

incheiata.

Atunci cand o tranzactie este realizata intr-un sistem distribuit sistemul de management al

tranzactiilor distribuite defineste un arbore de sesiune al tuturor nodurilor participante la

tranzactie. Acest arbore are o structura ierarhizata prin care sunt descrise relatiile dintre acestea

in timpul sesiunii. Nodurile ce fac parte din arborele de sesiune in tranzactia distribuita joaca

diverse roluri in diversele etape ale executiei. Rolurile posibile sunt:

Client – un nod are acest rol daca cere informatii de la alte noduri;

Server – un nod care receptioneaza cereri de la alte noduri si ofera datele nodurilor care

au cerut. Intr-un arbore de sesiune un nod poate juca rol de client pentru un nod si in

acelasi timp rol de server pentru alt nod.

Coordonator local – un nod la care pentru completarea unei parti a tranzactiei distribuite

refera date de la alt nod. Un astfel de nod coordoneaza activitatea nodurilor subordonate

care comunica direct cu el, activitati ce constau in: receptia starii tranzactiilor de la acele

noduri, transmiterea cererilor catre aceste noduri, receptia cererilor de la aceste noduri si

transmiterea lor la alte noduri, transmiterea rezultatului interogarilor la noduri ce au

initiat interogarile.

Coordonator global –este nodul care initiaza tranzactia distribuita. Aplicatia de baze de

date ce genereaza tranzactia trebuie sa fie direct conectata la nodul ce joaca rol de

coordinator global si acesta devine nodul radacina in arborele de sesiune. In timpul

executiei tranzactiei coordonatorul global efectueaza urmatoarele operatii: trimite

instructiunile SQL distribuite sau executia de proceduri la distanta, instruieste toate

nodurile referite, altele decat commit point site sa prepare tranzactia, instruieste nodul

commit point site sa initieze commit global pentru toate nodurile care au trecut de faza

prepare cu success, instruieste toate nodurile sa initieze revocare globala pentru parti ale

tranzactiei la care raspunsul primit a fost abort.

Commit Point Site –este nodul care initiaza commit sau rollback asa cum a fost instruit

de coordonatorul global. O buna practica necesita ca administratorul bazei de date sa

desemneze nodul commit point site ca fiind acel nod ce gestioneaza date critice.

Finalizarea tranzactiei incepe de la acest nod. Administratorul specifica serverul ce

gazduieste datele critice prin setarea parametrului COMMIT_POINT_STRENGTH, astfel

ca nodul care gazduieste baza de date cu cea mai mare valoare a acestui parametru va fi

ales commit point site. Alegerea nodului cu rolul commit point site este facuta la

inceputul fazei prepare prin selectia,de catre coordonatorul global,a nodului cu cea mai

mare importanta dintre nodurile participante. Cu toate acestea, chiar daca parametrul

COMMIT_POINT_STRENGTH este cel mai mare pentru un nod ce participa la tranzactie

numai ca read-only, nu poate fi commit point site. In situatia in care exista mai multe

noduri cu aceeasi valoare a importantei va fi ales unul dintre ele si desemnarea nodului

commit point site nu este necesara daca o tranzactie este revocata intrucat nu se intra in

faza prepare in care nodul este ales. Functionalitatea commit point site este diferita fata


42

de cea a celorlalte noduri implicate in tranzactia distribuita. Acest nod nu va participa

niciodata la faza prepare si deci nu intra in starea prepare intrucat prin faptul ca el

gazduieste date critice si nu ramane cu resursele blocate in eventualitatea ca apare un

defect. In cazul unei defectari toate celelalte noduri raman in starea prepared pastrand

blocarile necesare pana cand tranzactia este rezolvata. La acest nod tranzactia se incheie

inainte de realizarea ei la alte noduri. Ca urmare raspunsul de la acest nod determina cand

tranzactia este considerate incheiata sau se declansaza revocarea. Toate celelalte noduri

urmeaza incheierea tranzactiei dupa commit point site si coordonatorul global asigura ca

toate nodurile vor complete tranzactia in acelasi mod cu commit site point.

Prin acest mechanism o tranzactie distribuita este considerata incheiata dupace toate nodurile in

afara de commit point site au ajuns in faza prepared si tranzactia a fost incheiata, adica sa

incheiat commit la commit point site. La nodul cu rol commit point site redo log este actualizat

in momentul in care tranzactia a fost incheiata local pe respectivul nod, iar tranzactia distribuita

este considerate incheiata, chiar daca alte noduri sunt in starea prepared si ea nu a fost incheiata

la aceste noduri. Pana in momentul la care s-a actualizat redo log la commit point site tranzactia

este considerata ca nefiind incheiata.

In prima faza de pregatire a tranzactiei, faza prepare, se cere tuturor nodurilor ce participa la

tranzactie, exceptand commit point site, sa pregateasca executia commit. La preparare nodurile

inregistreaza informatiile in redo log pentru a se asigura ca in orice situatie poate realiza fie

commit fie revocare si aloca resursele in acest scop prin blocarea tabelelor ce se modifica.

Nodurile carora li s-a cerut prepare vor raspunde coordonatorilor care au cerut pregatirea fazei

rezultatul prepararii. Functie de situatie sunt posibile urmatoarele raspunsuri:

Prepared – semnifica faptul ca nodul a reusit pregatirea tranzactiei cu succes, au fost

inregistrate schimbarile in online log si poate face fie commit fie rollback. Prin acest

mesaj nodul garanteaza coordonatorului, promitand acestuia ca este capabil fie sa

realizeze commit fie revocare;

Read-only – semnifica faptul ca nodul invitat sa prepare nu contine date ce vor fi

modificare prin executia tranzactiei si de fapt nodul nu participa la faza comit, el fiind

implicat dor in furnizarea de date catre alte noduri pentru ca acestea sa realizeze

actualizarea;

Abort – mesajul este transmis atunci cand nodul nu poate pregati cu succes tranzactiasica

urmare elibereaza resursele si revoca partea locala a tranzactiei. Actiunea se propaga la

alte noduri ce vor revoca tranzactia locala si similar, vor elibera resursele.

In principal pentru completarea fazei prepare fiecare nod in afara de commit point site executa

urmatoarele operatii: cere tuturor nodurilor copil din structura arborelui de sesiune sa se

pregateasca pentru commit, verifica daca tranzactia modifica date din baza gazduita de acel nod

sau nodurile subordonate pentru a determina daca este implicat in mod read-only, aloca resursele

necesare pentru finalizarea tranzactiei daca datele sunt actualizate, salveaza in redo log

inregistrarile corespunzatoare tranzactiei, blocheaza accesul la obiectele ce se modifica si


43

transmite raspunsul corespunzator nodului care a initiat tranzactia. Nodul ramane in starea

prepared pana cand receptioneaza COMMIT sau ROLLBACK de la coordonatorul global.

A doua faza a tranzactiei, numita si COMMIT se produce numai daca raspunsul tuturor nodurilor

cu exceptia commit point site la cererea prepare este prepared. In acest fel se asigura faptul ca

executia tranzactiei este pregatita la toti participantii. Actiunile intreprinse sunt: coordonatorul

global cere commit point site sa finalizeze tranzactia si daca acesta o poate realiza cu secces va

informa coordonatorul global ca tranzactia a fost materializata dupa care coordonatorul global si

cei locali transmit mesaje catre celelalte noduri pentru finalizare tranzactie, fiecare nod executa

portiunea locala a tranzactiei si inregistreaza in redo log local ca a efectuat operatia, dupa care

notifica coordonatorul global ca operatia a fost efectuata.

O cerinta importanta pentru o baza de date distribuita este cea de asigurare a consistentei globale

a bazei de date. Pentru aceasta fiecare tranzactie efectuata are asociat un identificator unic sistem

charge number (SCN) ce actioneaza ca un timestamp prin care se poate identifica versiunea bazei

de date. Nodurile cominica intre ele si in faza prepare se determina cel mai mare SCN al tuturor

nodurilor participante la tranzactie, iar tranzactia se comite cu cel mai mare SCN la commit point

site si apoi este transmis la toate nodurile in starea prepared cu decizia de a efectua commit local.

4.4. Modalitati de ascunderea locatiei

Exista o multitudine de modalitati pentru a ascunde localizarea fragmentelor bazei de date dupa

ce au fost configurate toate database link-urile ncesare, astfel incat utilizatorii sa opereze cu o

baza de date distribuita similar cu modul de operare cu o baza de date locala. Mecanismele de

ascundere se bazeaza pe o serie de facilitati oferite de bazelor de date.

O modalitate de ascundere a localizarii se bazeaza pe utilizarea de vederi locale in definirea

carora sunt invocate tabele ce se gasesc la alta locatie. De exemplu, pentru utilizatorii bazei de

date Manag ce au nevoie de inregistrarile din anul 2012 stocate in tabela Clientia bazei de

date distante Vanzari putem crea un view local la serverul Manag astfel:

CREATE OR REPLACE FORCE VIEW cl2012 AS

SELECT *

FROM [email protected]

WHERE year(date)=2012;

Din acest moment utilizatorii locali pot face apel la vederea localacl2012pentru a accesa datele

solicitate din tabela client, fara a cunoaste ca originea datelor este o baza indepartata, cu o

cerere simpla.

SELECT * FROM cl2012;

Desigur ca proprietarul obiectului local poate asigura la obiectul local numai acele drepturi ce ii

sunt atribuite ca utilizator distant, functie de tipul de database link.


44

O alat modalitatte de ascundere a localizarii se bazeaza pe utilizarea sinonimelor. Sinonimele

sunt utilizate si in baze de date centralizate pentru a ascunde identitatea obiectelor. Asocierea

unui sinonim la un obiect face ca obiectul sa poata fi referit fie prin numele sau fie prin sinonim

fara a fi nevoie de modificarea aplicatiilor ce utilizeaza obiectul. Poate fi creat sinonim pentru o

multime de obiecte de la tabele, vederi pana la procedure, acestea fiind pastrate in dictionarul

bazei de date in care au fost create. Astfel pentru un obiect dintr-o baza de date indepartata la

care a fost creat un database link ii putem defini un sinonim ce este vazut ca orice obiect local cu

instructiunea:

CREATE [PUBLIC] nume_sinomin

FOR [schema.]nume_obiect[@nume_database_link];

In care cuvantul optional PUBLICindica faptul ca sinonimul este disponibil si poate fi folosit de

toti utilizatorii. Omiterea lui inseamna ca sinonimul este privat, cade exemplu:

CREATE PUBLIC SYNONIM client FOR [email protected];

Un alt avantaj al sinonimelor este dat de faptul ca in momentul in care un obiect este mutat de la

un nod la altul schimbarea database link-ului nu necesita interventia in aplicatie, intrucat este

suficienta modificarea definitiei sinonimului pastrand numele vechi, dar asociind noul database

link.

In Oracle unitatile de program PL/SQL, numite si proceduriconstituie o alta modalitate de

asigurare a transparentei la localizare. De exemplu, scriem o procedura locala care sterge dintr-o

tabela distanta inregistrarile ce indeplinesc conditia de egalitate a unui camp cu parametru

transmis procedurii.

CREATE PEOCEDURE sterge_cl (num NUMBER) AS

BEGIN

DELETE FROM [email protected]

WHERE cl_id = num;

END;

Atunci cand o aplicatie locala apeleaza procedura este ascuns faptul ca stergerea se face intr-o

tabela distanta.


45

5. Replicarea in baze de date distribuite

Asa cum am discutat in paragrafele anterioare principalele cerinte ale sistemelor distribuite sunt

fiabilitatea si disponibilitatea. In conformitate cu acestea defectarea unuia dintre nodurile

sistemului nu va paraliza functionarea sistemului si nici nu va afecta disponibilitatea datelor care

au fost inmagazinate la nodul respectiv. De cele mai multe ori sunt pastrate mai multe copii ale

acelorasi date in mai multe locatii in scopul realizarii autonomiei locale cerute si a cresterii

disponibilitatii. Pentru a se asigura consistenta bazei de date este obligatorie replicarea

fragmentelor intre locatiiin scopul reflectarii modificarilor asupra acestora.Aducerea la zi a

datelor pastrate in mai multe copii ca fragmente distribuite poarta denumirea de replicare. In

termeni de specialitate acesta operatie este cunoscuta si sub denumirea de sincronizarea bazei de

date [Car09]. Replicarea a devenit posibila prin utilizarea tehnologiilor de comunicatie moderne

care permit transportul datelor in format electronic de la o locatie la alta. Chiar daca unele

aspecte sunt intuitive, din punct de vedere practic tehnologia replicarii este suficient de complexa

si trebuie tratata ca atare. Replicarea este un proces care consta in realizarea si distribuirea unor

copii a datelor, numite si replici in scopul asigurarii posibilitatii de procesare locala a acestora,

oferind astfel un nivel cat mai ridicat de autonomie pentru bazele de date locale. Un nivel ridicat

de autonomie si implicit de disponibilitate, implică o serie de concesii privind actualitatea

informatiei utilizate. In plus, replicarea duce la cresterea redundantei, care poate afecta

consistenta bazei de date. Daca vom numi nodul aere furnizeaza date ca sursa si nodurile care

primesc datele ca tinte, putem defini replicarea prin:

Replicarea esteo tehnologie care permite ca informatii ce provin de la una sau mai multe surse

sa poata fi distribuite catre una sau mai multe tinte, cu propagarea consistenta a modificarilor

intervenite la surse catre tintele corespunzatoare.

Este logic sa consideram ca procesul de replicare nu se refera la replicarea intreagii baze de date,

care ar incarca foarte mult sistemul de comunicatie, ci doar un set de date, element care

complica suplimentar procesul de replicare. Un alt termen des intalnit in tehnologia replicarii

este cel de sincronizare, ca fiind procesul prin care se asigura capturarea, propagarea şi

reproducerea la tinte a actualizarilor de la surse. Sincronizarea nu se refera exclusiv la date,

intrucat se refera la propagarea actualizarilor, motiv pentru care putem privi sincronizarea dintr-o

perspectiva procedurala. Privita din punct de vedere procedural prin sincronizare de la sursa nu

se transmit datele propriuzise ce se actualizeaza, ci se transmit operatiile ce trebuie executate la

replici pentru a avea ca efect actualizarea. In concluzie, replicarea nu se refera doar la

distribuirea datelor, ci si la distribuirea prelucrarilor. Legat de caracteristicile bazei de date,

modului in care este distribuita si implicit a modalitatilor de replicare se disting urmatoareale

categorii:

Baze de date centralizate cu prelucrare distribuita –materializate in sisteme cu prelucrare

distribuita incluzand o singura baza de date pastrata de un nod central si gestionata de un

singur SGBD.


46

Baze de date partitionate, fragmentate sau nereplicate - baze de date distribuite in care

fragmentele nu au copii si deci fara redundanta. Aici costul stocarii este redus, cel de

comunicatie moderat, dar nu ofera fiabilitate si disponibilitate acceptabila.

Baze de date integral replicate - baze de date in care fiecare locatie contine cate o copie

completa a intregii baze de date. Intrucat procesarile sunt locale, disponibilitatea,

securitatea si fiabilitatea sunt foarte ridicate. Dezavantajul consta in costul ridicat al

echipamentelor de stocare si volumul mare al datelor transmise pentru actualizare,

sincronizarea permanenta fiind greu de asigurat.

Baze de date replicate partial – este cazul bazelor de date la care numai anumite

fragmente sunt replicate altele nu. Modelul incearca sa imbine avantajele celorlalte

categorii prin care sa se asigure prelucrari locale, autonomie, securitate, fiabilitate si

disponibilitate sporita. In acest scop sunt copiate la mai multe locatii fragmentele cu

utilizare frecventa de dimensiuni mici si care sunt rar modificate.

Utilizarea replicilor duce la cresterea performantelor aplicatiilor de baze de date prin faptul ca

datele sunt plasate cat mai aproape de locul in care sunt necesare. Daca aplicatiile si datele sunt

cat mai apropiate performantele cresc, iar daca este nevoie sa deplasam ceva este mult mai ieftin

sa deplasam aplicatiile langa date nu datele catre aplicatii, volumul informatiei transportate fiind

mult mai mic la aplicatii decat la date. Sunt insa si situatii in care aplicatiile si datele nu pot fi

gazduite pe aceeasi masina si pentru functionalitatea globala datele trebuie sa fie pastrate pe mai

multe noduri, chiar daca complica pastrarea sincronizarii bazei de date si genereaza trafic

suplimentar in sistemul de comunicatii. Cateva situatii:

O retea de retail cu magazine in diverse locatii,are un sediu cental unde se pastreaza

centralizat nomenclatorul de produse si preturile acestora, nomenclator ce este

administrat numai la sediul central. Sunt posibile doua situatii, cea in care magazinele

trebuie sa aiba acces la serverul central ori de cate ori vinde un produs , necesitand acces

on line la serverul de la sediul central, sau pastrarea la fiecare magazin a unei copii a

nomenclatorului de produse. Prima varianta face dependenta functionarea magazinelor de

locatia centrala, pe cand cea de a doua poate sa opereze cu nomenclatoare neactualizate

care nu contin ultimele modificari ale preturilor facute la locatia centrala.

Societatile pentru distributia resurselor (gaze, apa, electricitate) pot incheia contracte cu

clientii sau actualizeaza consumul pe baza datelor obtinute de catre agentii din teritoriu

care le stocheaza intr-o baza de date autonoma instalata pe un echipament portabil. In

momentul in care ajung la sediu aceasta baza de date este utilizata pentru actualizarea

datelor in baza de date globala, dar si reactualizarea tarifelor conform cu politica

societatii.Acesta situatie mai poarta denumirea de consolidarea datelor.

Ambele cazuri ofera un nivel ridicat de autonomie pentru bazele de date locale prin procesul de

replicare. Cu toate acestea sunt necesare concesii in ceea ce priveste actualitatea informatiei,

cresterea redundantei si posibila aparitie a inconsistentei. In realitate este posibil ca sursele si

tintele sa fie multiple, replicarea fiind:


47

One-to-many – cazul in care datele aflate la o locatie centrala sunt replicate la mai multe

locatii tinta, adica o singura sursa si mai multe tinte. O astfel de replicare este cel mai

usor de gestionat intrucat modificarea datelor se efectueaza la o singura locatie;

Many-to-one – cazul in care datele din mai multe surse sunt replicate la o singura tinta.

Acesta este un caz fara aplicatii practice deoarece daca modificarile la mai multe locatii

se propaga la o singura tinta nu este asigurata consistenta bazei de date pentru ca sursele

nu sunt sincronizate in nici un fel;

Many-to-many – cazul in care exista mai multe surse de date si mai multe tinte la care

acestea sunt replicate. Cazul este real prin faptul ca o locatie poate avea rol de sursa si

respectiv rol de tinta la diverse momente de timp;

De cele mai multe ori replicarea nu inseamna transmiterea unei copii a intregii baze de date,

replicarea totala, ci doar replicarea unei tabele sau a subsetului de date dintr-o tabela, fapt ce

complica de cele mai multe ori procesul de replicare.O prima diferentiere a tehnicilor de

replicare este facuta dupa momentul de timp la care sincronizarea este realizata (aducerea la zi a

copiilor) numite replicare sincrona, respectiv replicare asincrona.

Replicarea sincrona presupune ca o actualizare a datelor la sursa trebuie propagata si

aplicata imediat (sincron) la toate replicile, incheierea tranzactiei la sursa fiind

conditionata de actualizarea replicilor. Pentru realizarea unei actualizari este utilizat, asa

cum a fost prezentat, un protocol numit si „comitere in doua faze”, prin care se

urmareste garantarea sincronizarii simultane a tuturor replicilor. Pentru replicarea

sincrona este nevoie de conectivitate permanenta on line intre nodurile retelei si la fiecare

destinatie tranzactia de actualizare trebuie sa poata fi incheiata. In acest caz costul

replicarii este destul de ridicat si se urmareste in principal pastrarea integritatii datelor

fara a se urmari disponibilitatea. O tranzactie distribuita pentru replicarea sincrona este

aplicabila si nu creaza probleme de gestiune dacanu afecteaza volume mari de date. Am

folosit termenul de tranzactie distribuita in loc de replicare sincrona, intrucat nu putem

face o separare neta intre ei. O tranzactie distribuita nu lucreaza, de regula, utilizand copii

ale datelor ci cu date care sunt distribuite la mai multe locatii. Am vazut ca o tranzactie

distribuita necesita date localizate pe diverse masini, din punctul de vedere al aplicatiei

localizarea datelor este transparenta. La replicarea sincrona, este posibil ca o tranzactie sa

incerce sa actualizeze date care reprezinta sursa unei replicari. Pentru propagarea

imediata a actualizarii, sistemul genereaza o tranzactie speciala, care independent de

tranzactia declansata trebuie sa actualizeze replicile. Incheierea cu succes a tranzactiei

este conditionata de incheierea cu succes a tranzactiei care face actualizarea datelor la

replici. Trebuie remarcat faptul ca tranzactia poate fi o tranzactie simpla, locala, pe cand

tranzactia care asigura replicarea este o tranzactie distribuita.

Replicarea asincronă se spune ca este bazata pe un mecanism de tip „store and forward”

sau altfel numit „message based replication”. Informatiile despre actualizarile produse la

sursa sunt pastrate intr-o coada de asteptare, de unde sunt transmise destinatiilor pentru a

sincroniza baza de date de la destinatie in care sa se reflecte modificarile facute la sursa.


48

Un astfel de proces produce intarzieri de sincronizare la tinta de la cateva secunde pana la

zile functie de configuratia sistemului. In aceasta situatie se accepta operarea cu date

nesincronizate pentru anumite intervale de timp si scaderea restrictiilor privind costurile

si disponibilitatea comunicatiilor intre noduri. Datorita costurilor ridicate si complexitatii

replicarii sincrone alternativa uzualasi mult mai practica este reprezentata de replicarea

asincrona. Sunt situatii in care replicarea sincrona nu se poate aplica din cauza

neindeplinirii conditiilor tehnice. De multe ori termenul de replicare este asimilat cu

replicarea asincrona.

In conjunctie cu procesul de replicare o serie de aspecte privind consistenta datelor din baze de

date trebuie analizate in conjunctie cu procesul de replicare. Cum in general, toate actualizarile

intr-o baza de date se executa ca urmare a tranzactiilor este necesar ca la replicare sa fie pastrate

proprietatilor cunoscute sub denumirea de ACID. Fiecare SGBD implementeaza aceste

proprietati prin mecanisme de blocare la scriere a inregistrarilor ce sunt afectate de tranzactii inca

neincheiate, mecanism ce a fost gandit cu functionare sincrona si ca urmare nu poate fi aplicat

replicarii asincrone. Ca urmare efectele unei tranzactii nu sunt totdeauna vizibile in una sau mai

multe replici, ceea ce face ca intre doua sincronizari consecutive datele pe ansamblu, inclusiv

replicile, sa fie inconsistente. Daca consideram scenariul cu existenta unui sediu central si mai

multe filiale in diverse alte locatii si modificarile in nomenclatorul de produse si preturi in

responsabilitatea sediului central, tranzactia care modifica pretul unui produs la sediul central ar

trebui sa fie considerata incheiata cand modificarea este facuta atat in tabela de la sediul central

cat si in toate replicile distribuite. La o replicare asincrona mai multe filiale continua sa utilizeze

nomenclatoarul vechi pana cand o sincronizare a bazei de date este realizata. O astfel de

inconsistenta nu este suficient de severa si se poate accepta operarea pentru un timp limitat cu o

baza nesincronizata. In aceastasituatie modificarile se transmit catre replici fara a se include

informatii despre tranzactiile care le-au produs, cunoscuta sub numele de replicare rand cu rand.

Pot fi implementate si solutii in care se combina replicarea asincrona cu cea sincrona. In acest

caz anumite operatii critice, pentru care compromisul este inacceptabil, pot fi fortate la o

replicare sincrona pentru altele fiind acceptabila replicarea asincrona. O alta varianta posibila

este cea de acceptare a tranzactiilor intarziate prin care replicarea tine seama atat de modificarile

la sursa cat si de tranzactiile care au produs respectivele modificari. In acest caz se transmit catre

destinatii numai modificarile produse de tranzactii comise la sursa in ordinea in care modificarile

s-au produs, impreuna cu marcile de timp. Mecanismul face o replicare a tranzactiilor,

producandu-se o serializare a actualizarilor. De exemplu, daca o tranzactie T1 actualizeaza pretul

unui produs din nomenclator la momentul t1 dupa care alta tranzactie T2 actualizeaza pretul

aceluiasi produs la momentul t2, modificarile sunt reflectate la destinatie in aceeasi ordine. Chiar

daca aceste actualizari sunt facute in ordinea specificata nu se garanteaza consistenta, un motiv

putand fi si constrangerile locale.

O replicare poate fi unidirectionala sau bidirectionala functie se sensul de propagare sau rolul de

sursa sau destinatie jucat de un anumit nod. Replicarea unidirectionala este cea in care replicile

sunt disponibile numai pentru citire. Se spune ca o astfel de replica este read-only pentru tinte ea


49

reprezentand un instantaneu la un anumit moment, numit in literatura de specialitate si snapshot.

Termenul snapshot a fost introdus de Oracle la bazele de date centralizate semnificand

inghetarea unui set de date. Putem face analogie intre snapshot si view, in sensul ca ambele sunt

rezultatul unei operatii de interogare, insa un snapshot pastreaza rezultatul interogarii nu

interogarea care produce rezultatul, asa cum se pastreaza un view. In baze centralizate un

snapshot este improspatat la anumite intervale de timp, scopul sau fiind de a permite interogari

complexe cu performante superioare pentru procesarile OLTP sau analiza OLAP. Acest

instrument a fost utilizat in prima faza la replicare in procesarea distribuita. Odata cu

introducerea tehnologiei de replicare bidirectionala Oracle pastreaza denumirea, dar putin

modificata de "updatable snapshot”. Sybase foloseste termenul de snapshot ca o replica read-

only non-tranzactionala. Replicarea bidirectionala in care rolurile de sursa si tinta sunt schimbate

mai poarta denumirea de replicare simetrica. Mai corect este termenul de replicare

multidirectionala, intrucat replicile sunt transmise catre mai multe destinatii.

Sunt posibile mai multe configuratii pentru replicare:

Configuratie master/slave. Actualizarea se face la master cu transmiterea replicilor la

tinte pentru a fi utilizate read-only. Ea poate fi tranzactionala sau la nivel de linie in

functie de volumul,frecventa modificarilor si frecventa sincronizarilor. Structura este

arborescenta un nod parinte jucand rol de sursa si fii sai roluri de tinte, relatia dintre

nivelul parinte si copil fiind de master/slave;

Configuratie master/slave cu mai multi proprietari. Cazul centralizarii datelor din mai

multe surse intr-o singura destinatie. Este cazul aplicatiilor de centralizare si consolidare

a datelor;

Configuratie retea sau peer-to-peer. Este cazul in care fiecare locatie poate face

actualizari ale datelor si modificarile sunt replicate la toate nodurile. Pentru acesta

configuratie Oracle utilizeaza termenul de multiple master. Asigurarea integritatii datelor

este mult mai dificila datorita actualizarilor ce sunt generatoare de conflicte, utilizand mai

multe tehnici de rezolvarea conflictelor sau chiar solutii manuale.

Propagarea replicilor poate fi facuta in mai multe moduri. De exemplu IBM propune o tehnica

care include un nod de referinta prin care configuratia se transforma din configuratie retea intr-o

configuratie de tip ierarhie, cu nodul radacina ca nod de referinta. In aceasta abordare

actualizatile efectuate de noduri sunt replicate catre nodul de referinta, si acesta le va replica

celorlalte noduri. Un astfel de scenariu nu elimina conflictele dar simplifica modalitatile de

detectare si rezolvare a lor. De cele mai multe ori avem de a face cu variante combinate sau

configuratii paralele pentru aceeasi aplicatie.

Sunt utilizate diverse terminologii la produsele existente pentru a descrie modul de configurare a

replicarii. Dintre tehnologiile simple remarcam solutia bazata pe conceptul publicare si abonare,

utilizata ca atare la Microsoft, dar nu numai. Baza de date (serverul) care va servi ca sursa pentru

replicare va fi numita "editor" (publisher), in cadrul baze de date se definesc asa-numite

"publicatii" (publications), care formeaza seturile de date disponibile pentru replicare. Alte baze


50

de date se pot "abona" (subscribe) la aceste publicatii. Pentru definirea procesului de replicare

este necesara specificarea editorului, a publicatiei si a abonatului, si o serie de informatii

aditionale cum ar fi: tipul replicarii (unidirectionala sau bidirectionala), intervalul de timp la

care se fac sincronizari, modalitatile de rezolvarea conflictelor etc. Un server poate fi editor al

unor publicatii si in acelasi timp abonat la publicatii editate de alte servere.

Cel mai uzual este cazul replicarii selective, cand publicatia nu este o intreaga tabela, ci doar

anumite subseturi ale acesteia. Acest lucru este benefic atat prin scaderea volumului de date

replicate cat si prin asigurarea unui nivel de securitate si confidentialitate adecvat. Indiferent de

modul de specificare a sursei, subsetul de date dorit este produs ca rezultat al unei interogari

SQL SELECT. Rezultatul interograrii cuprinde subsetul de date ce respecta anumite cerinte in

concordanta cu restrictiile ce sunt formulate in clauzele interogarii. Este foarte important ca

fiecare linie selectata sa corespunda unei linii a tabelei sursa si ca subsetul de coloane selectat sa

contina toate coloanele ce formeaza cheia primara a tabelei sursa. Cu aceste restrictii rezulta ca

pentru producerea subsetului nu se pot folosi functii de agregare sau distinct, nu se admit clauze

GROUP BY, operatii cu seturi (UNION, MINUS), cat si o serie de sucereri, similar cu

modificarile prin intermediul view-rilor. Astfel, pentru definirea publicatiei in Oracle se executa

o instructiune de creare snapshot:

CREATE SNAPSHOT nume_snapshot

AS SELECT......

cu respectarea restrictiilor prezentate mai sus. Oracle opereaza cu doua niveluri de complexitate

privind replicarea, nivel de baza pentru replicarea unidirectionala si nivelul avansat ce poate

opera ca replicare bidirectionala. Replicile pot fi impartite in replici simple si replici complexe.

In replicarea de baza ambele categorii pot fi utilizate, dar numai replicile simple pot fi

actualizabile. Spunem ca o replica este simpla daca se construieste avand la baza o singura tabela

si se supune tuturor restrictiilor specificate anterior. Daca o interogare nu contine clauza WHERE

actualizarile se propaga la toate liniile si numai la coloanele precizate in expresiile din clauza

SELECT. Daca in interogare este utilizata si clauza WHEREsunt selectate pentru replicare numai

acele linii care satisfac conditiile precizate in expresiile clauzei WHERE. De exemplu:

CREATE SNAPSHOT Replica AS

SELECT * FROM [email protected] prod

WHERE prod.Bucati> 100

afecteaza doar liniile pentru care valoarea campului bucati este mai mare decat 100. Tehnologia

de replicare Oracle permite si selectia liniilor pe baza parcurgerii referintelor de tip many-to-one

din tabele asociate. Un exemplu este crearea unei replici pentru consolidarea datelor intr-o

locatie centrala, date provenite de la o filiala din judetul „BV” care contin doar comenzile

aferente clientilor din acest judet:


51

CREATE SNAPSHOT Replica_comenzi AS

SELECT * FROM [email protected] a

WHERE EXISTS

(SELECT Cod

FROM [email protected] b

WHERE a.cod_client = b.cod_client

AND b.Judet = ‚BV‟);

Putem face analogia intre definirea unei replici si definirea unui view. Ca asemanare ambele

ofera informatiile actuale la momentul in care sunt executate, restrictiile privind actualizarea prin

view sunt aceleasi cu cel aferente actualizarii unei replici, chiar daca multe medii de baze de date

nu permit replicarea unui view. Alte tehnologii, ca de exemplu IBM permite prin instrumentele

de replicare si in configuratii speciale si replicarea unui view. Oracle face o deosebire intre

replici actualizabile (updatable snapshots) si replicarea simetrica intre servere, denumita si

„multimaster replication” in care nu este permisa replicarea selectiva. Mediile de baze de date

genereaza o serie de alte obiecte specifice ce sunt utilizate la replicare. Oracle genereaza automat

pentru fiecare snapshot un index bazat pe cheia primara si un view. La fiecare sursa de replicare

Oracle construieste un jurnal, numit si snapshot log, materializat intr-o tabela ce contine pentru

fiecare linie actualizata, cheia primara, marca de timp, eventual ROWID (identificatorul unic de

rand). Informix utilizeaza un catalog global al replicarii ce contine metadate despre surse,

participanti, definitii, optiuni, replicat la toate serverele implicate.

5.1 Capturarea actualizarilor

Foarte importante sunt mecanismele prin care procesele de replicare sesizeaza producerea unei

modificari la sursa. Practic, sunt utilizate doua mari categorii de capturare a modificarilor la

sursa: cele bazate pe triggere (declansatoare) si cele bazate pe jurnalul de log.

Capturarea actualizarilor prin triggere. Un trigger este similar cu o procedura stocata ce nu este

apelata explicit, ci este lansat in executie ca urmare a producerii unui evenimet. Evenimentele

care declansaza executia unui trigger sunt cele cu tentativa de actualizare de tip: INSERT,

DELETE sau UPDATE la tabela careia ii este este atasat triggerul sau chiar la coloanele unei

tabele. Un trigger este scris in limbajul propriu SGBD sau intr-un limbaj gazada, ca de exemplu

Java. Mai jos am ilustrat un trigger scris intr-un limbaj procedural similar cu Oracle si Postgres:

CREATE TRIGGER Prod_update

BEFORE UPDATE ON Produs

FOR EACH ROW

BEGIN

IF OLD.cod_prod != NEW.cod_prod THEN

DELETE FROM Produs


52

WHERE cod_prod = OLD.cod_prod;

INSERT INTO Produs VALUES

(NEW.cod_prod, NEW.denumire, NEW.pret);

END IF;

END;

Acest trigger este legat de tabela Produssi la orice actualizare a unui produs se sterge linia

modificata si se insereaza una noua ce contine noile date. Triggerul din exemplu este executat ca

urmare a unei actualizari realizata doar prin operatia UPDATE. In exemplu, triggerul este

declansat inainte de efectuarea operatiei de actualizare prin specificare clauzei BEFORE. Daca se

doreste lansarea dupa actualizare se specifica AFTER. Triggerul ilustrat verifica valorile

campului Cod_prod calificate de prefixarile OLD si NEW pentru valoarea veche si respectiv

valoarea noua. O modificarea in alta coloana nu este captata de trigger. Dezavantajul acestei

abordari este dat de executia triggerului in baza de date, proces consumator de resurse ce ducela

diminuarea performantelor. In al doilea rand, triggerele nu au acces la informatii despre

tranzactia in cursul careia se executa si permit doar replicarea la nivel de linie si in plus pot

interfera cu alte triggere.

Capturarea modificarilor din jurnal,este o alta alternatica. Aceasta metodaeste mult mai simpla

pentru capturarea modificatilor. La orice baza de date cu performante medii serverul jurnalizeaza

intr-un anumit mod tranzactiile, cu scopul de a putea reface o baza de date dupa un incident.

Jurnalizarea consta in pastrarea unui identificator al tranzactiei, a utilizatorului care a comis

tranzactia, care sunt actualizarile realizate, valorile intermediare (inainte si dupa fiecare

actualizare) si momentul comiterii. Din punct de vedere practic sunt pastrate mai multe

informatii pentru a putea fi utilizate la o eventuala anulare a tranzactiei (rollback). Ideea de baza

consta in integrarea mecanismului de capturare in mecanismul de jurnalizare si identificarea

tranzactiilor care trebuie replicate poate fi facuta dinamic. Intrucat o parte din sisteme

inregistreaza in jurnal un volum limitat de inregistrari facand suprainscrierea celor mai vechi este

necesar ca procesele de jurnalizare si capturare sa fie corelate astfel incat sa nu se piarda

tranzactii. Avantajul capturarii bazate pe jurnal consta in faptul ca pot fi identificate tranzactiile

si nu se produc interferente cu procesarile curente. Cum orice avantaj necesita platirea unui cost,

programul sau procesul ce realizeaza capturarea necesita procesari destul de complexe si multe

operatii de transfer de date. Acestea au ca efect cresterea incarcarii serverului si consumul de

largime de banda pentru retea.

Solutiile sunt promovate de catre producatori, in sensul ca daca un producator a optat pentru o

anumita tehnica scoate in evidenta avantajele solutiei alese, ca de exemplu Oracle care

promoveaza solutia trigger intr-o varianta optimizata. Triggerele utilizate pentru replicare sunt

standardizate si internalizate in sensul ca sunt compilate si incluse chiar in nucleul bazei de date

fapt ce asigura performante foarte bune. Alte medii, ca de exemplu Sybase implementeaza

replicarea printr-un software specializat procesului de replicare (Replication Server). O

componenta Log Transfer Manager, ruleaza la fiecare server ce constituie o sursa de date si


53

furnizeaza serverului de replicare actualizarile capturate in jurnal. Alte doua medii Informix si

IBM implementeaza pentru replicare tehnologii bazate pe jurnal. Indiferent de tehnologia

utilizata, evaluarea corecta a datelor pentru replicare determina performantele oricarui proces de

replicare.

5.2. Aplicarea actualizărilor

La receptionarea unui mesaj ce cuprinde actualizari la un server destinatie, modificarile trebuiesc

aplicate cat mai repede la baza de date. Chiar daca procesul nu ridica aparent probleme dosebite,

este totusi posibil ca regulile de integritate de la baza de date destinatie sa fie diferite de cele de

la baza de date sursa. Aceasta poate duce la situatia de respingere a unor actualizari deja

acceptate la baza de date sursa. Unele dintre situatii sunt tipice si au asignate anumite strategii:

La configuratiile de tip master/slave regulile de integritate din baza de date slave sunt in

general mai relaxate decat cele ale bazei de date master;

La configuratiile peer-to-peer regulile de integritate sunt echivalente pentru toate

locaţiile, asa ca se poate presupune ca sunt replicate doar actualizari pentru tranzactii deja

validate la sursa.

Chiar cu respectarea conditiilor de mai sus, caracterul asincron al replicarii poate conduce la

conflict si aceste situatii trebuie detectate si rezolvate. Nu trebuie confundata o anomalie

functionala cu un conflict in sensul ca se poate accepta ca pentru anumite perioade sa se lucreze

cu o baza nesincronizata, situatie acceptata de logica aplicatiei. Anomaliile nu pot fi detectate de

mecanismul de replicare, ele vor trebui tratate de aplicatiile dezvoltate. Conflictele sunt specifice

configuratiilor cu replici actualizabile si apar la momentul in care aplicarea actualizarilor in baza

de date replicata nu este posibila datorită actualizarilor contradictorii. Cateva exemple de

conflicte:

La replicarea unei operatii DELETE la destinatie nu se gaseste linia ce trebuie stearsa,

situatie numita si conflict de stergere. O posibila cauza este actualizarea liniei de catre o

alta operatie in intervalul de timp in care replicarea s-a propagat.

La o operatie UPDATE, la destinatie nu se regaseste linia ce trebuie actualizata, numita si

conflict de modificare. Cauza posibila este similara cu cea de la operatia de stergere.

La o operatie INSERT la destinatie se gaseste o linie cu aceeasi cheie primara, generand

conflict de unicitate. Poate aparea datorita faptului ca ca in timpul propagarii, o operatie

de inserare de la alta sursa a fost efectuata sau o operaţie de modificare a modificat cheia

primara a unei linii existente.

O serie de reguli prestabilite sunt utilizate pentru corectarea conflictelor, ca de exemplu: reguli

bazate pe marci de timp (timestamps), metodele bazate pe un sistem de prioritati acordate

locatiilor si/sau utilizatorilor sau construirea unor proceduri stocate ce sunt executate atunci cand

un conflict este detectat, metoda ce poate combina avantajele celorlalte. Modalitatile de rezolvare

automata a conflictelor sunt diferite de la un mediu de baze de date la altul. Astfel, Informix

utilizeaza marciler de timp (ultima actualizare invinge), proceduri stocate (logica procedurii


54

determina actualizarea care invinge) sau chiar ignorarea conflictului. Functionarea corecta a

regulilor bazate pe marci de timp este conditionata de sincronizarea ceasurilor si de gestionarea

diferentelor de fus orar. IBM promoveaza o tehnologie pentru prevenirea conflictelor in care

propune inlocuirea configuratiilor peer to peer cu cele ierarhizate cu introducerea unui nod de

referinta. Actualizarile sunt replicate spre nodul de referinta, nod ce constituie radacina arborelui

pentru replicare, de unde replicile sunt transmise catre celelalte noduri. Daca sunt detectate

conflicte acestea sunt rezolvate la nodul de referinta prin generarea a ceea ce se numesc

„tranzactii de compensare”. Daca doua treanzactii fac actualizari contradictorii, una dintre ele

este aleasa ca victima si va fi anulata la nivelul nodului de referinta care genereaza o noua

tranzactie numita si „tranzactie de compensare” pentru a pastra consistenta datelor. Practic, nici

una dintre tehnicile de rezolvare a conflictelor nu este infailibila, toate necesita interventia

manuale pentru pastrarea consistentei. De fapt acesta este pretul care trebuie platit avantajului pe

care replicarea asincrona il ofera, de underezulta ca nu totdeauna replicarea asincrona este

posibila.


55

6. Baze de date distribuite NoSQL

In acest capitol vom discuta despre o noua tehnologie in domeniul bazelor de date distribuite ce a

fost dezvoltata in ultimul deceniu. Termenul de baza de date NoSQL a fost introdus pentru prima

data in anul 1998 de catre Carlo Strozzi ca un atribut al bazei de date open source pe care acesta

a dezvoltat-o [Chr]. Mai tarziu Eric Evans justifica necesitatea unor noi alternative prin

urmatorul citat: ,, scopul cautarii unor mijloace alternative este dat de faptul că trebuie sa

rezolvi o problema pentru care bazele de date relaţionale nu sunt viabile" [Eva09]. Intr-un

articol aparut in Computerworld [Com09] se afirma ca NoSQL inlocuieste modelul relational

extrem de scump si lenes cu un nou model foarte eficient in manipularea volumelor mari de date.

Este interesanta si observatia referitoare la demararea Web 2.0 care renunta la bazele de date

traditionale si construieste propriul sistem de stocare a volumelor mari de date utilizand

tehnologii inspirate din Google Bigtable si Dynamo (Amazon) [Chr]. Unul dintre inginerii

Facebook afirma ca prin modelul NoSQL scrierea intr-o baza de date de 50 Gb este mai rapida

de 2500 ori fata de traditionalul MySQL.

Principalele motive pentru dezvoltare si utilizare baze de date NoSQL sumarizate conform [Chr]

sunt:

Evitarea complexitatii – spre deosebire de bazele relationale care includ facilitati pentru

asigurarea unei consistente stricta a datelor prin proprietatile ACID, se constata ca acestea nu

sunt necesare in unele aplicatii;

Necesitatea acceptarii unui trafic masiv - unele medii NoSQL permit mai multe operatii

decat bazele de date relationale. Ca exemplu Google poate procesa 20 de petabytes zilnic

stocati in baza sa NoSQL Bigtable, prelucrarece este facilitata de MapReduce;

Scalabilitate buna pe orizontala operand pe hardware obisnuit – Scalabilitatea pe

orizontalaeste asigurata de posibilitatea de a adauga sau elimina noduri in infrastructura de

prelucrare fara efort in comparatie cu modelul relational, ca de exemplu configurarea Oracle

RAC. Masinile ce constituie noduri ale infrastructurii de prelucrare sunt calculatoare

obisnuite (component de raft), avand costuri moderate;

Renuntarea la modelul Entitate-Relaţie - bazele de date NoSQL au fost dezvoltate pentru

stocarea unor structuri de date simple sau asemanatoare cu cele din limbajele de programare

orientate obiect nu cele ale modelului relational. Cele mai multe aplicatii opereaza cu

structure de date de complexitate scazuta ce nu necesita functiile complexe oferite de bazele

de date relationale;

Complexitatea si costul configurarii clusterelor de baze de date – intrucat au fost

proiectate pentru operarea in clustere cu calculatoare obisnuite (PC) pot fi expandate usor

fara costuri pentru fragmentarea bazei de date pentru a rula in clustere de mari dimensiuni

sau in grid;

Relaxarea fiabilităţii in favoarea cresterii performantei – in foarte multe situatii poate fi

scazuta fiabilitatea in scopul cresterii performatei. Cazurile tipice fiind cele in care nu este

necesara pastrarea persistenta a unei informatii, ea putand fi pastrata in memorie RAM sau


56

asigurarea proprietatilor ACID pentru aplicatii la care astfel de proprietati nu sunt necesare,

ca exemplu site-uri de socializare.

Un alt aspect important care justifica necesitatea prelucrarii distribuite a datelor dar si

scalabilitatea pe orizontala vine de la volumul tot mai mare al datelor ce trebuie procesate cu

principala constrangere data de timpul foarte scurt in care trebuie dat raspunsul in contextual in

care hardware-ul utilizat are performanta redusa la nivel de echipament, dar creste foarte mult

prin asocierea echipamentelor. Stim ca modelul de date relational este construit pentru date cu

structura rigida intre care exista relatii, model adecvat executiei interogarilor intr-un limbaj

destul de sofisticat. O mare parte dintre aplicatiile actuale si mai ales extinderea aplicatiilor web

nu necesita o structura rigida a datelor si nu au nevoie de interogari complexe. Asa cum am

discutat in capitolele anterioare, modelul relational a fost dezvoltat ca model de baza de date

centralizata si toate imbunatatirile care asigura functionarea in cluster au fost adaugate pe un

model construit pornind de la alte principii. Ca urmare, sincronizarea este implementata

ineficient, sunt necesare protocoale two-phase commit consumatoare de resurse. O serie de baze

de date oferite in cloud computing omit complet modelul relational, ca de exemplu SimpleDB de

la Amazon sau depozitele de date eventual consistente dezvoltate in Erlang. Din punctual de

vedere al cerintelor majore a depozitelor de date in cloud computing atentia este concentrata pe

un cat mai mic efort de administrare si o foarte buna scalabilitate, mai ales pe orizontala [Tec09].

Faptul ca modelul relational a fost dezvoltat pentru baze de date centralizate constituie o

problema majora in acceptiunea lui Lehnhardt si Lang [Chr] prin incercarea clusterelor de baze

de date de a fi transparente fata de aplicatie, adica aplicatia sa aiba impresia ca opereaza cu o

singura masina nu cu un cluster. Considerentele initiale legate de latimea de banda, omogenitatea

retelei, topologie, latenta, stabilitate nu sunt garantate in timp. Transparenta la localizare nu este

un obiectiv al bazelor de date NoSQL si multe companii au imbratisat trecerea de la modelul

relational la modele nerelationale. De domeniul bazelor de date NoSQL au fost atrase o serie de

companii in special cele care se ocupa de dezvoltare web sau afacerile lor presupun rularea unor

aplicatii web. Dintre acestea amintesc: Cassandra dezvoltata de Faceboock si utilizata ulterior de

Twitter, Voldemort dezvoltata si utilizata de LinkedIn, servicii cloud stocare Amazon cu

SimpleDB etc. Cele mai multe dezvoltari sunt inspirate din Bigtable de la Google (referite

obisnuit ca stocare de coloana) sau de Dynamo de la Amazon (stocare cheie:valoare) [Chr].

Nu trebuie insa considerat ca orice solutie NoSQL este adaptata pentru orice situatie. Din

punctual de vedere al mediului de afaceri exista un oarecare scepticism pentru utilizarea

produselor open source, categorie din care fac parte si bazele NoSQL intrucat produsele ne

licentiate nu au suport garantat. Este cunoscut faptul ca orice tehnologie noua provoaca initial

mare entuziasm si o tehnologie care satisface cerintele la un anumit moment nu trebuie inlocuita

cu una noua a carei stabilitate nu a fost demonstrata.

6.2. Scurtă clasificare a bazelor de date NoSQL

Exista la acest moment o varietate de baze de date NoSQL dezvoltate in mare parte de companii

web, baze de date ce urmaresc satisfacerea unor cerinte de scalabilitate, performanta si oferirea


57

de noi facilitati. Unele au fost inspirate din Dynamo sau Bigtable, altele au pornit de la baze de

date existente sau au venit cu idei noi. Este dificila o clasificare a acestora din cauza varietatii si

a metodelor de implementare.

Conform [Chr] Stepen Yen sugereaza o clasificare a bazelor de date NoSQL pe baza modelului

datelor in urmatoarele categorii:

Key-Value-Cache din care fac parte Memcached, Repcached, Coherence,Infinispan,

Extreme Scale, Jboss Cache, Velocity, Terracoqa;

Key-Value-Store cu membrii: Keyspace, Flare, Schema Free, RAMCloud;

Eventually-Consistent Key-Value-Store cu reprezentatii: Dynamo, Voldemort, Dynomite,

SubRecord, Mo8onDb, Dovetaildb;

Ordered-Key-Value-Store cu reprezentantii: Tokyo Tyrant, Lighcloud, NMDB, Luxio,

MemcacheDB, Actord;

Data-Structures Server in implementarea Redis;

Tuple Store in implementarile Gigaspaces, Coord, Apache River;

Object Database cu reprezentantii: ZopeDB, DB4O, Shoal;

Document store cu o multime de implementari in CouchDB, Mongo, Jackrabbit, XML

Databases, ThruDB, CloudKit, Perservere, Riak Basho, Scalaris;

Wide Columnar Store avand ca membrii Bigtable, Hbase, Cassandra, Hypertable, KAI,

OpenNeptune, Qbase, KDI.

O alta clasificare se gaseste in articolul “Database in the cloud” scris de Ken North si include

numai bazele de date NoSQL utilizazte la stocarea datelor in cloud computing [Chr]:

Distributed Hash Table, Key-Value Data Stores cu reprezentantii: memcached,

MemcacheDB, Project Voldermort, Scalaris, Tokyo Cabinet;

Entity-Attribute-Value Datastores cu membrii: Amazon SimpleDB, Google AppEngine

datastore, Microsoft SQL Data Services, Google Bigtable, Hadoop, HyperTable, HBase.

Amazon Platform Amazon Simple DB;

Document Stores, Column Storescu membrii Sybase IQ, Vertica Analytic Database,

Apache CouchDB.

Rick Cattel imparte bazele de date NoSQL in 3 categorii dupa modelul datelor in urmatoarele

categorii: Key-value Stores, Document Stores, Extensible Record Stores. Poate cea mai buna

clasificare este data de [Pop10] si [Sco10] tinand cont de criterii nefunctionale si de facilitatile

oferite: performanta, scalabilitate, flexibilitate, complexitate si functionalitate. Sinteza este

reprezentata in tabelul 6.1.

Tabelul 6.1

Performanta Scalabilitate Flexibilitate Complexitate Functionalitate

Stocare key-value mare mare mare nu variabila (nu)

Stocare coloane mare mare moderata mica minima

Stocare documente mare variabila

(mare)

mare mica Variabila

(mica)


58

Baze de date orientate

graf

variabila variabila mare mare Teoria

grafurilor

Baze de date

relationale

variabila variabila mica moderata algebra

relationala

Dupa cum s-a precizat in paragrafele anterioare si conform [Chr] cele mai importante aspecte pe

baza carora se diferentiaza bazele de date non SQL sunt scalabilitatea, modelul datelor si al

interogarilor, persiatenta. Astfel, Casandra, HBase, Riak, Scalaris ofera o buna scalabilitate prin

posibilitatea de adaugare de noi noduri, Casandra oferind si suport pentru multiple datacentere.

Din punctul de vedere al modelului datelor si al modelului de interogare se remarca HBase si

Cassandra cu modelul datelor columnfamily, MongoDB si CuochDB cu modelul datelor

document, Voldermort si Scalaris cu model cheie-valoare. Modelul columnfamily similar cu

implementarea de la BigTable permite ca randurile sa aiba numar diferit de coloane, pe cand

modelul cheie-valoare, cu toate ca este simplu de implementat, este ineficient la actualizarea

datelor associate unei valori a cheii. Din perspectiva modelelor de interogare se remarca

CouchDB care are integrat suport pentru interogare MapReduce, model care a fost implementat

si in ultimele versiuni ale HBase. Un alt aspect este dat de modul in care sunt stocate datele cu

Memtables si SSTables la Cassandra si HBase (operatii de scriere in buffere interne si scrierea

permanentape disc dupa terminarea tranzactiei), arbori B (B-trees) la MongoDB realizand un

support de indexare bazat pe blocuri.

Cea mai mare parte a companiilor specializate in aplicatii web au adoptat asa numita terorema

CAP introdusa de Eric Brewer [Gra09]. Acest acronim vine de la cele trei concepte introduse:

Consistency, Availability, Partition tolerance. Prin consistenta se intelege capabilitatea

sistemului de a fi intr-o stare consistenta dupa executia operatiilor de actualizare la o sursa de

date, operatii care sunt reflectate la toate celelalte copii. Disponibilitatea ridicata presupune

capabilitatea de operare chiar daca unele noduri sunt oprite ca urmare a unor defectiuni sau

pentru activitati de mentenanta. Toleranta la partitionare inseamna capacitatea de operare si

atunci cand reteaua este partitionata si un nod nu poate comunica cu altele (in alti termini

plecarea sau adaugarea unui nod nu afecteaza semnificativ functionalitatea).Se constata ca pentru

o parte insemnata a aplicatiilor, in special pentru aplicatiile web, consistenta nu este atat de

importanta, spre deosebire de disponibilitate si toleranta la partitionare. Brewer introduce

caracteristicile BASE compuse din: Basically Availabile, Soft-state, Eventual consistency.

Proprietatile BASE sunt sistematizate de catre Ippolito prin:

Basically availabile– oaplicatie ruleaza de regula tot timpul insemnand ca este de regula

disponibila;

Soft-state – nu este consistenta la toate momentele de timp;

Eventualy consistency – chiar daca nu este consistenta la toate momentele de timp ea

poate sa fie intr-o stare eventual consistenta cunoscuta.

Este utila specificarea diferentelor intre consistenta stricta (strict consistency) si consistenta

eventuala (eventual consistency). La consistenta stricta toate operatiile de citire trebuie sa aduca

datele de la ultima operatie de scriere finalizata, ceea ce presupune fie ca citirea se realizeaza de


59

la acelasi nod cu cel la care s-a facut modificarea, fie ca tranzactiile sunt executate ca tranzactii

distribuite avand ca efect materializarea lor daca au fost actualizate toate copiile. Este clar ca acet

lucru nu poate fi atins cu pastrarea disponibilitatii si suportand partitionarea. Consistenta

eventuala accepta ca la citire sa acceseze datele in masura in care actualizarea se materializeaza.

Cu toate acestea datele accesate reprezinta o stare stabila reprezentand datele de la versiunea

anterioara.

6.3. Nivelul de stocare

Acest nivel analizeaza modul in care memoria externa (discul) este accesata si care sunt

implicatiile asupra performantelor in functie de operatiile efectuate. Sunt posibile urmatoarele

strategii:

Stocare bazata pe inregistrare (rand). Este specifica modelulului relational in care

randurile tabelei sunt serializate. Liniile noi sunt adaugate la sfarsitul sirului. In acest

caz o inregistrarea este citita sau scrisa cu o singura operatie de acces la disc si permite

accesul rapid la fiecare coloana a inregistrarii. Daca insa se doreste accesul in setul

datelor aferent unei coloane operatia devine consumatoare de timp;

Stocare pe coloane. In acest caz coloanele tabelei sunt serializate permitand acces rapid

la datele dintr-o coloana, in schimb accesul la o intreaga inregistrare este mare

consumatoare de timp. Se recomanda la aplicatiile analitice pentru analiza statistica a

datelor unde accesul rapid la coloane este important;

Stocare pe coloane cu grupuri logice. Solutia este similara cu cea bazata pe coloane

facand in plus gruparea coloanelor ce sunt accesate frecvent. Coloanele ce fac parte din

acelasi grup spunem ca formeaza o familie (column family). Aceasta idee a fost

introdusa de Google in BigTable si utilizata apoi si in Hbase.

Arbori structurati. Metoda nu se refera la serializare ci la modul in care memoria interna

si discul sunt utilizate pentru cresterea performantelor. Blocuri de date sunt pastrate in

memorie in containere numite memtables si salveaza pe disc o istorie a operatiilor

commit pentru datele din memorie. Continutul zonei de memorie este scris pe disc la

anumite momente de timp in containere numite SSTables. Aceste containere sunt

compactate in timp si mutate in alta zona refectand operatiile facute de utilizatori.

In fig. 6.1 sunt ilustrate modurile de serializarea a continutului pentru stocarea pe rand (a),

stocarea pe coloane (b) si pentru stocarea pe coloane cu grupuri logice (c). Figura 6.2 ilustreaza

nivelul de stocare in memoria interna in containere memtable, dar si stocarea pe memoria externa

in componente SSTable. Acesta descrie modelul de stocare utilizat de Googlela baza de date

BigTable.


60

Ana 5 27 Ion 5

42 Mihai 4 22

Rand 1

Rand 3

Ana Ion

27

Mihai 5

5 4 42 22

Prima coloana

Coloana trei

Ana Ion

5

Mihai

225 27 42 4

Prima coloana =

Grup1

Grup2 (coloanele doi, trei)

a) Stocare pe rand b) Stocare pe coloana c) Stocare pe coloane cu

grupuri logice

Fig. 6.1 Ilustrare nivel stocare (inspirata din [Lip09])

Fig 6.2 Nivel stocare memtable si SSTable in BigTable (luata din [Ho09])

Bazele de date non SQL implementeaza un nivel de stocare optimizat pentru propriul model de

date, modelul interogarilor, structurile de indexare, caracteristicile mediului de stocare.

6.4. Baze de date orientate document

6.4.1. MongoDB

MongoDB este o implementare de baze de date nerelationale opensource, scris în C++ orientat

pe documente. Spre deosedire de conceptul de rand, cunoscut sub denumirea de inregistrare sau

linie a unei tabele a fost inlocuit in MongoDB cu un model mult mai flexibil numit document.

Baza de date este constituita din una sau mai multe colectii de documente ce sunt referite ca

grupuri de documente. Se remarca faptul ca o baza de date MongoDB nu are schema, campurile

nu sunt predefinite. MongoDB ofera o buna scalabilitate pe orizontala prin distribuirea pe mai


61

multe noduri. Unitatea stocata este un document, structura de date similara cu un document

XML, un dictionar Pyton sau un document JSON. Efortul programatorilor este concentrat pentru

programarea aplicatiilor, nu pe scalabilitate, care este naturala prin capacitatea MongoDB de a

distribui colectiile atunci cand se adauga un nou nod. Tipurile de date suportate pentru campurile

documentului sunt:

Tipuri scalare: Boolean, integer, double;

Tip sir de caractere: string, expresii regulate, cod;

Obiecte: similar cu JSON, numite BSON;

Object id este reprezentat pe 12 octeti care identifica unic documentele din colectie.

Acest tip este compus din componentele: marca de timp (timestamp), identificatorul

masinii asignate valorii object id, identificatorul procesului MongoDB, contor.

MongoDB nu are implementat un mechanism similar cheilor straine din baze de date relationale,

motiv pentru care referintele intre documente sunt rezolvate de cererile suplimentare din

aplicatiile client. Avantajul acestor referinte consta in faptul ca sunt interpretate automat de

multe limbaje de programare. MongoDB oferain plus o serie de instrumente: indexare cu

posibilitatea de a efectua interogari rapide, scripturi java stocate ce inlocuiesc procedurile

stocate, se pot utiliza functii JavaScriptstocate pe server, suport MapReduce si alte metode de

agregare. O serie de instrumente lipsesc, pretul platit pentru scalabilitate fata de bazele de date

relationale, nu se pot efectua operatii join sau tranzactii complexe pe mai multe inregistrari.

6.4.1.1. Operatii in MongoDB

MongoDB suporta o serie de operatii similar cu cele implementate in limbajele SQL din bazele

de date relationale. Operatii de interogare:

Operatia SELECT. Operatia de cautare a obiectelor ce satisfac criteriul de selectie,

criteriu ce poate fi vazut similar cu cel din clauza WHERE in limbajul SQL. Documentele

pentru care criteriul este satisfacut sunt returnate, iar daca nu se precizeaza nici un

criteriu de selectie vor fi returnate toate documentele. Conditia de selectie, similar cu cea

din clauza WHERE SQL poate fi o conditie compusa din mai multe conditii atomice legate

prin connective logice. Conectivele logice suportate intre conditiile atomice sunt: AND

(,), OR ($or), NOT ($not). In conditiile atomice sunt permisi operatorii: diferit ($ne),

operatori relationali:> ($gt), >= ($gte), < ($lt), =< ($lte), apartenenta ($in),

nonapartenenta ($nin), modulo ($mod), nonexists. Foarte multe detalii despre operatia

SELECT se gasesc in manualul MongoDB.

Operatia PROJECT. Este similara cu operatia PROJECT din algebra relationala

permitand specificarea in al doilea parametru al interogatii care sunt campurile dorite in

rezultat sau care sunt campurile excluse din rezultat. Un camp dorit are asignat la numele

sau valoarea 1, pe cand un camp ce se doreste exclus are asignat la numele sau valoarea

0. Rezulta astfel doua modalitati de specificare a campurilor pentru operatia PROJECT si

anume: specificarea numai a campurilor dorite sau specificarea celor care sunt excluse


62

fiind astfel incluse in rezultat restul campurilor. Campul _id asimilat ca cheie primara

este totdeauna inclus in rezultat si nu poate fi exclus in nici o situatie.

Operatii de procesare a rezultatului. Rezultatul interogarilor combinate SELECT,

PROJECT poate fi prelucrat in continuare prin alte operatii ce au ca efect: sortare

similar cu efectul clauzei ORDER BY(sort), restrangerea numarului seturilor de date ale

rezultatului prin utilizarea operatiilor limit sau ignorarea primelor n, obtinerea

numarului rezultatelor interogarii cu operatia count, agregarea rezultatelor cu functii

definite cu operatia group (similara cu GROUP BY), reducerea numarului de documente

care sunt evaluate etc.

O alta categorie de operatii asupra bazei de date sunt cele prin care se modifica continutul

acesteia. Din aceasta categorie fac parte:

Insert. MongoDB este un model de baza de date document, ca urmare operatia de

inserare se refera la documente. La operatia insert se precizeaza ca argument

documentul inserat si MongoDB adauga campul cheie primara _id. Un efect similar il

poate avea si operatia save daca in document nu se regaseste campul _id.

Update. La operatia update o serie de parametrii precizati ca argumente determina

efectul operatiei: criteriul de selectie stabileste documentul sau documentele ce vor fi

actualizate, un document cu care se face potrivirea, si doua argumente in care se specifica

efectul operatiei ca operatie insert sau update. Daca se doreste modificarea numai a

anumitor campuri se vor specifica asa numitii modifier operators. Pentru detalii

consultati manualul MongoDB.

Delete. Pentru stergerea unui document dintr-o colectie se precizeaza criteriul sau

conditia ce trebuie indeplinita de document similar cu ceea ce se precizeaza la operatia

find. Daca nu se precizeaza o conditie toate documentele din colectie sunt sterse, iar o

metoda buna pentru stergerea unui singur document din colectie este cea de specificare a

campului _id ca fiind mult mai eficienta decat stergerea document prin specificarea

criteriului.

Din punctul de vedere al controlului tranzactiilor in MongoDB, atomicitatea poate fi asigurata

doar pentru operatiile update si delete, la care se poate seta indicatorul $atomic. Conform

manualului [MCS10] nu sunt suportate tranzactii complexe sau blocari din mai multe motive:

Asigurarea performantelor in medii partajate si blocarile distribuite sunt consumatoare de

resurse si duc la viteze de executie foarte scazute;

Operatiile asupra bazei de date se doresc simple si predictibile;

Rezolvarea de probleme “in timp real” nu permite blocarea unor volume mari de date

pentru perioade considerabile de timp.

Similar cu bazele de date relationale MongoDB permite executia de cod local la nodurile bazei

de date. Pentru executia unei secvente de cod la un singur nod, codul se incapsuleaza intr-o

functie JavaScript (JS) care se paseaza bazei de date. De asemenea, pot fi executate operatii de

agregare din categoria count, group tot ca operatii asupra datelor de la un singur nod. Pentru


63

agregarea datelor de la mai multe noduri MongoDB beneficiaza de o implementare MapReduce

similara cu documentatia Google sau implementarea Hadoop de la Apache. Reamintesc faptul ca

MapReduce are doua faze numite map si respectiv reduce, operatii ce sunt distribuite pe nodurile

infrastructurii.

O colectie de documente poate fi indexata dupa campuri similar cu indexarea in baze relationale.

Informatiile extrase despre campurile dupa care se face indexarea sunt organizate in arbori B si

utilizate la executia interogarilor in scopul cresterii performantelor. Cu toate acestea, asa cum si

in mediile relationale indexarea este recomandata numai in anumite situatii, MongoDB

recomanda indexarea colectiilor de obiecte in care numarul operatiilor de citire este mult mai

mare decat numarul operatiilor de scriere. In situatia in care numarul operatiilor de scriere este

mare, indexarea duce la scaderea performantelor. Similar cu Oracle, care creaza automat un

index dupa cheia primara si MongoDB creaza implicit un index dupa campul identificator unic

_id.

6.4.1.2. Aspecte privind distribuirea

MongoDB are o arhitectura ce permite concurenta la aceeasi resursa cu blocari atomice.

Principiul de baza implementat este de a permite oricate operatii de citire concurente, dar numai

o singura operatie de scriere la un moment de timp dat. Pentru toleranta la defectarea unui nod al

clusterului mai multe copii sunt pastrate de mai multe noduri, iar pentru aducerea la zi foloseste

un protocol de replicare asincrona. Ca urmare, la un moment dat numai un nod al bazei de date

este implicat in operatie de scriere, numit si nod primar, iar operatiile de citire sunt adresate

oricarui nod care detine o copie daca consistenta eventuala este suficienta sau nodului implicat in

operatia de scriere daca este nevoie de o consistenta putenica. O astfel de replicare se incadreaza

in filozofia de replicare master slave. La defectarea unui nod slave scrierea datelor primite de la

master nu mai este posibila, iar la repornire dupa un interval nu prea mare datele vor fi

actualizate. MongoDB ofera si alternativa ca la pornirea oricarui slave sa porneasca replicarea

pentru sincronizare.Procesul de replicare se configureaza prin precizarea numarului de noduri ce

pastreaza copiile si se initiaza replicarea prin conectarea la unul din procesele de pornire si

pasarea configuratiei. Pentru a accelera sincronizarea, nodurile adaugate la un anumit moment in

lista trebuie sa aiba fie un dictionar gol, fie o copie recenta a dictionarului de la alt nod. Intr-un

set de replicare pot fi implicate pana la sapte servere care au rol de servere de stocare (pot deveni

primare), servere passive (tot pentru stocare dar nu pot devein primare) sau servere de arbitrare

(nu sunt utilizate la stocare, dar participa la alegerea serverului primar). Pentru asigurarea

consistentei si durabilitatii sunt luate urmatoarele masuri:

Operatiile de scriere sunt incheiate cu success numai daca au fost replicate la majoritatea

nodurilor de date;

In perioada in care operatiile de scriere sunt propagate la nodurile replica,acestea sunt

disponibile la nodul master si pot fi accesate de la acesta;

In cazul defectarii nodului primar toate datele nereplicate la alte noduri sunt sterse;


64

In timpul perioadei de defectare in care nodul primar este declarant defect si un alt nod

este ales ca nod primar scrierea si consistenta puternica nu este posibila, cu toate ca

operatia de citire eventual consistenta este asigurata;

Pentru detectarea partitionarii retelei fiecare nod monitarizeaza starea celorlalte prin

heartbeats. Daca nodul primar nu receptioneaza mesaje de la cel putin jumatate dintre

noduri nu mai poate gestiona operatiile de scriere si paraseste starea de nod primar;

Noul nod ales ca nod primar are de rezolvat o serie de sarcini pentru a pastra consistenta

bazei de date.

Arhitectura distribuita pentru MongoDB se bazeaza pe trei componente:

Servere care executa procese mongo si stocheaza date, grupate dupa modul de replicare,

colectie numita si shard;

Servere de configurare ce pastreaza metadate despre fiecare shard si datele pastrate de el;

Servicii de rutare pentru distribuirea cererilor clientilor si returnarea rezultatelor catre

acestia.

O astfel de arhitectura este toleranta la defectare cu efecte minime functie de tipul defectului.

Astfel, defectarea unui serviciu de rutare are efect minimal prin faptul ca cererea clientului este

redirectata la un alt process de rutare, defectarea unui nod dintr-un shard nu va afecta

disponibilitatea prin faptul ca si alte noduri au replicile datelor, defectarea serviciului de

configurare nu afecteaza operatiile de citire sau scriere a datelor dar face imposibila impartirea si

redistribuirea colectiilor de date. Defectarea integrala a unui shard face indisponibile operatiile

de citire sau scriere in acel shard fara sa afecteze insa alte colectii. Din punctual de vedere al

securitatii MongoDB ofera doar instrumente de baza pentru administrarea accesului la date fara

sa ofere o securitate ridicata.

6.5. Baze de date orientate coloana

Bazele de date la care stocarea este orientata pe coloane este adecvata proceselor de prelucrare

analitica si business intelligence. Principala sursa de inspiratie pentru stocarea datelor orientate

pe coloana este Bigtable de la Google solutie ce a facilitat aparitia mai multor produse open

source cum sunt HBase, Hypertable, Cassandra, Dynamo. Modelul datelor folosit in Bigtable

este o rafinare a modelului cheie-valoare in care valorile sunt stocate ca vectori de baiti ce sunt

adresate prin tripletele (row-key, column-key, timestamp)(fig. 6.3).Se spune despre Bigtable ca

furnizeaza si proceseaza o structura de date “distribuita, map persistent multidimensional

sortat”. Asa cum se vede si in figura un map contine un numar neprecizat de randuri, un numar

nefixat de coloane, iar valorile au un timestamp asociat. Pentru adresarea unei valori se va folosi

o tripleta (cheia rand (numele de domeniu), nume coloana, timestamp).


65

Fig. 6.3 Exemplu de stocare in Bigtable (luata din [Cdg06], p.2)

Bigtable suporta pentru cheia de rand un sir de caractere demaxim 64K, randurile sunt ordonate

dupa cheia de rand si sunt grupate in colectii numite tablets care fomeaza unitatile de distributie.

Distanta intre doua randuri este mica (ele pot fi stocate in acelasi tablet) daca cheile de rand

ordonate alfabetic sunt apropiate. In filozofia Google alegerea cheii de rand ca adresa de

domeniu scrisa invers face ca subdomeniile unui domeniu sa aiba o distanta foarte mica fata de

domeniu . Coloanele sunt grupate dupa prefix in seturi numite si column families. Ca exemplu, in

fig. 6.3 avem doua column families: contents si anchor si la randul sau anchoreste

formata din doua coloane. Valorile in celule sunt ordonate descrescator dupa timestamp astfel

incat valoarea curenta este cea cu cel mai mare timestamp, adica valoarea cea mai

recenta.Bigtable permite operatiile: read cu selectarea randurilor dupa cheie si limitarea

familiilor de coloane, operatii de scriere la nivel de rand cu efect inserare, actualizare sau

stergere, operatii de scriere in tabele si familii de coloane incluzand stergerea sau crearea de noi

coloane, operatii MapReduce si o serie de operatii administrative. Se remarca faptul ca

tranzactiile sunt atomice la nivel de rand indiferent de numarul de coloane

implicate.Functionalitatile Bigtable sunt dependente de o serie de tehnologii si servivii Google,

cum sunt: distributed Google File System (GFS) ppentru persistenta, format fisier Google

SSTable, sistemul de management cluster etc. Orice implementare Bigtable implica mai multe

tablets servers responsabile pentru un numar de tablete, o librarie client care furnizeaza

aplicatiile capabile sa interactioneze cu Bigtable, un master server pentru gestiunea intregii

infrastructuri din punct de vedere software. In Bigtable tabelele sunt impartite dinamic in tablete

si acestea sunt distribuite dinamic la servere ce pot ramane sau pleca din configuratia clusterului.

Localizarea tabletelor este pastrata in tabela numita metadata care este tinuta in memorie si este

partitionata in root tablet, ca prim tablet si un numar arbitrar de alte tableturi metadata ce contin

informatii despre localizarea tabletelor utilizator. Ierarhia referitoate la locatiile tablet este data in

fig. 6.4.

Toate operatiile de scriere in tablete comise sunt pastrate in commit log si sunt persistente in

GFS. Actualizarile recente sunt pastrate intr-un buffer RAM numit si memtable. Principiul de

baza aplicat atunci cand un memtable atinge marimea specificata este de a stoca respectivul

memtable in format SSTable scris in GFS si se creaza un nou memtable in memoria RAM, lucru

ilustrat si in fig. 6.2.


66

Fig. 6.4. Ierarhia localizatii tablet in Bigtable (conform [CDG06, p. 4])

6.5.1. HBase

Hbase este o dezvoltare similara Bigtable realizata in Java fiind o parte a proiectului Apache

MapReduce Hadoop. El utilizeaza distributed file system (HDFS) care indeplineste un rol similar

cu GFS pentru Bigtable. HBase expune o interfata nativa scrisa in Java si o utilizare cunoscuta

pentru HBase este sistemul de mesaje din Facebook ce utilizeza HBase. Proiectul este lansat de

Apache, dar la dezvoltare au contribuit specialisti din intreaga lume si un mare numar de

companii printre care Yahoo, IBM, Google. Principal realizator al proiectului este Doug Cutting

actulmente angajat la Yahoo. Implementarea este bazata pe Hadoop Distributed File System

(HDFS), un sistem de fisiere distribuit destinat operarii pe structuri hardware obisnuite si asigura

toleranta la defectare si implementarea pe hardware cu costuri scazute. Ideea HDFS este de a

asigura acces rapid al aplicatiilor la date in contextul aplicatiilor ce manipuleaza un volum mare

de date [Lea]. Toleranta la defectare se materializeaza prin:

Implicatiile defectelor hardware. O instanta HDFS este constituita din sute sau mii de

masini, fiecare pastrand parti din fisiere de date. Detectarea oricarei defectarii si

rapiditatea refacerii automate este un obiectiv central pentru HDFS;

Aplicatiile proceseaza fluxuri de date pentru care trebuie asigurata latenta mica si viteza

mare de acces;

Seturi mari de date. HDFS este destiinat pentru stocarea si procesareaseturilor mari de

date, poate vehicula fisiere avand ordin de marime de gigabaiti, terabaiti. Accepta

milioane de fisiere intr-o singura instanta cu o multime scalabila de noduri in acelasi

cluster;

Ofera un model de coerenta simplu. Pentru a simplifica coerenta datelor si a creste viteza

de acces modelul implementat este “write-once-read-many”.

Aplicarea principiuliui “mutarea aplicatiilor este mai ieftina decat mutarea

datelor”.Implementarea porneste de la principiul conform caruia o prelucrare este

eficienta daca este executata cat mai aproape de locul unde datele sunt stocate pentru a

minimiza congestia aferenta comunicatiei.


67

Ofera portabilitata pe platforme eterogene. HDFS este construit pentru a oferi

portabilitate extrem de facila de la o platforma la alta.

Fig. 6.5. Noduri Hbase

Din punct de vedere arhitectural HDFS implementeaza o structura de tip master/slave.

Arhitectura include un singur NameNode materializat printr-un server care gestioneaza spatiul de

nume fisiere si accesul clientilor la fisiere si un numar de DataNode, uzual unul pe fiecare nod

component al clusterului, care gestioneaza spatiul de stocare atasat nodului pe care ruleaza

(fig.6.5).Un fisier este impartit in unul sau mai multe blocuri ce sunt stocate intr-un set de

DataNode. NodeName executa operatii cu sistemul de fisiere ca deschidere, inchidere,

redenumire fisiere si directoare, maparea blocurilor la DataNode. DataNode sunt responsabile de

servirea cererilor de citire si scriere de la sistemul de fisiere al clientilor si realizeaza de

asemenea crearea blocurilor, stergerea si replicarea dupa instructiunile primite de la NameNode.

Din punct de vedere materializare DataNode si NameNode sunt componente software in sisteme

de operare Linux in care HDFS suporta organizarea traditionala ierarhica a fisierelor similar cu

sistemele de operare. NameNode gestioneaza file system namespace si orice schimbare la file

system namespace sau a proprietatilor este inregistrata de NameNode si in acelasi timp pastreaza

numarul replicilor unui fisier. Din punctul de vedere al replicarii datelor,fiecare fisier este stocat

ca o secventa de blocuri, in care toate blocurile cu exceptia ultimului bloc au aceeasi marime.

Marimea blocurilor si factorul de replicare sunt configurabile pe fisier si pot fi specificate la

creare sau pot fi modificate. Deciziile de replicarea blocurilor sunt luate de NameNode care

primeste periodic de la fiecare DataNode din cluster informatii de tip Heartbeat si un raport de

blocuri. Pentru fiecare fisier se pastreaza o informatie ce contine urematoarele componente:

NameNode (Nume_fisier, Numar_replici, Id_blocuri, ...). In emplele urmatoare:

NameNode

Metadata (nume, replici…):

Cale, 3,…….

Client

Metadata ops

Noduri Date Noduri Date

Replicare

Citire

Block ops

Client

ScriereRack 1 Rack 2


68

/cale/part-0,r:2,{1,3},...

/cale/part-0,r:3,{2,4,5},...

este precizata calea, numele fisierului, numarul de replici al blocurilor. Astfel, part-0 are 2 replici

pentru blocurile 1 si 3 si 3 replici pentru blocurile 2,4,5. Din punctul de vedere al localizarii

instantele HDFS se intind peste mai multe rack-uri, tinand cont de considerentelegate de

largimea de banda care este mai mare in interorul unui rack, dar plasarea copiilor pe un singur

rack poate duce la pierderea datelor la defectarea sa, insa plasarea replicilor pe mai multe rack-

uri creste costul comunicatiei. Ca urmare o politica corecta arata case recomanda pastrarea a

doua replici la masini din acelasi rack si cel putin o replica la un nod situat pe alt rack. Aceasta

politica limiteaza traficul de scriere intre rackuri si sansa de defectare a intregului rack este mult

mai mica fata de sansa de defectare a unui nod. Din punctul de vedere al latentei pentru

minimizarea sa la citire, HDFS incearca sa faca citirea datelor de la replica cea mai apropiata,

astfel ca daca exista o replica gazduita de acelasi rack aceasta va fi preferata. NameNode

utilizeaza un log al tranzactiilor pentru pastrarea persistenta a inregistrarilor la fiecare schimbare

in metadate (EditLog), in sistemul local. Intregul file system mamespace, incluzand si maparea

blocurilor la fisiere si proprietatile fisierelor se pastreaza in FsImage ca fisier local. O imagine a

intreg file system namespace si block map este tinuta in memorie, formatul este compact si in

4GB RAM se poate tine un numar mare de fisiere si directoare. La boot se citeste FsImage si

EditLog, aplica toate tranzactiile din EditLog si creaza o noua versiune pentru FsImage.

DataNode pastreaza datele HDFS ca fisiere in sistemul de fisiere local si nu are cunostinte despre

fisierele HDFS. Fiecare bloc de date HDFS este pastrat in fisiere distincte in sistemul de fisiere

local. Distributia fisierelor in directoare este importanta doar pentru optimizarea locala. O

cererea clientului de creare a unui fisier nu necesita utilizare imediata a NameNode. Initial

clientul HDFS pastreaza datele intr-un fisier temporar local.Operatiile de scriere sunt transparent

redirectate la acest fisier local temporar. Cand nu mai incap intr-un bloc se contacteaza

NameNode care insereaza fisierul in ierarhia sistemului si aloca blocuri de date pentru el,

raspunde cererii clientului cu identitatea DataNode si clientul va trimite datele la nodul de date

specificat. La inchiderea unui fisier, datele netransportate inca din fisierul temporar local sunt

transferate la nodul de date destinatie, clientul anunta NameNode ca fisierul este inchis, moment

la care NameNode dicteaza crearea fisierului. La momentul la care un nod incepe sa receptioneze

date, acesta incepe sa stocheze o mica portiune pe care o scrie pe disc si o transmite urmatorului

nod la care replica se pastreaza, facand transmiterea datelor intre noduri ca intr-un registru de

deplasare.

Modelul Hbase este mult mai atractiv si mai riguros decat modelul SQL impunand oredondanta

mult mai mica. In general se spune ca companiile mari utilizand SQL mizeaza pe puterea

hardware incercand in acest mod sa ofere performantele dorite (exemplu, cumpararea Sun de

catre Oracle).Apache cu Hbase urmareste sa furnizeze stocare similara cu BigTable pentru

mediul de calcul distribuit Hadoop in care datele sunt organizate in tabele, randuri si coloane,

fiecare coloana particulara poate avea multiple versiuni pentru aceeasi cheie de rand utilizand un

model similar cu BigTable. Aplicatiile pastreaza randurile de date in tabele etichetate, randurile


69

au cheie de sortare si un numar arbitrar de coloane. Tabelele sunt stocate non dens asa ca

randurile aceleiasi tabele pot avea un numar variabil de coloane. Un nume de coloana este de

forma"<family>:<label>" unde <family> si <label> poate fi materializat prin orice sir arbitrar

de baiti. Hbase stocheaza “column families” grupate fizic pe disc, asa ca elementele dintr-o

anumita coloana au acelesi caracteristici de citire/scriere. La actualizari, numai un singur rand

poate fi blocat implicit la un moment dat de timp. Din punt de vedere arhitectural HBase are trei

componente majore:

HbaseMaster, analog cu Bigtable master server;

HregionServer, analog cu Bigtable tablet server;

Hbase client.

HBaseMaster este responsabil de asignarea regiunilor pentru HRegionServers. Prima regiune ce

va fi asignata este ROOT region care localizeaza toate META regiunile ce vor fi asignate.

Fiecare META region mapeaza un numar de regiuni utilizator care cuprind tabele multiple pe

care o instanta particulara Hbase le serveste. De indata ce toate META regions au fost asignate

masterul va asigna regiunile utilizator la HRegionServers, balansand numarul de regiuni servite

de fiecare.

HRegionServer. Pastreaza un pointer la HRegionServer care gazuieste ROOT region.

HBaseMaster monitorizeaza activitatea fiecarui HregionServer.HbaseMaster este responsabil de

manipularea functiilor administrative cum sunt cele de schimbare schema, adaugare si

eliminarecolumn families, activare-dezactivare copii de tabele.Spre deosebire de Bigtable cand

HBaseMaster se defecteaza, clusterul va fi oprit, la Bigtable, un Tabletserver poate inca servi

Tablets si dupa ce conexiunea cu masterul a fost intrerupta. Hbase areun singur punct central

pentru acces la toate HregionServers, adica HBaseMaster sica urmare acesta constituie un singur

punct de defectare. O solutie pentru asigurarea disponibilitatii poate fi o conexiune Heartbeat cu

o alta masina capabila sa asigure functia de HBase Master pentru a detecat defectarea HBase

Master si a prelua sarcinile acestuia.

META Table. META table pastreaza informatia despre fiecare regiune utilizator in Hbase, care

include un obiect HRegionInfo continand informatii ca cheia de start, cheia de stop, cand

regiunea este on-line sau off-line, adresa HRegionServer care serveste regiunea. META table

creste pe masura ce numarul regiunilor utilizator creste.

ROOT Table. ROOT table este limitat la o singura regiune si mapeaza toate regiunile in META

table. Similar cu META table, el contine un obiect HRegionInfo pentru fiecare META region si

locatia HRegionServer care serveste acel META region. Un rand in ROOT si META table are

dimensiunea de aproximativ 1KB. Implicit marimea unei regiuni este de 256 MB, asa ca ROOT

region poate mapa 2.6 x 105 META regiuni, care mapeaza in total 6.9 x 10

10 regiuni utilizator,

adica aproximativ 1.8 x 1019

(264

) baiti de date. HRegionServer este responsabil de gestionarea

cererilor de citire si scriere. El comunica cu HBaseMaster pentru a da o lista a regiunilor servite

si pentru a spune masterului ca este functional. Cererile pentru baza de date au urmatoarea

semnificatie:


70

Cereri de scriere.Cand o cerere de scriere este receptionata, mai intai este inscrisa in

jurnalul log numit si HbaseLog. Toate cererile de scriere pentru fiecare regiune sunt

servite si scrise in acelasi log. De indata ce cererea a fost scrisa in Hlog ea este stocata in

memoria cache numita Memcache. Exista cate un Memcache for fiecare HStore.

Cereri de citire.La citire este verificata mai intai Memcache si daca data ceruta nu este

gasita, MapFiles sunt cautate pentru rezultat.

Gestionare cache. Cand Memcache atinge dimensiunea configurata el este copiat pe disc

creand un nou MapFile si un marker este scris in Hlog asa ca atunci cand este reincarcat

intrarile log dinaninte de ultima salvare pot fi sarite. Operatia poate fi concurenta cu un

server care proceseaza cereri de citire sau scriere si ca urmare inainte ca noul MapFile sa

fie mutat citirea si scrierea sunt suspendate pana cand MapFile este adaugat la lista

MapFiles active pentru un HStore

Compactarea. Cand numarul MapFiles excede limita configurabila este realizata o

compactare minora care consolideaza cele mai recente MapFiles scrise. O compactare

majora este realizata periodic cand se consolideaza toate MapFiles intr-un singur

MapFile.

Separarea regiunilor. Cand marimea fisierelor pentru un HStore atinge o marime configurabila

(obisnuit 256MB) o separare a regiunii este ceruta. Separarea divide regiunea initiala in doua

jumatati operatie foarte rapida pentru ca regiunea copil citeste din MapFile a parintelui. Regiunea

parinte este facuta off-line, serverul de regiune inregistreaza noul copil in META region si

masterul este informat ca o separare a fost facuta si poate asigna server de regiune pentru copil.

Chiar daca mesajul de separare este pierdut, masterul va descoperi ca separarea s-a produs

deoarece se scaneaza periodic META regions pentru regiunile neasignate. HBase Client este

responsabil de gasirea HregionServers care servesc gama de randuri de interes. La instalare

HBase client comunica cu HBaseMaster pentru a gasi ROOT region. Acesta este o comunicatie

doar intre client si master. Dupa ce ROOT region este localizat, clientul contacteaza acel server

de regiune si scaneaza ROOT region pentru a gasi META region care va contine locatia pentru

regiunea utilizator ce contine gama de randuri dorita. Dupa localizarea regiunii utilizator clientul

contacteaza serverul de regiune care serveste acea regiune si furnizeaza cereri de citire sau

scriere. Informatiile sunt puse in cache de catre client asa ca urmatoarele cereri nu mai trebuie sa

parcurga intreg procesul. Cand o regiune este reasignata in urma defectarii serverului de regiune

sau pentru balansarea incarcarii clientul va rescana META table pentru a determina noua locatie

pentru regiunea utilizator. Daca META region a fost reasignata clientul va rescana ROOT region

pentru a determina noua locatie pentru META region.

Aplicarea functiilor Map si Reduce este optimizata functie de structura de date reprezentata sub

forma de pereche (cheie, valoare). Rolul functiei Map aplicata in parallel setului de date de

intrare este de a produce o lista de perechi (cheie, valoare). Secventa operatiilor este urmatoarea

[Had]:

Map se aplica in paralel fiecarui element din setul de date de intrare si produce perechi

(k2,v2) pentru fiecare apel.


71

Functia Reduce este aplicata in paralel fiecarui grup format pe baza cheilor produse de

functia map si produce o colectie de valori in acelasi domeniu

Reduce(k2, lista(v2)) =>Lista(v2)

Fiecare apel al functiei Reduce produce fie o singura valoare fie returneaza vid, un apel

nu poate returna mai mult de o valoare.

Remarcam ca, in ansamblu MapReduce transforma o lista de perechi (key, value) intr-o lista de

valori. O aplicare posibila este determinarea numarului de aparitii ale fiecarui cuvant sau chiar

asociatie de cuvinte intr-o multime de documente.

Map primeste laintrare numele documentului (ckeia1) si continutul acestuia (valoare1) si

produce carezultat lista cu perechile cuvantului din document (cheie2) si numarul de

aparitii (valoare2) pentru fiecare apel.

Reduce primeste la intrare cuvantul si lista aparitiilor acestuia in fiecare document si

produce la iesire suma aparitiilor cuvantului in colectia de documente.

MapReduce se bazeaza pe impartirea unui numar de operatii pe seturi de date la fiecare nod

dintr-o retea (cluster). Fiecare nod este asteptat sa raspunda periodic cu rezultatul procesarii si

actualizarea starii. Daca un nod nu raspunde intr-un intervalul de timp specificat, nodul master

inregistreaza nodul ca fiind defect si trimite sarcinile de procesare alocate acestuia catre alte

noduri.Din punct de vedere functional MapReduce asigura functionalitate distribuita si

principalele componente pentru implementarea sa software sunt:

Input reader divide datele de intrare in felii (bucati) ce sunt asignate la fiecare functie

map. Similar cu citirea unui dictionar in format text si returnarea de inregistrari compuse

dintr-o linie. Dimensiune 16 - 128 Mb;

Functia map preia o serie de perechi cheie/valoare, genereaza nici una sau mai multe alte

perechi cheie/valoare;

Partition function reprezinta o functionalitate a aplicatiei prin care iesirile tuturor

apelurilor functiei map sunt alocate la functii particulare Reduce. Uzual aceasta este o

functie hash de tip modulo numarul functiilor Reduce;

Functia de comparatieprin care intrarea pentru fiecare functie Reduce este luata de la

masina unde Map ruleaza;

Functia Reduce integreaza valorile asociate cu acea cheie si produce la iesire zero sau

mai multe perechi (cheie, valoare);

Output writer scrie rezultatul produs de functia Reduce intr-o structura de stocare stabila,

uzual un sistem de fisiere distribuit.

Din punct de vedere al implementarii, se impart mai intai fisierele de intrare in M componente,

uzual cu dimensiuni cuprinse intre 16 si 64 sau chiar 128 Mb.Marimea componentelor poate fi

controlata de utilizator printr-un parametru optional. O copie a programului are functionalitati

diferite si formeaza masina numita si master. Toate celelalte masini sunt executanti si au

sarcinile de procesare asignate de catre master. Masterul trebuie sa aloce M taskuri Map si R

taskuri Reduce. Masterul alege lucratori inactivi si le atribuie fiecaruia dintre ei fie un task Map

fie un task Reduce. Lucratorul care are asignat un task Map citeste continutul fragmentului de


72

intrare corespunzator. El analizeaza perechile (cheie, valoare) a datelor de intrare si paseaza

fiecare pereche la functia Map definita de utilizator. Perechile intermediare (cheie, valoare)

produse de catre functia Map sunt pastrate in memoria interna. Periodic perechile pastrate in

memoria interna sunt scrise pe discul local, partitionat in R regiuni de functia de partitionare.

Locatiile perechilor de pe discul local sunt transmise inapoi la master care este raspunzator de

inaintarea (transmiterea) acestor locatii la executantii Reduce. Cand un executant Reduce este

notificat de catre master despre aceste locatii el va initia remote procedure call pentru citirea

datelor de la discul local al masinii care a executat functia Map. Dupa ce a citit toate datele

intermediare, acesta le sorteaza dupa cheile intermediare asa ca toate perechile cu aceeasi cheie

sunt grupate impreuna. Sortarea este necesara deoarece in mod uzual mai multe chei diferite sunt

mapate la acelasi task reduce. Daca volumul de date este mare pentru ca sortarea sa se execute in

memoria interna se va utiliza o sortare externa. O masina care executa un task Reduce parcurge

datele intermediare sortate si pentru fiecare cheie unica intermediara paseaza cheia si setul

intermediar de valori la functia utilizator Reduce. Iesirea de la functia Reduce este adaugata la

iesirea finala pentru acea partitie Reduce. Cand toate taskurile Map si Reduce au fost terminate,

masterul atentioneaza programul utilizator. La acest punct apelul MapReduce de la programul

utilizator este returnat la codul utilizator.Pentru fiecare task Map si Reduce masterul pastreaza

starea si identificatorul masinii care il prelucreaza:

IDLE – stare inactiva

IN PROGRESS – task in executie

COMPLETED – task complet executat

Cum la executia in cluster sunt implicate doua entitati, acestea devin entitati susceptibile de

defectare. Defectarea unei statii lucrator (executant) este detectata de master prin mesajele

transmise periodic, mesaj de cerere ecou (ping) catre fiecare statie lucrator. Sunt posibile

urmatoarele situatii:

Pentru orice task Map care are starea COMPLETED atribuit unei masinii ce nu raspunde,

deja asignata la master, este adus in starea initiala IDLE si devine eligibil pentru a fi

distribuit altor statii ignorand procesarile deja effectuate, deoarece nu mai avem acces la

discul local al masinii pe care a fost stocat fisierul de iesire.

Toate taskurile Map si Reduce cu starea IN PROGRESS sunt aduse in starea initiala

IDLE pentru a putea fi redistribuite.

Taskurile Reduce COMPLETED nu mai trebuiesc executate deoarece iesirea lor este

stocata intr-un fisier sistem global. Atunci cand un task Map este executat de o masina A

si apoi reexecutat de o masina B, datorita defectarii lui A, toate masinile ce executa

taskuri Reduce sunt notificate pentru reexecutie. Ca urmare orice task care nu a citit deja

datele de la masina A va cunoaste ca datele de intrare trebuiesc citite de la masina B.

La defectare nodului master procedura simpla este cea de a marca periodic puncte de control la

care se scrie structura de date descrisa mai sus intr-un fisier global. La defectare o copie a

taskului master este lansata cu starea aferenta ultimului punct de control la care starea a fost

salvata.


73

Pentru echilibrarea incarcarii intr-un cluster o tehnica uzuala porneste de la divizarea in M piese

pentru Map si R piese pentru Reduce cu M si R mult mai mari decat numarul de statii de lucru

din cluster. Aceasta granularitate permite distributia sarcinilor de prelucrare mult mai echilibrat

cat si recuperarea in cazul in care o statie de lucru se defecteaza.Limitarea numarului de piese

pentru Map si Reduce este benefica pentru master, deoarece acesta trebuie sa faca M+R

planificari si trebuie sa pastreze M*R stari. Volumul de date pentru pastrarea starii este totusi

mic. In practica numarul M este determinat de volumul datelor de intrare si de marimea maxima

a unui fragment si de regula R este mult mai mic decat M. Un exemplu care sa arate gama de

marime poate fi M=200.000, R=5.000 utilizand 2000 masini.


74

Bibliografie

[Car09] Dorin Carstoiu, Baze de date, Editura Matrix Rom 2009

[Cdg06] Chang, Fay ; Dean, Jeffrey ; Ghemawat, Sanjay ; Hsieh, Wilson C. ; Wallach,Deborah

A. ; Burrows, Mike ; Chandra, Tushar ; Fikes, Andrew ; Gruber, Robert E.:Bigtable: A

Distributed Storage System for Structured Data. November 2006. –

http://labs.google.com/papers/bigtable-osdi06.pdf

[Chr] Christof S. NoSQL Databases , http://www.christof-strauch.de/nosqldbs.pdf.

[Com09] Computerworld: No to SQL? Anti-database movement gains steam. June 2009. –

http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_-

movement_gains_steam

[Con05] Thomas Connolly, Carolyn Begg, Database Systems, A Practical Approach to Design,

Implementation, and Management, Addison Wesley, 2005.

[Dat87] Date, Chris. (1987). An Introduction to Database Systems. Vols. I and II. 4th

ed.

Reading, MA: Addison-Wesley Publishing Co.

[Gam] J. Gamper – Distributed Database Design,

http://www.inf.unibz.it/dis/teaching/DDB/In/ddb03.pdf

[Eva09] Evans, Eric: NoSQL: What’s in a name? October 2009. – Blog post of 2009-10-

30.http://www.deadcafe.org/2009/10/30/nosql_whats_in_a_name.html

[Gra09] Gray, Jonathan: CAP Theorem. August 2009. – Blog post of 2009-08-

24.http://devblog.streamy.com/2009/08/24/cap-theorem/

[Had] Hadoop Map/Reduce Tutorial, http://hadoop.apache.org/docs/r0.18.3/mapred_tutorial.html

[Ho09] Ho, Ricky: NOSQL Patterns. November 2009. – Blog post of 2009-11-15.

http://horicky.blogspot.com/2009/11/nosql-patterns.html

[Ipp09] Ippolito B. 2009 , Drop ACID and think about Data – Talk at Pycon on 2009-03-28,

http://blip.tv/file/1949416/ .

[Kris10] Kristina C. and Michael D. 2010. MongoDB:The Definitive Guide. O'Reilly Media,

United States of America , p. 25-40,147-159.

[Lea] Leau C., Spring for Apache Hadoop Reference Manual,

http://static.springsource.org/spring-

hadoop/docs/1.0.0.RELEASE/reference/html/index.html

[Lip09] Lipcon, Todd: Design Patterns for Distributed Non-Relational Databases. June 2009. –

Presentation of 2009-06-11.http://www.slideshare.net/guestdfd1ec/design-patterns-for-

distributed-nonrelationaldatabases

[MCS10] Merriman, Dwight ; Chodorow, Kristina ; Stearn, Mathias et al.: mongoDB Manual–

Updating – Atomic Operations. October 2010. – Wiki article, version 42 of 2010-10-

25.http://www.mongodb.org/display/DOCS/Atomic+Operations

[ODAG] Oracle Database Administrator's Guide,

http://docs.oracle.com/cd/A97630_01/server.920/a96521/ds_concepts.htm

http://www.christof-strauch.de/nosqldbs.pdf



http://www.inf.unibz.it/dis/teaching/DDB/In/ddb03.pdf

http://www.deadcafe.org/2009/10/30/nosql_whats_in_a_name.html

http://devblog.streamy.com/2009/08/24/cap-theorem/

http://www.mongodb.org/display/DOCS/Atomic+Operations


75

[Pop10] Popescu, Alex: Presentation: NoSQL at CodeMash – An Interesting NoSQL

categorization.February 2010. – Blog post of 2010-02-

18.http://nosql.mypopescu.com/post/396337069/presentation-nosql-codemash-an-

interestingnosql

[Sco10] Scofield, Ben: NoSQL – Death to Relational Databases(?). January 2010. –

Presentation at the CodeMash conference in Sandusky (Ohio), 2010-01-14.

http://www.slideshare.net/bscofield/nosql-codemash-2010

[Silb] D. Silberberg – Distributed Database Systems - Distributed Database Design,

http://aplcenmp.apl.jhu.edu/~davids/605741/handouts/8_Distributed_Database_Design.p

df[Tec09] Technology Review: Designing for the cloud. July/August 2009. – Interview

withDwight Merriman (CEO and cofounder of

10gen).http://www.technologyreview.com/video/?vid=356

[Tod09] Todd L. 2009 , Design Patterns for Distributed Non-Relational Databases ,

http://www.slideshare.net/guestdfd1ec/design-patterns-for-distributed-nonrelational-

databases .

[5] http://www.mongodb.org

http://nosql.mypopescu.com/post/396337069/presentation-nosql-codemash-an-interestingnosql

http://nosql.mypopescu.com/post/396337069/presentation-nosql-codemash-an-interestingnosql

http://aplcenmp.apl.jhu.edu/~davids/605741/handouts/8_Distributed_Database_Design.pdf

http://aplcenmp.apl.jhu.edu/~davids/605741/handouts/8_Distributed_Database_Design.pdf

Sisteme de Baze de Date Distribuite

Documents

Transcript of Sisteme de Baze de Date Distribuite