Documente Academic
Documente Profesional
Documente Cultură
Sisteme de Baze de Date Distribuite PDF
Sisteme de Baze de Date Distribuite PDF
EDITURA CONSPRESS
2013
Copyright © 2013, Editura Conspress şi autorul
EDITURA CONSPRESS
este recunoscută de
Consiliul Naţional al Cercetării Ştiinţifice din Învăţământul Superior
CÂRSTOIU, DORIN
Sisteme de baze de date distribuite / Dorin Cârstoiu –
Bucureşti : Conspress, 2013
Bibliogr.
ISBN 978-973-100-272-9
004.43
Carte universitară
CONSPRESS
B-dul Lacul Tei nr.124, sector 2,
cod 020396, Bucureşti
Tel.: (021) 242 2719 / 300; Fax: (021) 242 0781
Sisteme de baze de date distribuite – Dorin Cârstoiu
Cuprins
1. Introducere ............................................................................................................................... 2
1.1. Regulile Date .................................................................................................................... 2
1.2. Avantaje si dezavantaje baze de date distribuite .............................................................. 8
2. Arhitectura unui Sistem de Gestiune pentru Baze de Date Distribuite (SGBDD) ................ 10
3. Proiectarea unei baze de date relationale distribuite ............................................................. 19
3.1. Fragmentarea .................................................................................................................. 19
3.2. Alocarea datelor ............................................................................................................. 22
3.3. Distribuirea datelor ......................................................................................................... 23
3.4. Considerente legate de transparenta ............................................................................... 25
4. Executia cererilor distribuite ................................................................................................. 27
4.1. Implicatiile fragmentarii asupra executiei cererilor ....................................................... 30
4.2. Executia tranzactiilor...................................................................................................... 32
4.3. Instructiuni SQL distribuite............................................................................................ 39
4.4. Modalitati de ascunderea locatiei ................................................................................... 43
5. Replicarea in baze de date distribuite .................................................................................... 45
5.1 Capturarea actualizarilor ..................................................................................................... 51
5.2. Aplicarea actualizărilor .................................................................................................. 53
6. Baze de date distribuite NoSQL ............................................................................................ 55
6.2. Scurtă clasificare a bazelor de date NoSQL ................................................................... 56
6.3. Nivelul de stocare ........................................................................................................... 59
6.4. Baze de date orientate document .................................................................................... 60
6.4.1. MongoDB ............................................................................................................... 60
6.4.1.1. Operatii in MongoDB ...................................................................................... 61
6.4.1.2. Aspecte privind distribuirea............................................................................. 63
6.5. Baze de date orientate coloana ....................................................................................... 64
6.5.1. HBase ...................................................................................................................... 66
Bibliografie ................................................................................................................................... 74
1
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
2
Sisteme de baze de date distribuite – Dorin Cârstoiu
3
Sisteme de baze de date distribuite – Dorin Cârstoiu
4
Sisteme de baze de date distribuite – Dorin Cârstoiu
5
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
8
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
9
Sisteme de baze de date distribuite – Dorin Cârstoiu
Nivel
global Schema Schema de Schema de
globala fragmentare alocare
(nod coordonator)
Schema Schema
locala locala
Nivel
SGBD ……... SGBD
local
local local
(nod cooperant)
BD BD
locala locala
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
F1 F2 …... F3
ale tabelei T
Alocare fizica N1 N2
….. Nm
Noduri in retea
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
Nod
Nivel 1
Cerere 1 date
nod Cereri la
Cerere 2 Nod distanta
date
Nod
Tranzactie 1 Nivel 2
date
nod Tranzactii la
Tranzactie 2 Nod distanta
date
Nod
Tranzactie 1 Nivel 3
date
nod Tranzactii
Tranzactie 2 Nod distribuite
date
Nod
Tranzactie 1 Nivel 4
date
nod Cereri
Tranzactie 2 Nod distribuite
date
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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 conceptuala
Schema de
fragmentare
Schema de alocare
Schema;locala de Schema;locala de
mapare mapare
Schema;conceptuala Schema;conceptuala
locala locala
Schema;interna Schema;interrna
locala locala
base
base
Data
Data
14
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
T T
T T
Nod 1 T Nod 1
T
BD1 BD2
Retea globala
T
Nod 1 T
T
BD3
16
Sisteme de baze de date distribuite – Dorin Cârstoiu
T T
T T
Nod 1 T Nod 1
T
BD1 BD2
T
Nod 1 T
T
BD3
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
17
Sisteme de baze de date distribuite – Dorin Cârstoiu
Baza de date BD
BD
Oracle Ingres distribuita Oracle
Ingres
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
Relatia se pastreaza la un singur nod daca cererile necesita toate datele stocate in relatie si
datele se stocheaza pe nodul care utilizeaza datele;
Un principiu universal valabil arata ca este mult mai usor sa distribuim programe in
sensul ca datele sa se gaseasca in acelasi loc cu programele decat sa transportam date.
Descompunerea relatiilor in fragmente si distribuirea fragmentelor este rezonabila daca:
Aplicatiile acceseaza usual numai anumite subseturi de date ale relatiei;
Descompunerea relatiiilor in fragmente si distributia lor permite executarea de tranzactii
in paralel intrucat fiecare operatie are nevoie de acces la un set deferit de date din relatie;
Cererile contin subcereri ce pot fi executate in paralel.
Cu toate aceste avantaje pastrarea integritatii unei relatii descompuse in fragmente si distribuite
intre mai multe noduri este greu de asigurat. Din cele analizate rezulta ca atat fragmentele cat si
relatiile sunt unitati corespunzatoare pentru distributie, insa decizia privind distributia trebuie
foarte bine analizata. Fragmentarea bazei de date asigura suplimentar o serie de alte avantaje
cum sunt: cresterea fiabilitatii, cresterea performantelor, scaderea costurilor de comunicatie,
cresterea securitatii prin politici de securitate diferite la noduri, utilizarea eficienta a capacitatii
de stocare. Alte criterii ce trebuie luate in consideratie la decizia de fragmentare constau in
analizarea locului in care o cerere se executa, ce seturi de date necesita, care este fvrecventa de
executie a unor cereri specifice, modul in care datele sunt accesate: read sau write.
Se cunosc mai multe tipuri de fragmentare, indiferent de modul in care fragmentarea este
efectuata trebuie sa existe o succesiune de operatii prin care relatia fragmentata sa poate fi
refacuta. Fragmentarea poate fi:
Orizontala– atunci cand n-uplurile relatiei sunt segmentate in mai multe fragmente
fiecare dintre acestea avand aceleasi attribute cu cele ale relatiei originale. In aceasta
situatie sunt puse intr-un fragment n-uplurile care indeplinesc o anumita conditie,
respectiv celelalte in alt fragment. Din punctul de vedere al reconstructiei o simpla
operatie UNION reface relatia initiala. In principal, fragmentarea orizontala decupeaza o
tabela pe orizontala pastrand in fiecre fragment inregistrarile satisfacand o anumita
conditie ce defineste setul de inregistrari. Fragmentarea orizontala nu afecteaza
redundanta in sensul ca fragmentele pot sa contina date distincte si nu sunt pastrate
aceleasi n-upluri in mai multe fragmente. Pentru descompunerea unei relatii in fragmente
se executa operatii similar cu operatiaSELECT din algebra relationala. Daca o relatie R a
fost fragmentata orizontal in fragmentele R1, R2, R3, putem a recompune relatia initiala
prin 𝑅 = 𝑅1 ∪ 𝑅2 ∪ 𝑅3 ;
Verticala – partitonarea relatiei dupa atributele sale. Un fragement contine toate n-
uplurile relatiei, insa numai anumite atribute ale acesteia. Pentru refacerea relatiei initiale
este necesara o operatie de tip join insa pentru realizarea acesteia fragmentele trebuie sa
contina ca informatie redundanta macar atributul cheie al relatiei initiale. Se observa ca
fragmentarea pe verticala necesita un grad mai mare de redundanta pentru pastrarea in
fiecare fragment a atributului cheie. Fie o relatie R si S1, respectiv S2 doua subseturi de
atribute ale lui R, ambele subseturi contin cel putin un atribut cheie si reuniunea celorlalte
20
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
21
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
22
Sisteme de baze de date distribuite – Dorin Cârstoiu
23
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
24
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
25
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
29
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
R U
H H
R1 R2 >< ><
V V V V
R11 R12 R21 R22 R11 R12 R21 R22
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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 1 Locatia 2
Ang11=Ang1><Lucr11 Ang21=Ang2><Lucr21
Locatia 3 Locatia 4
Lucr11= SResponsabil =“Popescu” (Lucr1) Lucr21= SResponsabil =“Popescu” (Lucr2)
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:
In general, o procesare a cererii urmareste executia dupa s schema similara cu cea ilustrata in
figura 4.3.
Cerere pe fragment
31
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
32
Sisteme de baze de date distribuite – Dorin Cârstoiu
BD distribuita
BD BD
Manag Product
. BD
Vanzari .
33
Sisteme de baze de date distribuite – Dorin Cârstoiu
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 Database link
client
INSERT INTO Dept ...
UPDATE Prod ….
COMMIT
BD BD
Manag Product
Dept Prod
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
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
Database
SELECT * BD link BD
FROM Prod Locala distanta
Prod
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
Fixed User Link. Este o conexiune prin care utilizatorul se conecteaza folosind numele
de utilizator si parola precizate in definitia link-ului, adica numele si parola sunt fixate
odata cu definirea link-ului. In acest caz utilizatorul ion, care utilizeaza un fixed user
link avand nume utilizator emil si parola a397a ce conecteaza baza de date Manag cu
baza de date Product se va conecta la baza de date Product ca utilizatorulemil si va
avea toate privilegiile si rolurile pe care emil le are la aceasta baza de date. Cu o astfel
de conexiune se creaza utilizatori neglobali la o baza de date distanta cu nume utilizator
si parola pastrate necriptat in dictionarul de date. Un astfel de link este usor de creat,
necesita informatii suplimentare minimale, nu necesita canal de comunicatie SSL, dar
prezinta o vulnerabilitate majora de securitate prin faptul ca parola este stocata in clar.
Exemple:
o CREATE PUBLIC DATABASE LINK product.aii.pub.ro CONNECT
TO emil AS a379c – un link global public ce utilizeaza numele global al
bazei de date product, iar conexiunea cu baza de date distanta este facuta cu
user/pass emil/a379c.
o CREATE DATABASE LINK leg3 CONNECT TO emil IDENTIFIED
BY a379c USING „service‟ – un link privat fixat cu numele leg3 ce
utilizeaza serviciul cu numele service. Linkul conecteaza utilizatorul la baza
distanta cu user/passemil/a379c.
Current user link. Este un link ce conecteaza utilizatorul la baza de date ca un utilizator
global. Un utilizator local se poate conecta la o baza distanta ca un utilizator global in
contextual utilizarii unei proceduri stocate fara a stoca parola utilizatorului in definirea
link-ului. Astfel ion poate avea acces la procedurile scrise de emil accesand contul
emil si schema din baza de date.
Database link permite accesul la obiectele unei baze de date distante de catre utilizatori ai unei
baze de date locale fara ca acestia sa fie utilizatori ai bazei indepartate. Definitia acestuia este
pastrata in scema locala si poate fi utilizat ca orice alt obiect din schema locala in instructiunile
SQL. In tehnologia Oracle “shared database link” este un link intre un proces server local si o
baza de date distanta. Atunci cand o baza de date locala este conectata la o baza distanta printr-
un database link baza de date poate rula in mod dedicate sau in shared server mode. Diferenta
dintre shared database link si un link standard consta in:
Utilizatori diferiti ce acceseaza acelasi obiect din schema printr-un database link pot
partaja conexiunea de retea;
Atunci cand un utilizator stabileste o conexiune cu un server distant de la un process
server specific, procesul poate reutiliza conexiunea deja stabilita cu respectivul server
chiar si in situatia in care conexiunea a fost deja stabilita intr-o alta sesiune.
Intr-un sistem de baze de date distribuite fiecare fragment al bazei de date trebuie sa se identifice
unuic prin numele sau global (global database name). In tehnologia Oracle numele global este
obtinut prin prefixarea numelui de domeniu al retelei cu numele bazei de date. Cele doua
36
Sisteme de baze de date distribuite – Dorin Cârstoiu
37
Sisteme de baze de date distribuite – Dorin Cârstoiu
Link public – creat de utilizator ca link public, ce poate fi utilizat de toti utilizatorii si
toate programele care il apeleaza pentru a accesa obiectele bazei de date distante.
Exemple:
o CREATE PUBLIC DATABASE LINK product.aii.pub.ro – un link
public la baza de date distanta product ce utilizeaza user/pass a utilizatorului
conectat. Daca emil cu parola a379c utilizeaza linkul intr-o cerere acesta
stabileste o conexiune la baza distanta cu user/pass emil/a379c.
o CREATE PUBLIC DATABASE LINK product.aii.pub.ro CONNECT
TO emil IDENTIFIED BY a379c – un link public fixat cu utilizator si
parola specificata in definitia sa, user/pass emil/a379c.
o CREATE PUBLIC DATABASE LINK p_leg CONNECT TO
CURRENT_USER USING “serv1” – un link public numit p_leg la baza
de date distanta cu numele de serviciu serv1, care utilizeaza user/pass a
utilizatorului curent pentru conectarea la baza de date distanta (utilizatorul curent
poate sa nu fie acelasi cu cel conectat, dar trebuie sa fie un utilizator global la
ambele baze de date.
Link global – creat de un utilizator public si toti utilizatorii sau programele ce utilizeaza
linkul pot accesa obiectele din baza de date corespondenta.
Alegerea tipului de database link este depinde de cerintele specifice ale aplicatiei ce utilizeaza
sistemul. Un link privat este mult mai securizat in comparatie cu un link public sau global
intrucat el poate fi utilizat numai de proprietar sau de subprogramele acestuia care se gasesc in
aceeasi schema. Atunci cand mai multi utilizatori necesita o cale de acces la o baza de date
distanta, exista alternativa de creare a unui singur database link public ce poate fi utilizat de catre
toti care acceseaza baza distanta. Pentru a simplifica administrarea centralizata a database link-
urilor de catre un singur administrator se recomanda crearea lor ca database link globale.
Pentru ca aplicatiile sa poata accesa datele si alte obiecte in sistemul distribuit este necesara
crearea database link-urilor necesare. Pentru a crea database link utilizatorul trebuie sa aiba
privilegiile corespunzatoare tipului de database link pe care il creaza. Aceste privilegii sunt:
CREATE DATABASE LINK – permite crearea numai de database link privat;
CREATE PUBLIC DATABASE LINK – permite crearea si de database link public;
CREATE SESSION – Crearea oricarui tip de database link.
Un database link defineste o comunicaie intre o baza de date si o alta distanta. Atunci cand o
aplicatie utilizeaza un database link pentru accesul la o baza de date distanta se stabileste o
sesiune cu baza de date distanta in beneficiul aplicatiei care formuleaza cererea. Tipul de
conexiune este stabilit in momentul in care se creaza database link-ul.In multe situatii se creaza o
multime de legaturi la diverse baze de date, legaturi ce sunt de acelasi tip si vizeaza accesul la
aceeasi baza de date.
38
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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:
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
42
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
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.
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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:
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.
Atunci cand o aplicatie locala apeleaza procedura este ascuns faptul ca stergerea se face intr-o
tabela distanta.
44
Sisteme de baze de date distribuite – Dorin Cârstoiu
45
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
48
Sisteme de baze de date distribuite – Dorin Cârstoiu
49
Sisteme de baze de date distribuite – Dorin Cârstoiu
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:
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:
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
51
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
53
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
55
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
56
Sisteme de baze de date distribuite – Dorin Cârstoiu
de noi facilitati. Unele au fost inspirate din Dynamo sau Bigtable, altele au pornit de la baze de
date existente sau au venit cu idei noi. Este dificila o clasificare a acestora din cauza varietatii si
a metodelor de implementare.
Conform [Chr] Stepen Yen sugereaza o clasificare a bazelor de date NoSQL pe baza modelului
datelor in urmatoarele categorii:
Key-Value-Cache din care fac parte Memcached, Repcached, Coherence,Infinispan,
Extreme Scale, Jboss Cache, Velocity, Terracoqa;
Key-Value-Store cu membrii: Keyspace, Flare, Schema Free, RAMCloud;
Eventually-Consistent Key-Value-Store cu reprezentatii: Dynamo, Voldemort, Dynomite,
SubRecord, Mo8onDb, Dovetaildb;
Ordered-Key-Value-Store cu reprezentantii: Tokyo Tyrant, Lighcloud, NMDB, Luxio,
MemcacheDB, Actord;
Data-Structures Server in implementarea Redis;
Tuple Store in implementarile Gigaspaces, Coord, Apache River;
Object Database cu reprezentantii: ZopeDB, DB4O, Shoal;
Document store cu o multime de implementari in CouchDB, Mongo, Jackrabbit, XML
Databases, ThruDB, CloudKit, Perservere, Riak Basho, Scalaris;
Wide Columnar Store avand ca membrii Bigtable, Hbase, Cassandra, Hypertable, KAI,
OpenNeptune, Qbase, KDI.
O alta clasificare se gaseste in articolul “Database in the cloud” scris de Ken North si include
numai bazele de date NoSQL utilizazte la stocarea datelor in cloud computing [Chr]:
Distributed Hash Table, Key-Value Data Stores cu reprezentantii: memcached,
MemcacheDB, Project Voldermort, Scalaris, Tokyo Cabinet;
Entity-Attribute-Value Datastores cu membrii: Amazon SimpleDB, Google AppEngine
datastore, Microsoft SQL Data Services, Google Bigtable, Hadoop, HyperTable, HBase.
Amazon Platform Amazon Simple DB;
Document Stores, Column Storescu membrii Sybase IQ, Vertica Analytic Database,
Apache CouchDB.
Rick Cattel imparte bazele de date NoSQL in 3 categorii dupa modelul datelor in urmatoarele
categorii: Key-value Stores, Document Stores, Extensible Record Stores. Poate cea mai buna
clasificare este data de [Pop10] si [Sco10] tinand cont de criterii nefunctionale si de facilitatile
oferite: performanta, scalabilitate, flexibilitate, complexitate si functionalitate. Sinteza este
reprezentata in tabelul 6.1.
Tabelul 6.1
Performanta Scalabilitate Flexibilitate Complexitate Functionalitate
Stocare key-value mare mare mare nu variabila (nu)
Stocare coloane mare mare moderata mica minima
Stocare documente mare variabila mare mica Variabila
(mare) (mica)
57
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
59
Sisteme de baze de date distribuite – Dorin Cârstoiu
Prima coloana =
Rand 1 Prima coloana
Grup1
Ana 5 27 Ion 5 Ana Ion Mihai 5 Ana Ion Mihai
42 Mihai 4 22 5 4 27 42 22 5 27 5 42 4 22
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.
60
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
61
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
63
Sisteme de baze de date distribuite – Dorin Cârstoiu
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.
64
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
Block ops
Client
Replicare
Client
67
Sisteme de baze de date distribuite – Dorin Cârstoiu
/cale/part-0,r:2,{1,3},...
/cale/part-0,r:3,{2,4,5},...
este precizata calea, numele fisierului, numarul de replici al blocurilor. Astfel, part-0 are 2 replici
pentru blocurile 1 si 3 si 3 replici pentru blocurile 2,4,5. Din punctul de vedere al localizarii
instantele HDFS se intind peste mai multe rack-uri, tinand cont de considerentelegate de
largimea de banda care este mai mare in interorul unui rack, dar plasarea copiilor pe un singur
rack poate duce la pierderea datelor la defectarea sa, insa plasarea replicilor pe mai multe rack-
uri creste costul comunicatiei. Ca urmare o politica corecta arata case recomanda pastrarea a
doua replici la masini din acelasi rack si cel putin o replica la un nod situat pe alt rack. Aceasta
politica limiteaza traficul de scriere intre rackuri si sansa de defectare a intregului rack este mult
mai mica fata de sansa de defectare a unui nod. Din punctul de vedere al latentei pentru
minimizarea sa la citire, HDFS incearca sa faca citirea datelor de la replica cea mai apropiata,
astfel ca daca exista o replica gazduita de acelasi rack aceasta va fi preferata. NameNode
utilizeaza un log al tranzactiilor pentru pastrarea persistenta a inregistrarilor la fiecare schimbare
in metadate (EditLog), in sistemul local. Intregul file system mamespace, incluzand si maparea
blocurilor la fisiere si proprietatile fisierelor se pastreaza in FsImage ca fisier local. O imagine a
intreg file system namespace si block map este tinuta in memorie, formatul este compact si in
4GB RAM se poate tine un numar mare de fisiere si directoare. La boot se citeste FsImage si
EditLog, aplica toate tranzactiile din EditLog si creaza o noua versiune pentru FsImage.
DataNode pastreaza datele HDFS ca fisiere in sistemul de fisiere local si nu are cunostinte despre
fisierele HDFS. Fiecare bloc de date HDFS este pastrat in fisiere distincte in sistemul de fisiere
local. Distributia fisierelor in directoare este importanta doar pentru optimizarea locala. O
cererea clientului de creare a unui fisier nu necesita utilizare imediata a NameNode. Initial
clientul HDFS pastreaza datele intr-un fisier temporar local.Operatiile de scriere sunt transparent
redirectate la acest fisier local temporar. Cand nu mai incap intr-un bloc se contacteaza
NameNode care insereaza fisierul in ierarhia sistemului si aloca blocuri de date pentru el,
raspunde cererii clientului cu identitatea DataNode si clientul va trimite datele la nodul de date
specificat. La inchiderea unui fisier, datele netransportate inca din fisierul temporar local sunt
transferate la nodul de date destinatie, clientul anunta NameNode ca fisierul este inchis, moment
la care NameNode dicteaza crearea fisierului. La momentul la care un nod incepe sa receptioneze
date, acesta incepe sa stocheze o mica portiune pe care o scrie pe disc si o transmite urmatorului
nod la care replica se pastreaza, facand transmiterea datelor intre noduri ca intr-un registru de
deplasare.
Modelul Hbase este mult mai atractiv si mai riguros decat modelul SQL impunand oredondanta
mult mai mica. In general se spune ca companiile mari utilizand SQL mizeaza pe puterea
hardware incercand in acest mod sa ofere performantele dorite (exemplu, cumpararea Sun de
catre Oracle).Apache cu Hbase urmareste sa furnizeze stocare similara cu BigTable pentru
mediul de calcul distribuit Hadoop in care datele sunt organizate in tabele, randuri si coloane,
fiecare coloana particulara poate avea multiple versiuni pentru aceeasi cheie de rand utilizand un
model similar cu BigTable. Aplicatiile pastreaza randurile de date in tabele etichetate, randurile
68
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
72
Sisteme de baze de date distribuite – Dorin Cârstoiu
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
Sisteme de baze de date distribuite – Dorin Cârstoiu
Bibliografie
74
Sisteme de baze de date distribuite – Dorin Cârstoiu
75