Sisteme de Baze de Date Distribuite

Dorin CRSTOIU
EDITURA
CONSPRESS
2013
Copyright 2013, Editura Conspress i autorul

EDITURA CONSPRESS
este recunoscut de
Consiliul Naional al Cercetrii tiinifice din nvmntul Superior
Lucrare elaborat n cadrul proiectului: "Reea naional 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 Naionale a Romniei

CRSTOIU, DORIN
Sisteme de baze de date distribuite / Dorin Crstoiu
Bucureti : Conspress, 2013
Bibliogr.
ISBN 978-973-100-272-9
004.43
Carte universitar
CONSPRESS
B-dul Lacul Tei nr.124, sector 2,
cod 020396, Bucureti
Tel.: (021) 242 2719 / 300; Fax: (021) 242 0781
Sisteme de baze de date distribuite
Dorin Crstoiu
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 actualizrilor .................................................................................................. 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
Dorin Crstoiu
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
2
Dorin Crstoiu
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
3
Dorin Crstoiu
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
4
Dorin Crstoiu
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
5
Dorin Crstoiu
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
6
Dorin Crstoiu
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
7
Dorin Crstoiu
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
8
Dorin Crstoiu
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.
Dorin Crstoiu
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).
Nivel
global
(nod coordonator)
Nivel
local
(nod cooperant)
Schema
globala
Schema de
fragmentare
Schema
locala
SGBD
local
Schema de
alocare
Schema
locala
...
BD
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
10
Dorin Crstoiu
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.
Fragmente
ale tabelei T
F1
F2
...
F3
Alocare fizica
N1
N2
..
Nm
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
11
Dorin Crstoiu
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 SGBDurile 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.
12
Dorin Crstoiu
Nod
date
Cerere 1
nod
Cerere 2
Nod
date
Tranzactie 1
Nod
date
Tranzactie 2
Nod
date
nod
Tranzactie 1
Nod
date
Tranzactie 2
Nod
date
Tranzactie 1
Nod
date
Tranzactie 2
Nod
date
nod
nod
Nivel 1
Cereri la
distanta
Nivel 2
Tranzactii la
distanta
Nivel 3
Tranzactii
distribuite
Nivel 4
Cereri
distribuite
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
13
Dorin Crstoiu
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
Data
base
Data
base
Fig.2.4. Arhitectura ANSI-SPARC pe trei niveluri
14
Dorin Crstoiu
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
15
Dorin Crstoiu
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
BD1
Nod 1
BD2
Retea globala
T
Nod 1
T
T
BD3
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.
16
Nod 1
Dorin Crstoiu
BD1
Nod 1
BD2
Retea locala (LAN)
T
Nod 1
T
T
BD3
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
Gateway
Gateway
DBMS1
DBMS2
DBMS3
Fig. 2.7 Structura baza de date distribuita eterogena (Gateway)
17
Utilizator
Ingress
Ingres
(SQL)
BD
Ingres
Gateway
Baza de date
Oracle Ingres distribuita
Dorin Crstoiu
Oracle
(SQL)
BD
Oracle
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.
18
Dorin Crstoiu
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;
19
Dorin Crstoiu
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 nuplurile 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
20
Dorin Crstoiu
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)
Ang11
Ang2 (Salariu <1000)
Ang12
(D_nr 2 sau 5)
Ang21
(D-nr 4 sau 6)
Ang22
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;
21
3.2.
Dorin Crstoiu
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.
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
22
Dorin Crstoiu
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 propriuzisa, 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
23
Dorin Crstoiu
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.
24
3.4.
Dorin Crstoiu
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.
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
25
Dorin Crstoiu
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.
26
Dorin Crstoiu
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
27
Dorin Crstoiu
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
28
Dorin Crstoiu
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
29
Dorin Crstoiu
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.
R
H
H
R1
R2
R11
R12
><
><
V
R21
R22
R11
R12
R21
R22
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:
30

PNume (SResponsabil
= Popescu
Dorin Crstoiu
(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):
Locatia 5
Ang11 U Ang21
Locatia 2
Locatia 1
Ang21=Ang2><Lucr21
Ang11=Ang1><Lucr11
Locatia 3
Locatia 4
Lucr11= SResponsabil =Popescu (Lucr1)
Lucr21= SResponsabil =Popescu (Lucr2)
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.
Schema globala
Decompozitie cerere
Conversie cerere in alg. relationala pentru relatii dustribuite
Localizarea datelor
Schema fragmente
Cerere pe fragment
Statistica fragmentelor
Otimizare globala
Cerere optimizata pe fragmente
Schema locala
Otimizare locala
Cerere optimizata local
Fig. 4.3 Executie cerere distribuita

31
Dorin Crstoiu
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].
32
Dorin Crstoiu
BD distribuita
BD
Manag
BD
Product
BD
Vanzari
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
33
Dorin Crstoiu
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.
Server
Server
Cerere formulata
serverului de catre
client
INSERT INTO Dept ...
UPDATE Prod .
COMMIT
Database link
Dept
BD
Manag
Prod
BD
Product
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
34
Dorin Crstoiu
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.
SELECT *
FROM Prod
BD
Locala
Database
link
BD
distanta
Prod
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;
35
Dorin Crstoiu
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 printrun 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
36
Dorin Crstoiu
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.
37
Dorin Crstoiu
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 linkurilor 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.
38
4.3.
Dorin Crstoiu
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, emil.comenzi@vanzari.aii.pub.ro 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 emil.comenzi@vanzari.aii.pub.ro
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
39
Dorin Crstoiu
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 emil.comenzi@vanzari.aii.pub.ro;
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.
40
Dorin Crstoiu
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
41
Dorin Crstoiu
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
42
Dorin Crstoiu
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 clienti@vanzari.aii.pub.ro
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.
43
Dorin Crstoiu
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 clienti@vanzari.aii.pub.ro;
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 clienti@vanzari.aii.pub.ro
WHERE cl_id = num;
END;
Atunci cand o aplicatie locala apeleaza procedura este ascuns faptul ca stergerea se face intr-o
tabela distanta.
44
Dorin Crstoiu
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.
45
Dorin Crstoiu
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:
46
Dorin Crstoiu
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.
47
Dorin Crstoiu
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
48
Dorin Crstoiu
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 readonly 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
49
Dorin Crstoiu
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 Produse@aii.pob.ro 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:
50
Dorin Crstoiu
CREATE SNAPSHOT Replica_comenzi AS

SELECT * FROM Comenzi@brasov.ro a
WHERE EXISTS
(SELECT Cod
FROM Clienti@brasov.ro 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
51
Dorin Crstoiu
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
52
Dorin Crstoiu
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 actualizrilor
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
locaiile, 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 operaie 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
53
Dorin Crstoiu
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.
54
Dorin Crstoiu
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 relaionale 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-Relaie - 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 fiabilitii 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
55
Dorin Crstoiu
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
56
Dorin Crstoiu
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
Stocare key-value
Stocare coloane
Stocare documente
Performanta
mare
mare
mare
Scalabilitate
mare
mare
variabila
(mare)
57
Flexibilitate
mare
moderata
mare
Complexitate
nu
mica
mica
Functionalitate
variabila (nu)
minima
Variabila
(mica)

Baze de date orientate variabila
graf
Baze
de
date variabila
relationale
Dorin Crstoiu
variabila
mare
mare
variabila
mica
moderata
Teoria
grafurilor
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
58
Dorin Crstoiu
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.
59
Rand 1
Ana
42
5
Mihai
Dorin Crstoiu
Prima coloana =
Grup1
Prima coloana
27
4
Ion
22
Ana
5
Ion
27
42
Mihai
22
Coloana trei
Rand 3
a) Stocare pe rand
b) Stocare pe coloana
Ana
5
27
Ion
5
42
Mihai
4
22
Grup2 (coloanele doi, trei)
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
60
Dorin Crstoiu
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
61
Dorin Crstoiu
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
62
Dorin Crstoiu
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;
63
Dorin Crstoiu
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).
64
Dorin Crstoiu
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.
65
Dorin Crstoiu
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.
66
Dorin Crstoiu
Ofera portabilitata pe platforme eterogene. HDFS este construit pentru a oferi

portabilitate extrem de facila de la o platforma la alta.
Metadata (nume, replici):
Cale, 3,.
NameNode
Metadata ops
Block ops
Client
Citire
Noduri Date
Noduri Date
Replicare
Rack 1
Scriere
Rack 2
Client
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:
67
Dorin Crstoiu
/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 rackuri 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
68
Dorin Crstoiu
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 1010 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:
69
Dorin Crstoiu
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.
70
Dorin Crstoiu
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
71
Dorin Crstoiu
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.
72
Dorin Crstoiu
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.
73
Dorin Crstoiu
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: Whats in a name? October 2009. Blog post of 2009-1030.http://www.deadcafe.org/2009/10/30/nosql_whats_in_a_name.html
[Gra09] Gray, Jonathan: CAP Theorem. August 2009. Blog post of 2009-0824.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/springhadoop/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-fordistributed-nonrelationaldatabases
[MCS10] Merriman, Dwight ; Chodorow, Kristina ; Stearn, Mathias et al.: mongoDB Manual
Updating Atomic Operations. October 2010. Wiki article, version 42 of 2010-1025.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
74
Dorin Crstoiu
[Pop10] Popescu, Alex: Presentation: NoSQL at CodeMash An Interesting NoSQL

categorization.February
2010.
Blog
post
of
2010-0218.http://nosql.mypopescu.com/post/396337069/presentation-nosql-codemash-aninterestingnosql
[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-nonrelationaldatabases .
[5] http://www.mongodb.org
75

Sisteme de Baze de Date Distribuite

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sisteme de Baze de Date Distribuite

Încărcat de

Drepturi de autor:

Formate disponibile

Dorin CRSTOIU

Copyright 2013, Editura Conspress i autorul

Lucrare elaborat n cadrul proiectului: "Reea naional de centre pentru

Descrierea CIP a Bibliotecii Naionale a Romniei

Sisteme de baze de date distribuite

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

Sisteme de baze de date distribuite

Sisteme de baze de date distribuite

Avantaje si dezavantaje baze de date distribuite

Sisteme de baze de date distribuite

Sisteme de baze de date distribuite

2. Arhitectura unui Sistem de Gestiune pentru Baze de Date

Fig. 2.1 Arhitectura SGBDD tip ANSI

Sisteme de baze de date distribuite

Fig. 2.2 Schema de alocare

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

Fig. 2.3 Arhitectura tip IBM

Sisteme de baze de date distribuite

Fig.2.4. Arhitectura ANSI-SPARC pe trei niveluri

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

Fig 2.5 Baza de date distribuita in retea WAN

Modelul corespunde structurii organizationale a multor companii.Acestea isi desfasoara

Sisteme de baze de date distribuite

Retea locala (LAN)

Fig 2.6 Baza de date distribuita intr-o retea LAN

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

Sisteme de baze de date distribuite

Fig. 2.8 O poarta de la sistemulIngres catre sistemul Oracle

Sisteme de baze de date distribuite

3. Proiectarea unei baze de date relationale distribuite

Sisteme de baze de date distribuite

Sisteme de baze de date distribuite

Ang2 (Salariu <1000)

Fig.3.1 Fragmentarea mixta a relatiei Angajat

Sisteme de baze de date distribuite

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

> 1 replicarea este avantajoasa.

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

Sisteme de baze de date distribuite

actualizarea este mai mare, replicarea constituie o complicatie pentru pastrarea

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

Considerente legate de transparenta

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite

4. Executia cererilor distribuite

Sisteme de baze de date distribuite

Sisteme de baze de date distribuite

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

Sisteme de baze de date distribuite