Carte Big Data 2016 PDF

BOGDAN GEORGE TUDORICA
)
)
)
CALATORIE
PRIN LUMEA BIG DATA
PRIN LUMEA BIG DATA

)
CALATORIE
)
ISBN 978-606-23-0605-2
9 786062 306052
”Călătorie prin lumea Big Data”, scrisă
de Bogdan George Tudorică, este disponibilă
sub o Licență internațională Creative
Commons Attribution 4.0.
”Călătorie prin lumea Big Data”, by Bogdan

George Tudorică, is licensed under a Creative
Commons Attribution 4.0 International
License.
CALATORIE
PRIN LUMEA BIG DATA
Editura PRINTECH
2016
Editura PRINTECH
Tipar executat la:

S.C. ANDOR TIPO S.R.L. - Editura PRINTECH
Site: www .andortipo.ro; www.printech.ro
Adresa: Str. Tunari nr.11, Sector 2, Bucure~ti
Tel./Fax: 021.211.37.12; 021.212.49.51
E-mail: comenzi@.andortipo.ro
Descrierea CIP a Bibliotecii Nationale a Romaniei

TUDORICA, BOGDAN
Calatorie prin lumea Big Data I
Bogdan George Tudorica. -
Bucure~ti : Printech, 20 l 6
Contine bibliografie
ISBN 978-606-23 -0605 -2
004
© Copyright 2016
Toate drepturile prezentei editii sunt rezervate autorului.
Nicio parte din aceasta lucrare nu poate fi reprodusa,
stocata sau transmisa indiferent prin ce forrna, ftira acordul
prealabil scris al autorului.
Cuprins
Introducere ................................................................................ 3
Partea întâi – trecut și prezent în Big Data.............................. 13
1 Aspecte privind modalitățile de structurare a volumelor
mari de date ......................................................................... 13
1.1 Organizarea structurată a volumelor mari de date.
Baze de date relaționale. Depozite de date ..................... 13
1.2 Organizarea semistructurată a volumelor mari de
date. Baze de date NoSQL (Not Only SQL) ................... 47
1.3 Concluzii parţiale .................................................. 64
2 Prelucrarea volumelor mari de date ............................ 65
2.1 Suportul fizic utilizat pentru prelucrarea volumelor
mari de date ..................................................................... 65
2.2 Prelucrarea volumelor mari de date structurate .. 119
2.3 Măsurarea performanței în prelucrarea volumelor
mari de date ................................................................... 150
2.4 Concluzii parţiale ................................................ 169
Partea a doua – viitorul Big Data .......................................... 171
3 Soluții de structurare a volumelor mari de date în
sistemele NoSQL .............................................................. 171
3.1 Trecerea de la organizarea structurată a volumelor
mari de date la organizarea semistructurată .................. 171
3.2 Soluții de organizare semistructurată a volumelor
mari de date ................................................................... 184
3.3 Implementarea unei soluții de organizare
semistructurată a volumelor mari de date ..................... 191
4 Soluții de prelucrare a volumelor mari de date în
sistemele NoSQL .............................................................. 203
4.1 Soluții de prelucrare a volumelor mari de date
organizate semistructurat. Soluţii hibride depozit de date /
bază de date NoSQL ..................................................... 203
1
4.2 Implementarea unei soluții de măsurare a
performanței în prelucrarea volumelor mari de date
organizate semistructurat .............................................. 242
Partea a treia - Abordarea programatică a Big Data ............. 261
5 Proiectarea și implementarea unei aplicații de interfață
pentru organizarea și prelucrarea volumelor mari de date
semistructurate .................................................................. 261
5.1 Proiectarea aplicației. Facilități urmărite ........... 264
5.2 Implementarea aplicației ASMDB. Rezultate
obținute ......................................................................... 277
5.3 Analiza stadiului la care a ajuns aplicaţia ASMDB
(concluzii parţiale) ........................................................ 307
Concluzii ............................................................................... 311
Referințe bibliografice .......................................................... 315
Lista figurilor și a tabelelor ................................................... 327
2
Călătorie prin lumea Big Data
Introducere
Scopul lucrării de față, intitulată „Călătorie prin lumea
Big Data”, este studierea modului în care creşterea volumului
de date influenţează operaţiile uzuale efectuate asupra datelor
şi toate procedurile tehnologice asociate acestor operaţii. De
asemenea, lucrarea îşi propune găsirea unor metode de
organizare a volumelor mari de date (Big Data) de aşa natură
încât siguranţa şi performanţa în utilizarea acestora să crească.
Trebuie subliniat că în cadrul conceptului de volume
mari de date avut în vedere în această lucrare au fost incluse
toate formele de organizare a datelor care pot duce la
acumularea de date în cantităţi care să justifice eticheta de
„volum mare”, nu numai aplicaţiile considerate tradiţional ca
fiind bazate pe cantităţi mari de date (ex. depozite de date).
Autorul a apelat la această extindere datorită faptului că, în
ultimii ani, aceste aplicaţii tradiţionale au fost depăşite cu mult
în ceea ce priveşte volumele de date vehiculate de către tipuri
de aplicaţii nou apărute, fie că e vorba de aplicaţii web, fie că e
vorba de aplicaţii cloud, sau de diverse alte aplicaţii bazate pe
tehnologii asemănătoare. O astfel de mutare a centrului de
greutate a avut loc şi în domeniul bazelor de date care suportă
aceste aplicaţii, unde au căpătat o prioritate mare bazele de date
NoSQL.
Domeniul organizării datelor în general este un
domeniu intens studiat, fiind de altfel unul dintre cele mai
vechi domenii din informatică. Astfel, sunt bine cunoscute
aspectele legate de stocarea datelor pe diverse suporturi de
stocare, împreună cu toate detaliile ce decurg din aceasta (mod
şi tehnologii de stocare, densitate de stocare, calităţi şi
dezavantaje ale diverselor tehnologii) şi respectiv de
organizarea datelor (formate de fişiere, colecţii, baze de date),
metode de optimizare a acesteia (compresia datelor pentru
3
Tudorică Bogdan George
stocare sau pentru transmisie), dar şi metode de securizare

(redundanţă, sume de control etc.).
Problematica ridicată de volumele mari de date este o
problematică nouă, până în urmă cu câţiva ani neexistând
tehnologia necesară pentru a stoca volume mari de date (anul
2009 este anul apariţiei în uz comercial a unităţilor de stocare
având capacităţi de peste 1TB).
Este de notat totuşi faptul că fiecare perioadă a epocii
informaticii începând din anii ’70 şi-a pus problema organizării
a ceea ce reprezentau volume mari de date pentru perioada
respectivă.
Se poate cu siguranţă marca perioada actuală ca fiind cu
adevărat perioada volumelor mari de date, pentru că este pentru
prima dată când dispozitivele de stocare uzuale oferă spaţiu
suficient de mare încât să reprezinte individual o provocare
pentru capacităţile de prelucrare şi transfer disponibile.
Un indicator al interesului mare reprezentat de această
problematică este faptul că toţi marii competitori pe piaţa
bazelor de date (Oracle, IBM, Microsoft, SAP) participă şi
sprijină activ cercetările şi conferinţele de profil. Mai mult
decât atât, în ultimii trei ani (ulterior începerii studiului pentru
această lucrare), unul dintre cei trei competitori a pus la
dispoziţia clienţilor săi un produs NoSQL (Oracle NoSQL
Database), iar o alta dintre cele trei companii are în serviciu
comercial un sistem cloud de mari dimensiuni (Microsoft
OneDrive).
Lucrarea de faţă îşi propune următoarele obiective:
 Studierea modului în care sunt structurate volumele
mari de date;
 Studierea metodelor şi tehnologiilor existente pentru
prelucrarea volumelor mari de date;
 Studierea metodelor de măsurare a performanţei
atinse în utilizarea volumelor mari de date.
4
 Identificarea provocărilor (traduse în posibile

direcţii de cercetare / dezvoltare) ridicate de
introducerea sistemelor NoSQL;
 Formularea unor posibile soluţii la aceste provocări
(identificarea unor produse pasibil de a fi utilizate,
formularea unor reguli de bună practică etc.)
Elementele de noutate aduse de această lucrare sunt:
 Analiza stadiului actual al cunoaşterii în domeniul
organizării volumelor mari de date precum şi în
enunţarea unor sinteze referitoare la acest stadiu.
Sunt prezentate detaliat tehnologiile utilizate,
avantajele şi dezavantajele acestora, performanţele
atinse şi se fac comparaţii calitative şi cantitative
între aceste tehnologii.
 Selectarea şi compararea tehnologiilor fezabile
pentru administrarea volumelor mari de date precum
şi în realizarea unei aplicaţii concrete de
administrare a volumelor mari de date. Sunt
prezentate detaliat tehnologiile utilizate, avantajele
şi dezavantajele acestora, performanţele atinse şi se
fac comparaţii calitative şi cantitative între aceste
tehnologii.
 Realizarea unei metodologii pentru măsurarea
performanţei infrastructurii de stocare utilizate în
organizarea volumelor mari de date de şi
implementarea unei aplicaţii informatice pe baza
acestei metodologii.
 Proiectarea şi realizarea unei aplicaţii care,
împreună cu un mecanism de gestiune a datelor (în
speţă o aplicaţie de gestiune a bazelor de date
NoSQL) să furnizeze un pachet de facilităţi de
administrare a volumelor mari de date.
5
Lucrarea este structurată în două părţi cuprinzând cinci

capitole, care vor fi descrise succint în cele ce urmează.
Prima parte a lucrării (conţinând capitolele unu şi doi)
analizează şi sintetizează stadiul actual al cunoaşterii în
domeniul organizării volumelor mari de date.
Primul capitol tratează modalităţile în care sunt
structurate volumele mari de date în aplicaţiile actuale. Sunt
analizate separat modalităţile de organizare structurată a
volumelor mari de date (care sunt în cele mai multe cazuri baze
de date relaţionale) şi modalităţile de organizare
semistructurată a volumelor mari de date (mai nou apărutele
baze de date NoSQL – Not Only SQL).
Cel de-al doilea capitol acoperă stadiul actual al
cunoaşterii în domeniul prelucrării volumelor mari de date. Un
prim subcapitol tratează suportul fizic utilizat pentru
prelucrarea volumelor mari de date (sisteme de calcul de înaltă
performanţă, prelucrare distribuită, mijloace alternative de
creştere a performanţei). Un al doilea subcapitol tratează
modalitatea tradiţională de prelucrare a volumelor mari de date
– depozitele de date. Ultimul subcapitol din capitolul doi
descrie modul în care poate fi măsurată performanţa obţinută la
prelucrarea volumelor mari de date.
Capitolul al treilea deschide partea a doua a lucrării,
parte în care sunt descrise, analizate şi propuse diverse soluţii
noi de organizare a volumelor mari de date. Capitolul conţine
trei subcapitole care descriu modul în care se poate face
trecerea de la aplicaţiile tradiţionale bazate pe date organizate
structurat la aplicaţii de generaţie nouă care utilizează şi date
organizate semistructurat, soluţii de organizare semistructurată
6
a datelor, precum şi ideile care stau la baza implementării unei

aplicaţii bazate pe date organizate semistructurat.
Capitolul patru se referă la modul în care pot fi
prelucrate volumele mari de date organizate semistructurat şi
performanţele care pot fi atinse în cadrul acestui tip de
prelucrări. Cel de-al doilea subcapitol descrie în mod particular
o metodologie propusă de autor pentru măsurarea performanţei
oferite de infrastructura ce stă la baza aplicaţiilor bazate pe
volume mari de date organizate semistructurat. Pe baza
metodologiei respective, autorul a realizat şi o aplicaţie de
benchmarking, descrisă în acelaşi subcapitol, aplicaţie care
analizează comparativ performanţele unui SGBD relaţional
(MySQL) şi a unuia NoSQL (MongoDB).
Vocabular utilizat
Date - Datele sunt valori ale unor variabile calitative

sau cantitative aparţinând de un set de itemi. Datele pot fi
privite ca fiind cel mai scăzut nivel de abstractizare de la care
informaţiile şi cunoştinţele sunt derivate.
Volum mare de date (Big data) – Volum de date care
depășeşte din punct de vedere cantitativ tehnologiile utilizabile
în mod obişnuit pentru prelucrare, stocare sau transport imediat
disponibile în momentul respectiv. Conceptul are semnificaţie
aparte pentru fiecare dintre cele trei categorii de operaţii (se
poate defini conceptul de volum mare de date în raport cu
operaţiile de prelucrare, cu cele de stocare sau cu cele de
transport).
Astfel, din punct de vedere al prelucrării, un volum
mare de date reprezintă o cantitate de date care necesită un
timp de prelucrare semnificativ mai mare decât cele acceptabile
pentru aplicaţiile obişnuite (secunde, minute). Poate fi vorba de
7
o cantitate de date care necesită pentru prelucrare calculatoare

de mare putere sau care necesită soluţii distribuite de prelucrare
sau chiar pentru care nu există la momentul respectiv soluţii de
prelucrare integrală în timp rezonabil.
Din punct de vedere al stocării, conceptul de volum
mare de date reprezintă acea cantitate de date care nu poate fi
stocată folosind o soluţie obişnuită de stocare, necesitând fie o
formă distribuită de stocare, fie unităţi de stocare de mare
capacitate (mass storage) care sunt prea scumpe pentru aplicaţii
comune, fie chiar depăşind limitele echipamentelor de stocare
de orice tip din momentul respectiv (la acest moment unităţile
de stocare disponibile în mod obişnuit au capacităţi de stocare
de ordinul a 1-1,5 TB pentru piaţa SOHO şi 4-8 TB pentru
piaţa high-end).
Din punct de vedere al transferului, un volum mare de
date reprezintă acea cantitate de date care nu poate fi transmisă
într-un timp rezonabil folosind mijloacele tehnologice ale
momentului. La acest moment limitele maxime pentru
transferul la distanţă sunt situate la aproximativ 12 MBs/100
Mbs pentru utilizatorii SOHO, capacităţile maxime de transfer
în uz comercial sunt de aproximativ 2-3 Tbs iar performanţele
record înregistrate se situează în jurul valorii de 100 Tbs [28].
În orice caz, admiţând că soluţia tehnologică aleasă pentru
stocare / prelucrare este una distribuită, capacitatea de transfer
disponibilă se situează în plaja 5-14 Mbs [24].
Baze de date - O bază de date este o colecţie integrată
de înregistrări corelate în mod logic sau de fişiere consolidate
într-un fond comun care oferă date pentru una sau mai multe
utilizări. Termenul de bază de date se referă atât la datele
propriu-zise cât şi la structurile de date în care sunt stocate
datele şi metadatele corespunzătoare (colecţiile cu datele
propriu-zise, dicţionarul de date - structura de date, restricţiile
de integritate, viziunile, clusterele etc., fişierele anexe - fişiere
de parametri, fişiere de index etc.). Software-ul organizează
8
datele într-o bază de date în conformitate cu un model de bază

de date.
Sistem de gestiune a bazelor de date (SGBD) - Un
SGBD este un set de aplicaţii care controlează organizarea,
stocarea, extragerea, gestionarea şi recuperarea datelor dintr-o
bază de date.
Baze de date de foarte mari dimensiuni (Very Large
Database) - O bază de date de foarte mari dimensiuni este o
bază de date care conţine un număr extrem de mare de tuple /
înregistrări, sau ocupă un spaţiu extrem de mare pe sistemul de
fişiere / sistemul fizic de stocare. Definiţia unei baze de date de
foarte mari dimensiuni este o bază de date ce ocupă mai mult
de 1 terabyte sau conţine mai multe miliarde de înregistrări (cu
precauţia că în mod natural această definiţie se modifică în
timp în funcţie de capabilităţile sistemelor de calcul folosite la
momentul respectiv). Ţinând cont de conceptul de volum mare
de date descris mai sus, o bază de date de foarte mari
dimensiuni poate fi definită şi ca o bază de date conţinând un
volum mare de date.
Tranzacţie (efectuată pe o baze de date) – O
tranzacţie este o unitate de prelucrare care cuprinde un număr
de operaţii efectuate asupra unei baze de date (ex. citirea unui
obiect din baza de date, scrierea, blocarea etc.) care sunt
executate împreună. O tranzacţie poate fi evaluată ca fiind
coerentă şi de încredere independent de alte tranzacţii. În
sistemele de baze de date relaţionale, o tranzacţie trebuie să fie
atomică, coerentă, izolată şi durabilă (Atomic, Consistent,
Isolated, Durable - ACID). În sistemele de baze de date
NoSQL se admite derogarea de la / reformularea celor patru
caracteristici ajungându-se la următorul set: disponibilitate de
bază, stare incomplet definită, consistenţă atinsă în cele din
urmă (Basic Availability, Soft state, Eventual consistency -
BASE).
9
Consistenţă - În contextul ACID, consistenţa se referă

la oferirea unei garanţii că atunci când o tranzacţie este
terminată, baza de date se află într-o stare consistentă. În
sistemele ACID acest tip de consistenţă este parţial
responsabilitatea dezvoltatorului care scrie codul pentru
tranzacţii şi parţial asigurată de către constrângerile de
integritate ale bazei de date. Sunt definite mai multe tipuri de
consistenţă:
Consistenţă puternică. După finalizarea unei
modificări, orice interogări ulterioare vor returna valoarea
modificată.
Consistenţă slabă. Sistemul nu garantează că orice
interogare ulterioară unei modificări va returna valoarea
modificată. Pentru ca acest lucru să se întâmple, trebuie
îndeplinite un număr de condiţii. Perioada de timp în care încă
mai există posibilitatea returnării de către o interogare a valorii
nemodificate se numeşte fereastră de inconsistenţă.
Consistenţă „în cele din urmă”1 (eventual
consistency). Aceasta este o formă specifică de consistenţă
slabă în care sistemul de stocare garantează că dacă după o
modificare nu vor fi făcute noi şi noi modificări ale unui obiect,
în cele din urmă toate interogările referitoare la obiectul
respectiv vor returna valoarea modificată. Dacă nu apare niciun
fel de probleme, dimensiunea maximă a ferestrei de
inconsistenţă poate fi determinată pe baza a diverşi factori cum
ar fi întârzierile de comunicaţie, gradul de încărcare al
sistemului şi numărul de replici din schema de replicare. DNS
(Domain Name System) este un exemplu clasic de sistem cu
consistenţă „în cele din urmă”.
1
Termenul nu a mai fost tradus / utilizat în limba română până acum.
Consider că traducerea alternativă „consistenţă eventuală” induce un sens
eronat în sensul că presupune şi cazul în care consistenţa nu ar fi atinsă.
10
Modelul de consistenţă „în cele din urmă” are

următoarele subtipuri:
Consistenţă cauzală. Dacă un proces A a comunicat
procesului B că anumite date au fost modificate, orice
interogare ulterioară executată de B va returna valoarea
modificată, şi orice nouă modificare va ţine cont garantat de
prima modificare. Modificările executate de un alt proces C
care nu are o relaţie cauzală cu A face subiectul regulilor
normale de consistenţă „în cele din urmă”.
Consistenţă „read-your-writes”. Un model de
consistenţă în care orice proces ţine cont în mod garantat de
propriile modificări mai vechi ale datelor. Acesta este un caz
special de consistenţă cauzală
Consistenţă de sesiune. Este o formă practică de
consistenţă „read-your-writes” în care procesul accesează
datele în contextul unei sesiuni. Atât timp cât sesiunea nu este
închisă, sistemul garantează consistenţă „read-your-writes”.
Dacă sesiunea este terminată din cauza unui motiv oarecare, o
nouă sesiune va fi creată, dar nu există garanţii ca cea de a
doua sesiune va continua perfect activitatea primei sesiuni.
Consistenţă monotonică la citire. Dacă un proces a
obţinut la o interogare cel puţin o dată valoarea modificată,
nicio interogare ulterioară nu va mai returna valoarea
nemodificată.
Consistenţă monotonică la scriere. Sistemul
garantează serializarea modificărilor făcute de un proces. Este
un nivel minim de consistenţă necesar pentru a putea crea cod
care să nu depăşească anumite limite de complexitate.
11
Mulţumiri
Adresez mulţumirile cuvenite colegilor mei din cadrul

colectivului Departamentului Cibernetică, Informatică
Economică, Finanţe şi Contabilitate din cadrul Facultăţii de
Ştiinţe Economice, Universitatea Petrol-Gaze din Ploieşti, în
mod special d-rei Conf. Dr. Ec. Ana Tănăsescu, d-nei Conf. Dr.
Ing. Aurelia Pătraşcu şi d-lui Conf. Dr. Ing. Dorel Duşmănescu
pentru tot ajutorul, observaţiile şi recomandările utile oferite.
Dedic cu drag această carte soţiei mele, căreia îi
mulţumesc călduros pentru ajutorul, înţelegerea, răbdarea şi
încurajările pe care mi le-a acordat.
12
Partea întâi – trecut și prezent în Big Data
1 Aspecte privind modalitățile de structurare a

volumelor mari de date
1.1 Organizarea structurată a volumelor mari de

date. Baze de date relaționale. Depozite de date
De regulă, volumele cele mai mari de date pot fi

regăsite în baze de date (deşi există şi destul de multe excepţii
de la această afirmaţie). Din acest motiv, este interesant de
analizat care este poziţia celor mai mari competitori din
domeniul bazelor de date relaţionale (Oracle, IBM, Microsoft)
în legătură cu acest subiect şi care sunt soluţiile găsite de
aceştia.
1.1.1 Baze de date relaţionale
Consideraţii generale
În ultima perioadă, peste 86% din totalul veniturilor

obţinute din vânzarea de sisteme de gestiune a bazelor de date
(SGBD), la nivel mondial, au fost încasate doar de trei
producători. Potrivit unui studiu publicat recent de compania
Gartner, IBM a înregistrat 35,7% din totalul veniturilor, Oracle
32,6%, iar Microsoft 18,1%.
13
DB2 şi Oracle au oferit îmbunătăţiri majore în zona de

administrare şi de disponibilitate. Ambele au adăugat facilităţi
semnificative în gestionarea mediilor de date complexe şi în
automatizarea activităţilor de administrare de complexitate
ridicată. În timp ce SQL Server a fost perceput ca fiind cel mai
uşor de gestionat pentru baze de date mici şi mijlocii, DB2 este
cel mai utilizat pentru gestiunea bazelor de date de dimensiuni
medii şi mari, fiind urmat de Oracle.
În domeniul administrării transferurilor de date, atât
IBM (cu utilitarul Overloading), cât şi Oracle (cu Data Pump)
oferă facilităţi sporite prin produsele lor, producătorul Oracle
conducând, totuşi, datorită avantajelor de neegalat în partea de
management.
În zona întreruperilor neplanificate, Oracle şi DB2 sunt
la egalitate. Noua implementare DB2 egalează performanţele
oferite de Data Guard-ul Oracle. În timp ce Oracle oferă funcţii
suplimentare în zona de undo a managementului, abilitățile
DB2 de cluster failover par să fie avantajoase pentru mediile
care utilizează Business Intelligence (BI).
SQL Server este perceput ca un produs foarte uşor de
utilizat care se integrează foarte bine în platforma Windows. În
trecut, SQL Server era considerat a fi, la scară mică, în mod
clar, uneori instabil şi nefuncţional şi nu la fel de bogat ca alte
SGBD de vârf. În acelaşi timp, SQL Server se integrează bine
în instrumentele pentru dezvoltarea de aplicaţii bazate pe
standarde Windows, dar nu are nivelul de integrare al celorlalte
SGBD în alte sisteme de operare. Microsoft a încorporat
instrumente de bază de Business Intelligence care tind să fie
adoptate foarte bine la integrarea în mediul tipic Windows. Cu
14
toate acestea, capacitatea de a executa operaţii de BI într-un

mediu trebuie să fie privită şi din perspectiva scalabilităţii şi
performanţei. Chiar dacă în trecut SQL Server a condus la
unele criterii de referinţă în procesul de prelucrare OTLP,
aceasta încă nu reuşeşte să răspundă cerinţelor pe scară largă
ale aplicaţiilor bazate pe interogarea intensivă a unor volume
foarte mari de date, specifice BI. Cu toate acestea, datorită
complexităţii de ansamblu moderate, precum şi a unui nivel de
autonomie impresionant, SQL Server oferă suport foarte bun
pentru mediile care îl folosesc - aplicaţii mici şi mijlocii pe
platforma Windows.
În timp ce extensiile pentru modelul relaţional nu sunt
foarte vizibile la SQL Server, Oracle şi DB2 au stabilit o serie
de caracteristici obiect-relaţional în produsele lor şi par să
asigure un suport bun pentru managementul de conţinut şi
extensii în baza de date. În contrast cu politica Oracle de
integrare a tuturor tipurilor de date în baza de date Oracle, DB2
permite integrarea informaţiilor atât din interiorul, cât şi din
afara lumii native DB2. Prin această strategie, DB2 poate servi
ca punct de acces unic la datele întreprinderii. SQL Server
urmează o politică de utilizare a middleware-lui pentru
integrarea surselor de date eterogene, spre deosebire de Oracle
care utilizează strategia "integrează totul în baza de date". În
contrast cu acestea, filosofia DB2 este de a fi o „fereastra către
informaţii din întreprindere", preluând responsabilitatea pentru
accesul eficient la date, indiferent de sursa de informaţie. DB2
oferă un maximum de flexibilitate atunci când este vorba de
extinderea bazei de date şi / sau de integrarea diferitelor tipuri
de surse de informaţii.
15
În zona de management al securităţii, Oracle acceptă

anumite caracteristici care implică autentificare, în principal, în
timp ce produsele SGBD concurente se bazează pe funcţii
oferite de stratul de aplicaţie sau de sistem de operare. Astfel,
Oracle oferă o caracteristică de securitate de neegalat de către
DB2 şi SQL Server, prin sistemul de etichete.
DB2 oferă o arhitectură reproiectată bazată pe plug-in-
uri în sprijinul integrării mecanismelor de autorizare
individuală. DB2 poate fi considerat ca lider global pentru
aplicaţii pe scară largă de Business Intelligence şi, datorită
ofertelor sale extinse de caracteristici, are un nivel destul de
ridicat de complexitate. Totuşi, DB2 a atins un echilibru bun
între această complexitate şi simplitatea administrării bazată pe
o arhitectură de ansamblu bine pusă în aplicare, pe baza
caracteristicilor autonome.
Scalabilitatea
Scalabilitatea este capacitatea unui SGBD de a se

adapta la cerinţe crescute în ceea ce priveşte numărul de
utilizatori, volumul de date, volumul şi complexitatea
tranzacţiilor.
Atunci când o bază de date a fost proiectată pentru a fi
scalabilă, scalarea trebuie să nu afecteze structura aplicaţiilor şi
să nu ducă la schimbări în codul sau orarul aplicaţiilor, adică să
rămână atât de transparentă pe cât este posibil. Scalabilitatea ar
trebui să fie granulară, însemnând că scalarea se va putea face
în paşi mici, spre exemplu pornind de la un sistem Windows pe
o maşină cu un singur procesor să se poată ajunge oricând,
gradat sau nu, la o maşină UNIX multiprocesor, la 64 de biţi,
16
fără ca aplicaţiile să sufere vreun efect vizibil. O altă variantă

de evoluţie ar fi începerea activităţii cu un server Linux de
mică capacitate sau poate un server blade Linux şi creşterea
ulterioară a capacităţii prin adăugarea altor blade-uri sau alte
servere independente.
Creşterea volumului de prelucrări este de cele mai
multe ori cauzată de factori de afacere. Spre exemplu, odată ce
o afacere electronică creşte în volum, va trebui crescută
performanţa infrastructurii pentru a face faţă încărcării
adiţionale. Aplicaţiile de Business Intelligence de multe ori vor
necesita şi ele scalări din pricina creşterii volumelor de date
prin colectarea datelor istorice din diferite surse. În general,
scalabilitatea este necesară pe măsura creşterii afacerii în timp,
cel puţin pentru a asigura investiţiile făcute în aplicaţii. Pentru
a se adapta la volume crescute de lucru, o organizaţie ar trebui
să considere înlocuirea sau modificarea hardware-ului,
sistemului de operare, precum şi a configuraţiei sau structurii
bazei de date.
Factorii care afectează scalabilitatea pot să difere în
funcţie de tipul de aplicaţie. Sistemele OLTP necesită alte
facilităţi ale SGBD decât aplicaţiile de BI pentru a atinge
scalabilitatea. Pe de o parte, creşterea puterii pe latura de
interogări de BI înseamnă creşterea paralelismului în interiorul
procesului de interogare (realizabil prin folosirea de noduri
adiţionale sau cu ajutorul paralelismului inter-partiţii). Pe de
altă parte, creşterea numărului de „tranzacţii pe minut” – o
exprimare eufemistică pentru performanţa unei baze de date –
într-un sistem OLTP implică, în principal, un număr crescut de
17
procesoare pentru a executa mai multe tranzacţii în acelaşi timp

(paralelism între interogări).
De asemenea, o distribuţie eficientă a datelor care să
favorizeze scalabilitatea înseamnă un lucru diferit, depinzând
de aplicaţie. Pentru BI, se doreşte obţinerea unui echilibru
optim al partiţiilor de date care să asigure un paralelism avansat
în interogare. În acelaşi timp, la OLTP scalabilitatea implică
obţinerea unui timp optim pentru citire şi scriere la accesarea
înregistrărilor individuale, în condiţiile unei concurenţe
crescute, datorate numărului de tranzacţii în creştere.
La căutarea unei arhitecturi optime pentru cerinţele
tranzacţionale ale unei organizaţii, pot apărea diferite
alternative ca fiind atractive. Într-o prima fază, distribuţia task-
urilor către diversele procesoare este efectuată de către sistemul
de operare.
La rândul lui, SGBD poate asigura paralelismul prin
generarea de sub-task-uri pe care sistemul de operare să le
poată distribui. În acest sens, trebuie luată în considerare
utilizarea, individual sau în combinaţie, a Multi Procesării
Simetrice (MPS; multiprocesarea simetrică se referă la
utilizarea unui singur nod de procesare care conţine, la rândul
lui, mai multe procesoare) sau a Procesării Masiv Paralele
(PMP; procesarea masiv paralelă se referă la utilizarea mai
multor noduri, combinate într-un cluster care să execute
funcțiile unui nod individual, din punctul de vedere al
aplicaţiei).
Implementările SGBD bazate pe clustere PMP trebuie
să aibă la bază una dintre tehnologiile de partajare a datelor
cunoscute - Shared-Nothing (în care toate resursele sunt
18
administrate individual de către noduri) sau Shared-Disk (în

care resursele de stocare sunt administrate centralizat şi
partajate între toate nodurile).
Fiecare dintre cele două tehnologii are propriile
avantaje şi dezavantaje care trebuie evaluate în funcţie de tipul
de aplicaţie care trebuie rulat. Atunci când se alege soluţia
utilizării clusterelor şi a PMP, trebuie luate în calcul costurile
adiţionale şi creşterea complexităţii administrării. În cele mai
multe cazuri, o soluţie MPS este cea mai potrivită pentru
cerinţele OLTP, deşi este limitată la utilizarea unui singur
server. În acest caz, scalarea pentru un volum mai mare de
tranzacţii implică, în principal, adăugarea de procesoare şi de
memorie maşinii de calcul utilizate. În acelaşi timp,
implementările PMP bazate pe clustere sunt mai potrivite, de
obicei, pentru interogările complexe utilizate de mediile BI. În
acest caz, scalarea pentru obţinerea unui paralelism mai ridicat
sau a unor volume de date mai mari va fi o operaţiune mai
complexă.
Toate cele trei SGBD analizate oferă răspunsuri la
problema scalabilităţii. Paralelismul de tip MPS este asigurat
de toate cele trei SGBD. De asemenea, numai două dintre ele
(DB2, cu o arhitectură de tip Shared-Nothing şi Oracle, cu o
arhitectură de tip Shared-Disk) folosesc, în mod vizibil,
arhitecturi de tip PMP. SQL Server foloseşte o formă derivată a
acestei arhitecturi – bazele de date federalizate. Aceasta
presupune implementarea unui cvasi-cluster în care bazele de
date sunt slab clusterizate. Atât Oracle, cât şi DB2 acceptă
acelaşi strat superior peste structura cluster (utilizarea
viziunilor de tip UNION-ALL).
19
Dacă utilizatorul exploatează abilitatea SGBD folosit

pentru a partiţiona datele, obţine în acest mod creşterea
paralelizării aplicaţiilor. Partiţionarea datelor permite, în
continuare, distribuirea lor fizică, astfel încât paralelismul este
crescut, este sporită performanţa şi, în anumite cazuri, este
maximizată concurenţa. Alegerea unei strategii de partiţionare
va fi determinată de încărcarea prevăzută. Este vorba fie de o
tactică îndreptată către optimizarea intra-interogare, fie de una
îndreptată către optimizarea inter-interogări. Tacticile intra-
interogare implică distribuirea optimă a datelor pentru a realiza
interogări înalt paralelizate, precum sunt cele din aplicaţiile de
BI. Tacticile inter-interogare utilizează distribuţii grupate ale
datelor bazate pe prioritate, în acest mod obţinându-se
autonomia partiţiilor. De obicei, această tehnică este folosită
pentru aplicaţiile OLTP, deşi are anumite aplicaţii şi în
domeniul BI.
Atunci când SGBD este SQL Server, efectul de
partiţionare poate fi obţinut numai prin utilizarea unei tehnici
mediate de utilizator. Acesta trebuie să definească baze de date
federalizate pentru ca datele să fie distribuite pe baza valorii.
Din nefericire acest lucru duce la consumul suplimentar de
timp prin utilizarea OLE DB API (pentru acces la distanţă). De
asemenea, trebuie acordată atenţie acelor interogări care
limitează procesarea la un singur nod. Mai mult de atât,
managementul instanţelor de bază de date este complicat.
Schimbări în aspectul bazei de date necesită modificări ale
viziunilor „union-all” utilizate pentru directarea şi
administrarea bazelor de date federalizate şi acest lucru s-ar
putea să nu fie transparent pentru aplicaţie. Deşi SQL Server
20
acceptă stocarea relaţională pentru OLAP, nu este oferită nicio

metodă specifică de clustering. Cu toate acestea, un cub
(relaţional, multidimensional sau hibrid) poate fi partiţionat
logic, de exemplu pe dimensiunea timp. Partiţiile individuale
pot fi stocate pe un server la distanţă, ceea ce duce la
distribuirea agregatelor, cu sau fără datele sursă, depinzând de
tipul de stocare (ROLAP, MOLAP sau HOLAP). Din acest
motiv, atunci când se adaugă un hardware mai performant la un
server MS SQL, este posibil să se obţină o granularitate foarte
bună (deşi există în continuare restricţionarea referitoare la
utilizarea acelui hardware acceptat de SO Windows).
Atât DB2, cât şi Oracle asigură partiţionarea fizică a
datelor pentru utilizarea implementărilor MPS sau PMP.
Opţiunea de partiţionare a Oracle oferă posibilitatea de
a crea partiţii pe bază de domeniu, de liste, de valori hash sau
pe criterii compozite. În timp ce partiţionările pe bază de liste
sau domenii pot influenţa pozitiv bazele de date de tip OLTP
cu volume mari de date, precum şi interogările bazate pe
domeniu sau operaţiile roll-in/roll-out (cum ar fi: adăugarea de
date pentru luni noi sau ştergerea de date pentru luni mai
vechi), partiţionarea hash creşte paralelismul pentru interogări
complexe sau volume mari de date. Prin utilizarea unei
partiţionări compozite, se pot combina tehnici bazate pe
domeniu cu cele bazate pe liste sau valori hash. De asemenea,
este disponibilă şi posibilitatea de a partiţiona datele stocate cu
opţiunea OLAP, activând paralelismul şi permiţând o mai bună
utilizare a resurselor hardware în raport cu seturile de date
multi-dimensionale.
21
DB2 utilizează tehnologia numită Clustering Multi

Dimensional (MDC; tehnologia MDC a fost aleasă pentru a
rezolva problema lipsei mecanismelor de blocare hardware -
cum este facilitatea de cuplare de OS/390 - din mediile Linux,
UNIX şi Windows) care permite ordonarea fizică a datelor ca
suport pentru căutările în domeniu. MDC permite unei tabele
să fie clusterizate simultan după mai mult de o cheie sau
dimensiune. În plus, MDC introduce indecşi bazaţi pe blocuri
care permit regăsirea de grupuri de înregistrări (în locul
înregistrărilor individuale pentru indecşii clasici). Aceştia
elimină dezavantajele indexării clusterelor şi furnizează
beneficii de performanţă datorită dimensiunii lor, mult mai
mici decât a indecşilor clasici.
O tabelă MDC permite şi asigură clusterizarea după
toate dimensiunile, în mod automat şi continuu. Acest lucru
elimină necesitatea de reorganizare şi furnizează avantaje de
performanţă şi uşurinţă în management similare sau mai bune
cu cele bazate pe partiţionare din Oracle. De asemenea, în DB2
pot fi implementate partiţionări bazate pe liste sau domenii prin
tabele separate fizic, cuplate slab prin vizualizări UNION ALL.
Scopul principal al arhitecturii Shared-Nothing din DB2
(pentru clustere PMP) este să permită în mod eficient unei baze
de date să crească dincolo de capabilităţile unui singur server.
În combinaţie, o arhitectură de tip MPS permite scalarea
lineară prin adoptarea unui server individual de mare putere
care să profite de arhitectura Shared-Nothing.
Clusterele PMP sunt utilizate, în mod tipic, pentru
execuţia de interogări complexe pe volume mari de date,
specifice sistemelor suport de decizie. Facilitatea DB2 DPF
22
(Facilitate de Partiţionare Distribuită) utilizează un algoritm

hash pentru distribuirea datelor în partiţii. Administratorul
bazei de date (DBA) este responsabil pentru definirea cheii de
partiţionare, dar SGBD se ocupă cu distribuirea fizică a
înregistrărilor individuale. În general acest mecanism
generează o distribuţie egală a datelor fizice, cu excepţia
cazului în care se aplică pe date colocate. O uniune aplicată pe
tabele mari necesită comunicaţie între partiţii (uzual prin
TCP/IP) (“Colocarea este mutarea înregistrărilor din tabele
diferite care conţin date relaţionate într-o partiţie comună a
bazei de date. … Tabelele sunt considerate a fi colocate dacă
ele sunt stocate într-un grup de partiţii al unei baze de date, au
acelaşi număr de coloane în cheia de partiţionare şi tipurile de
date din coloanele corespunzătoare sunt compatibile în partiţie.
Înregistrările din tabelele colocate care au aceiaşi valoare a
cheii de partiţionare sunt stocate în aceeaşi partiţie.”) (IBM,
2009).
Deseori, redundanţa transpartiţie (cu tabelele replicate
bazate pe tehnologia DB2 Materialized Query Tables - MQT)
este utilizată pentru a reduce traficul inter-partiţii pentru
tabelele de tip lookup. Uneori hash-ingul poate intra în conflict
cu cerinţele de secvenţiere sau de ordine de sortare pentru
aplicaţii pre-construite asamblate. La utilizarea DB2 DPF,
DBA trebuie să depună un efort suplimentar pentru
administrarea partiţiilor individuale, deşi multe activităţi pot fi
executate dintr-o partiţie centrală. Mai mult de atât, DB2
Design Advisor oferă asistenţă în proiectarea unei partiţionări
optimale, bazate pe încărcare. Şi arhitectura DB2 oferă
23
granularitate foarte fină la extindere, datorită abilităţii sale de a

rula pe diverse combinaţii de hardware şi sisteme de operare.
Oracle Real Application Clusters (RAC) asigură
sincronizarea accesului la date şi modificări inter-nod (în mod
tipic cu ajutorul unei arhitecturi de tip Shared-Disk). RAC este
necesar atunci când se impune o arhitectură de tip PMP într-un
mediu clusterizat sau atunci când se solicită o disponibilitate
ridicată.
În cazul tranzacţiilor de tip read/write, comunicarea
inter-nod pentru blocarea înregistrărilor poate afecta
scalabilitatea. Acesta este motivul principal pentru care Oracle
Parallel Server (OPS) a fost rescris pentru noua arhitectură
RAC. Totuşi, Oracle continuă să recomande utilizarea unui
hardware omogen în configuraţia clusterelor şi indică utilizarea
configuraţiilor care au fost certificate pentru utilizarea bazelor
de date RAC.
Într-un mediu OLTP cu un număr mare de tranzacţii,
timpul suplimentar de sistem se poate reduce prin aplicarea
partiţionării. Însă, acest lucru poate duce la apariţia unor
costuri de reproiectare a bazei de date şi a aplicaţiei atunci când
se doreşte scalarea la cerinţe mai mari.
Din acest motiv, de cele mai multe ori o decizie pentru
adoptarea RAC are la bază cerinţe de înaltă disponibilitate şi nu
de scalabilitate. RAC nu furnizează scalabilitate (aproape)
liniară – experienţe practice au arătat o descreștere a sporului
de performanţă la adăugarea de noduri suplimentare la cluster
(de exemplu: un al doilea nod adaugă 80% putere, un al
patrulea adaugă 51%, iar un al optulea numai 21%).
24
Opţiunile de partiţionare oferite de Oracle suportă atât

OLTP, cât şi BI, iar clusterele RAC sunt utilizate, în principal,
pentru a furniza înaltă disponibilitate. De asemenea, DB2
scalează foarte bine în aplicaţiile OLTP bazate pe arhitecturi
MPS. Pe partea de BI, clusterele DB2 bazate pe tehnologia
Shared-Nothing sunt utilizate predominant pentru depozite de
date de mari dimensiuni.
Este de reţinut faptul că niciuna dintre funcțiile
avansate ale SGBD descrise anterior nu elimină obligaţia DBA
de a-şi fundamenta atent deciziile cu privire la crearea şi
modificarea structurii bazei de date, în conformitate cu
necesităţile impuse de aplicaţie. Mai trebuie menţionat faptul
că sistemele de tip cluster implică unele costuri suplimentare
de proiectare şi administrare, faţă de sistemele de tip MPS.
Acest lucru este contrabalansat de costul uzual mai mare al
sistemelor MPS şi de faptul că vârfurile, atât de performanţă,
cât şi de scalabilitate, nu sunt atinse decât de sisteme de tip
PMP sau hibride.
În continuare vor fi prezentate facilităţile oferite de cele
mai importante SGBD actuale care au capabilități de lucru
distribuit (sau de clusterizare).
Oracle Database şi Real Application Cluster
Oracle Real Application Clusters este o opţiune pentru

Oracle Database Enterprise Edition care a fost introdusă
începând cu versiunea Oracle 9i.
Oracle Real Application Clusters este o componentă
cheie a Oracle Maximum Availability Architecture (MAA)
25
care este pachetul Oracle de extensii pentru asigurarea de

disponibilitate ridicată.
Arhitectura Oracle Real Application Clusters

O bază de date RAC este o bază de date clusterizată
(Figura 1). Server Pools furnizează rezilienţă crescută şi
creştere modulară incrementală a sistemului.
Figura 1 – Arhitectura Oracle Real Application Clusters
Oracle Real Application Clusters decuplează instanţa

Oracle (procesul şi memoria aferentă acestuia care rulează pe
server şi permite accesul la date) de baza de date Oracle
(structura fizică rezidentă pe echipamentul de stocare). O bază
de date clusterizată este o bază de date unică ce poate fi
accesată de multiple instanţe, fiecare rulând pe un server
separat din Server Pool. Atunci când sunt necesare resurse
26
suplimentare, pot fi adăugate la Server Pool servere şi instanţe,

chiar în timpul funcţionării. Odată ce noile instanţe pornesc,
aplicaţiile existente pot apela imediat aceste instanţe, fără nicio
modificare în aplicaţie sau în serverul de aplicaţii (Abramson,
2004).
Oracle Clusterware
Începând de la versiunea Oracle Database 10g, Oracle
furnizează Oracle Clusterware (Figura 2), o soluţie portabilă de
clusterizare integrată şi proiectată specific pentru Oracle
Database. Oracle Clusterware oferă o soluţie completă de
clusterizare şi acceptă orice aplicaţii proiectate pentru Oracle
10g. Instalarea Oracle Clusterware trebuie să premeargă
oricărei implementări Oracle RAC (deşi există şi terţe soluţii
care suportă Oracle RAC, chiar şi în prezenţa acestora, Oracle
Clusterware este, încă, utilizat ca interfaţă de administrare).
Oracle Clusterware monitorizează şi administrează bazele de
date Oracle Real Application Cluster. Atunci când un server
din Server Pool este pornit, toate instanţele, listenerii şi
serviciile pentru acesta sunt automat pornite. Dacă o instanţă
eşuează, Oracle Clusterware va restarta automat instanţa astfel
încât serviciul să fie restaurat încă înainte de anunţarea
administratorului bazei de date.
Odată cu Oracle Database 10g Release 2, Oracle a
adăugat la produsele sale şi un API de înaltă disponibilitate
(High Availability API) astfel ca aplicaţiile non-Oracle să
poată fi administrate prin framework-ul de disponibilitate
ridicată furnizat de Oracle Clusterware.
27
Prin acest API, orice aplicaţie care se înregistrează în

Oracle Clusterware trebuie să furnizeze informaţii despre cum
poate fi pornit, oprit şi monitorizat procesul său. În plus, se pot
specifica servere candidat care să ia locul serverului activ
pentru furnizarea unei anumite resurse în cazul apariţiei unei
probleme.
Figura 2 – Vedere de ansamblu asupra Oracle Clusterware
Microsoft SQL Server şi Azure
Microsoft SQL Azure Database este o bază de date de

disponibilitate ridicată, scalabilă şi capabilă de construcţia unui
sistem cloud. Disponibilitatea ridicată şi toleranţa la defecte
sunt implicite şi nu este necesară nicio formă de administrare
fizică pentru asigurarea acestor facilităţi. În plus, este
disponibil şi modelul relaţional T-SQL, cu care dezvoltatorii
sunt deja familiarizaţi, împreună cu toate uneltele uzuale de
dezvoltare şi management (Microsoft, 2013).
28
Microsoft Azure poate fi utilizat pentru construcţia

rapidă şi eficientă de sisteme şi aplicaţii Software as a Service.
Printre caracteristicile Microsoft Azure se numără
următoarele:
 nu este necesară administrarea fizică – platforma pe
care se bazează este virtualizată sub formă de
Platform as a Service (PAAS);
 are disponibilitate ridicată şi o toleranţă bună la
defecte;
 furnizează şi instalează facil baze de date multiple;
 bazele de date pot fi scalate în sus şi în jos după
necesităţile afacerii;
 pot fi furnizate servicii către multiple organizaţii;
 este integrat cu SQL Server şi diverse unelte
,incluzând Visual Studio;
 utilizează modelul relaţional de bază de date T-
SQL;
 se poate opta pentru facturare pay-as-you-go.
În continuare sunt enunţate facilităţile oferite de
Microsoft Azure:
 este un sistem de gestiune a bazelor de date
relaţional:
o pot fi create, accesate şi manipulate tabele,
vizualizări, indecşi, roluri, proceduri stocate,
declanşatoare şi funcţii;
o pot fi executate interogări şi uniuni
complexe peste multiple tabele;
o sunt disponibile opţiunile Insert, Update şi
Delete;
29
o sunt disponibile constrângeri;

o sunt posibile tranzacţiile;
o este posibilă construcţia tabelelor temporare;
o sunt utilizabile funcţiile de bază (funcţii de
agregare, funcţii matematice, funcţii de
prelucrare a şirurilor de caractere, funcţii de
lucru cu data / timpul);
o este inclus un subset al sistemului de
proceduri stocate şi vizualizări de sistem din
SQL Server;
o sunt disponibile statistici şi informaţii pentru
facturarea serviciilor şi analize istorice.
 programabilitate:
o acces administrat la date prin ADO.NET;
o conexiune ODBC nativă;
o suport pentru PHP;
o suport pentru JDBC.
 unelte integrate:
o furnizarea de servere logice şi baze de date
prin portalul de management al conturilor
SQL Azure Database, portal care include o
unealtă web de management al bazelor de
date;
o SQL Server Management Studio: un mediu
integrat conţinând unelte grafice pentru
accesarea şi configurarea bazelor de date
SQL Server şi SQL Azure databases
(disponibil în variante pe 32 şi 64 de biţi);
30
o Visual Studio 2010 asigură crearea de

aplicaţii cu conexiuni de date la SQL Azure,
permiţând dezvoltatorilor să includă
interogări, să manipuleze date şi să efectueze
operaţiuni de legare a datelor în aplicaţiile
din mediul Visual Studio;
o în plus, un număr de unelte permit facilitarea
unor activităţi cum ar fi mutarea şi migrarea
datelor, instalare şi administrare în linie de
comandă.
Facilităţi anunţate - SQL Azure Data Sync
SQL Azure Data Sync care se află în prezent în stadiul

Community Technology Preview (CTP) (Microsoft, 2013) este
un serviciu de sincronizare a datelor bazat pe cloud construit cu
ajutorul tehnologiilor Microsoft Sync Framework. Acest
serviciu furnizează sincronizare bidirecţională şi capabilităţi de
managementul datelor, permiţând ca datele să fie distribuite
uşor între multiple baze de date SQL Azure, dar şi între baze de
date localizate şi baze de date SQL Azure.
Facilităţile oferite de SQL Azure Data Sync sunt:
 scalare elastică – serviciile sunt scalate pe măsură ce
cresc necesităţile de resurse;
 configuraţia de sincronizare nu necesită cod – se pot
specifica uşor datele care urmează a fi sincronizate
cu unelte intuitive;
 programarea sincronizării – se poate alege cât de
des să fie sincronizate datele;
31
 administrarea conflictelor – cazurile în care aceleaşi

date sunt modificate în multiple locaţii;
 jurnalizare şi monitorizare – capabilităţi
administrative de urmărire a datelor şi monitorizarea
potenţialelor probleme;
 crearea de sub-seturi de date – selecţia tabelelor care
vor fi sincronizate între bazele de date SQL Azure.
IBM DB2 şi Distributed Relational Database

Architecture
Distributed Relational Database Architecture (DRDA)

este un set de protocoale care permite ca sisteme de baze de
date multiple, atât IBM cât şi ne-IBM, împreună cu aplicaţii, să
lucreze împreună. Orice combinaţie de produse de management
de baze de date relaţionale care utilizează DRDA pot fi
conectate pentru a forma un sistem distribuit de management
de baze de date relaţionale. DRDA coordonează comunicaţia
între sisteme prin definirea a ceea ce urmează să fie
interschimbat, precum şi a modalităţii de realizare a acestui
lucru (IBM, 2012).
Unitate de lucru
O unitate de lucru (UOW – Unit of Work) este o
singură tranzacţie logică care este alcătuită dintr-o secvenţă de
declaraţii în care fie toate operaţiile sunt îndeplinite cu succes,
fie întreaga secvenţă ca întreg este considerată eşuată.
32
O unitate de lucru distribuită (DUOW – Distributed

Unit of Work), de asemenea cunoscută şi ca actualizare
multisite, este o unitate de lucru care implică mai mult de un
singur server. O DUOW are următoarele caracteristici:
 în timpul unei DUOW sunt actualizate mai multe
servere de management al bazelor de date;
 aplicaţia conduce distribuţia activităţii şi
iniţializează comiterea;
 o DUOW poate conţine mai multe cereri;
 fiecare cerere apelează un server de management al
bazelor de date;
 comiterea este coordonată la scara setului de
servere.
Deşi DRDA defineşte protocoalele de comunicaţii
pentru baze de date, nu conţine şi definirea unor interfeţe de
programare sau API-uri care ar trebui utilizate de dezvoltatorii
de aplicaţii. În general, DRDA poate fi utilizată de un program
de aplicaţii pentru a redirecţiona corespunzător orice cerere pe
care un server din compunerea DRDA o poate executa. Toate
serverele DRDA disponibile la momentul actual pot executa
cererile SQL trimise de programele de aplicaţii prin tehnologia
DB2 Connect.
IBM furnizează programatorilor de aplicaţii unelte
pentru sistemele de operare Windows, UNIX şi Linux. Aceste
unelte compun clientul DB2. Managerul de baze de date DB2
acceptă următoarele interfeţe de programare: ADO.NET,
JDBC, SQLJ, PHP, Perl DBI, embedded SQL, DB2 Call Level
Interface şi OLE DB. Aceste API-uri pot fi utilizate de
33
programatori pentru a construi aplicaţii cu ajutorul unor

limbaje de programare variate.
DB2 Connect implementează arhitectura DRDA pentru
a reduce costul şi complexitatea accesării datelor stocate în
IBM DB2 pentru IBM i, DB2 pentru IBM Power Systems,
DB2 pentru z/OS, DB2 Server pentru VM şi VSE şi alte
servere de baze de date compatibile DRDA. Prin completa
exploatare a arhitecturii DRDA, DB2 Connect oferă o soluţie
de cost scăzut, conţinând acele caracteristici de management de
sistem pe care le cer clienţii.
În terminologia DRDA, un apelant de aplicaţii
(Application Requester - AR) este codul care se ocupă de
partea din aplicaţie aflată la capătul conexiunii distribuite,
adică aceea care solicită date. DB2 Connect acţionează ca un
AR în numele aplicaţiilor care pot fi localizate pe o staţie de
lucru DB2 sau pe o maşină client aflată la distanţă de DB2
Connect. Un server de aplicaţii (Application Server - AS) este
codul care se ocupă de celălalt capăt al conexiunii, cel la care
se află baza de date.
De asemenea, DRDA realizează conexiuni multi-nivel
între un AR şi un server. În această topologie, serverul la care
se conectează direct un AR este un AS, iar toate celelalte
servere sunt numite servere de baze de date (Database Server –
DS) şi nu interacţionează direct cu AR. În plus, pentru a
sublinia faptul că un anumit server nu are nici rol de AS, nici
rol de DS, dar îndeplineşte un anumit rol în sistem, acesta este
numit server intermediar (intermediate server – IS). Toate
aceste roluri sunt recunoscute de DB2 Connect (Figura 3
înfăţişează traseul pe care îl urmează datele între staţia de lucru
34
DB2 Connect şi serverul IBM în cazul în care se lucrează

numai cu clienţi locali).
Staţie de lucru DB Connect Gazdă sau server IBM i DB2
Server de aplicaţii
Program de aplicaţie
Protocolul DRDA DRDA
Solicitant de aplicaţie Sistem de gestiune a
DRDA bazelor de date
Figura 3 – Comunicaţia de date între staţia de lucru DB2 Connect şi

serverul IBM
Pentru implementarea conexiunilor între SGBD, server

DRDA şi clienţii de server de date IBM, DRDA utilizează
următoarele arhitecturi:
 Character Data Representation Architecture
(CDRA);
 Distributed Data Management Architecture (DDM);
 Formatted Data Object Content Architecture
(FD:OCA);
 Transmission Control Protocol/Internet Protocol
(TCP⁄IP).
Aceste arhitecturi servesc ca elemente constructive.
Stream-urile de date care parcurg reţeaua sunt specificate de
arhitectura DRDA care documentează un protocol de stream de
date care asigură acces distribuit la baze de date relaţionale.
O cerere este direcţionată către destinaţia corectă prin
intermediul unor directoare care conţin diverse tipuri de
informaţii de comunicaţii, dar şi numele serverului de baze de
date DRDA care este accesat.
35
O unitate de lucru la distanţă (remote unit of work –

RUOW) permite utilizatorilor şi aplicaţiilor să modifice date
dintr-o singură locaţie. O astfel de unitate asigură accesul la o
singură bază de date. Astfel, în timp ce un program poate
modifica date din mai multe baze de date aflate la distanţă,
fiecare dintre aceste baze de date va fi apelată prin intermediul
unui RUOW diferit.
RUOW au următoarele caracteristici:
 sunt realizate multiple cereri (declaraţii SQL) în
fiecare RUOW;
 sunt utilizate multiple cursoare în fiecare RUOW;
 fiecare RUOW nu poate actualiza decât o singură
bază de date;
 programul de aplicaţii fie finalizează modificările
efectuate, fie anulează RUOW în întregime. În
anumite circumstanţe, anularea poate fi făcută şi de
către DB2 Connect.
Aplicaţia trebuie să realizeze următoarele:
 acceptă sumă de transferat din interfaţa client;
 scade suma din contul depozit şi determină noua
balanţă a contului;
 citeşte programarea taxelor de tranzacţie pentru a
determina care este taxa care va fi aplicată;
 scade taxa din cont;
 adaugă suma la contul de plată;
 finalizează tranzacţia (RUOW).
Modul de lucru cu RUOW este explicat prin
intermediul diagramei din Figura 4 în care se prezintă un client
de bază de date care rulează o aplicaţie de transfer al fondurilor
36
conţinând tabele de plăţi şi de depozite, precum şi o

programare a taxelor de tranzacţie.
Figura 4 – Utilizarea unei singure baze de date într-o tranzacţie.
O cerere distribuită este o funcţie a unei baze de date

distribuite care permite aplicaţiilor şi utilizatorilor să trimită
declaraţii SQL care apelează două sau mai multe SGBD într-o
singură declaraţie. Spre exemplu poate fi făcută o uniune între
tabele din două subsisteme DB2 pentru z/OS.
DB2 Connect permite realizarea de cereri distribuite
peste un număr oarecare de baze de date şi SGBD. De
exemplu, este posibilă o uniune între un tabel DB2 şi o
vizualizare Oracle. SGBD acceptate sunt reprezentate de
membrii familiei DB2 (cum ar fi: DB2 Database pentru Linux,
UNIX şi Windows, DB2 pentru z/OS şi DB2 pentru i) şi
Oracle. Este disponibil suport multivendor atunci când se
utilizează DB2 Connect în conjuncţie cu InfoSphereFederation
Server.
Cererile distribuite oferă transparenţa locaţiei pentru
obiecte de baze de date. Dacă informaţiile (din tabele şi
vizualizări) sunt mutate, referinţele la acele informaţii (numite
nickname-uri) pot fi actualizate fără să fie necesară nicio
37
modificare în aplicaţiile care solicită acele informaţii. De

asemenea, cererile distribuite sunt utile în cazul SGBD care nu
recunosc toate dialectele DB2 SQL sau anumite capabilităţi de
optimizare. Operaţiile care nu pot fi executate într-un astfel de
SGBD (spre exemplu declaraţiile SQL recursive) pot fi rulate
în DB2 Connect.
Cererile distribuite funcţionează într-o manieră
autonomă. Spre exemplu, o interogare DB2 care conţine
referinţe la obiecte Oracle poate fi trimisă, în timp ce aplicaţii
Oracle accesează acelaşi server. Cererile distribuite nu
monopolizează şi nu restrâng accesul (dincolo de restricţiile de
integritate şi blocare) la obiecte Oracle sau din alte SGBD.
Implementarea funcţionării cererilor distribuite constă
într-o instanţă DB2 Connect, o bază de date care va servi ca
bază de date federalizată şi una sau mai multe surse de date.
Baza de date federalizată conţine intrări care identifică sursele
de date şi caracteristicile lor. O sursă de date conţine SGBD şi
date. Aplicaţiile se conectează la baza de date federalizată cum
ar face-o la orice altă bază de date DB2. Baza de date
federalizată DB2 Connect nu este destinată să conţină date
utilizator, singura sa funcţie fiind să conţină informaţii despre
sursele de date.
După ce un sistem federalizat este instalat, informaţia
din sursele de date poate fi accesată ca şi cum s-ar afla într-o
bază de date de mari dimensiuni. Utilizatorii şi aplicaţiile trimit
interogări bazei de date federalizate care extrage, în continuare,
datele din sistemele DB2 şi Oracle după necesităţi. Utilizatorii
şi aplicaţiile specifică nickname-uri în interogări; aceste
nickname-uri furnizează referinţe la tabele şi vizualizări
38
localizate în sursele de date. Din perspectiva utilizatorului,

nickname-urile sunt similare cu alias-urile.
Mulţi factori pot afecta performanţa cererilor
distribuite. Cel mai important dintre ei constă în acurateţea şi
actualitatea informaţiilor despre sursele de date şi obiectele
conţinute în ele, stocate în catalogul global al bazei de date
federalizate. Această informaţie este utilizată de optimizatorul
DB2 şi poate afecta deciziile de a trimite mai departe cererile
pentru evaluare la sursele de date.
MySQL Cluster şi MySQL Federated Storage Engine
MySQL Cluster este o bază de date scalabilă, de

performanţă ridicată, dezvoltată original pentru unele din cele
mai solicitante aplicaţii din industria de telecomunicaţii. De
cele mai multe ori aceste aplicaţii de telecomunicaţii impun o
disponibilitate a bazei de date care să depăşească 99.999%.
De la introducerea produsului MySQL Cluster în 2004,
noi seturi de facilităţi au fost introduse în mod constant. Aceste
facilităţi au lărgit atractivitatea sa pentru cazuri de utilizare,
pieţe şi sectoare industriale noi.
MySQL Cluster este acum adoptat nu numai ca bază de
date pentru aplicaţii tradiţionale de telecomunicaţii cum ar fi:
HLR (Home Locator Registry) sau SLR (Subscriber Locator
Registry), dar este, de asemenea, utilizat şi pentru Service
Delivery Platforms, Value-Added Services, VOIP, aplicaţii
web, facturare internet, managementul sesiunilor, site-uri de
eCommerce, motoare de căutare şi aplicaţii tradiţionale back
39
office. Aplicaţiile industriale s-au extins, incluzând web-ul,

întreprinderi şi organizaţii guvernamentale.
Odată cu lansarea MySQL Cluster 7.0 şi 7.1, au fost
introduse în deja popularul produs MySQL Cluster 6.3 multe
facilităţi şi îmbunătăţiri noi.
MySQL Cluster este o bază de date de disponibilitate
ridicată care utilizează o arhitectură unică de tip Shared-
Nothing şi o interfaţă SQL standard. Sistemul este compus
dintr-un număr de procese de comunicaţii sau noduri care pot fi
distribuite pe diverse maşini pentru a asigura disponibilitatea
continuă în eventualitatea unei defecţiuni de server sau de
reţea. MySQL Cluster utilizează un motor de stocare, compus
dintr-o serie de noduri de date pentru stocarea datelor care pot
fi accesate independent, utilizând SQL standard cu MySQL
Server, prin API NDB pentru acces în timp real sau prin
intermediul altor metode (cum ar fi LDAP sau JPA) care
accesează la rândul lor API NDB.
API NDB este o interfaţă de programare orientată
obiect pentru MySQL Cluster care implementează indecşi,
scan-uri, tranzacţii şi tratarea evenimentelor. Tranzacţiile NDB
respectă ACID prin faptul că asigură un mijloc de a grupa
operaţii de aşa natură încât fie vor fi finalizate integral, fie vor
eşua integral.
MySQL Cluster tolerează defectarea câtorva noduri de
date şi se autoreconfigurează din mers pentru a masca aceste
defecte. Capabilităţile de autoreparare, precum şi faptul că
partiţionarea datelor este ascunsă de aplicaţie, rezultă într-un
model simplu de programare care permite dezvoltatorilor de
40
aplicaţii cu baze de date să includă disponibilitate ridicată în

aplicaţiile lor fără utilizarea unui cod complex de nivel coborât.
MySQL Cluster este alcătuit din trei tipuri de noduri:
noduri de date, noduri servere de management şi noduri server
MySQL.
Nodurile de date stochează toate datele care aparţin
MySQL Cluster. Datele sunt în mod instantaneu replicate între
aceste noduri pentru a asigura disponibilitatea continuă în cazul
în care unul sau mai multe noduri se defectează. De asemenea,
aceste noduri se ocupă cu administrarea tranzacţiilor de baze de
date. Creşterea numărului de copii creşte redundanţa datelor.
De obicei, aplicaţiile care utilizează API NDB accesează
nodurile de date direct, dar le pot accesa şi printr-un server
MySQL.
Nodurile servere de management se ocupă cu
configurarea sistemului la pornire şi sunt, de asemenea,
utilizate atunci când are loc o schimbare în cluster. În
configuraţie minimă, trebuie configurat un singur nod de
management, dar pentru disponibilitatea mai mare trebuie
adăugate noduri suplimentare. Un nod de management este
necesar atunci când clusterul este pornit, oprit sau reconfigurat;
de asemenea, acest tip de nod acţionează ca arbitru în anumite
cazuri de defectare a unui nod de date pentru a asigura evitarea
scenariilor de tip „split brain”.
Nodurile server MySQL permit accesul SQL la nodurile
de date clusterizate. Acest tip de nod oferă dezvoltatorilor o
interfaţă standard pe care să o utilizeze în programare. La
rândul lor, nodurile server trimit cererile către nodurile de date,
eliminând necesitatea utilizării unui cod de nivel coborât,
41
specializat pentru cluster, în aplicaţie. Deşi în configuraţia

minimală este necesar un singur nod server, adăugarea de
noduri suplimentare creşte performanţa. Acest aranjament se
îndreaptă, în mod natural, spre implementarea unei metodologii
de tip Scale-out pentru creşterea scalabilităţii, capacităţii şi
performanţei. Aplicaţiile care au nevoie să obţină o
performanţă maximă în timp real de la baza de date MySQL
Cluster ar trebui să utilizeze API NDB direct şi nu să opteze
pentru trecerea prin nodurile server.
De asemenea, există o serie de tehnologii de conectare
care pot fi utilizate de către aplicaţii pentru a accesa datele prin
API NDB, furnizând independenţă completă a dezvoltatorilor
şi integrare uşoară cu MySQL Cluster pentru o gamă largă de
aplicaţii web şi de întreprindere şi beneficiind, în acelaşi timp,
de performanţa oferită de API NDB. Baza de date este
segregată intern în partiţii astfel încât acestea să poată fi
distribuite pe nodurile de date. Pentru a evita existenţa unui
punct singular de defectare, două sau mai multe noduri de date
stochează datele pentru o anumită partiţie, aceste noduri fiind
numite grup de noduri.
În Figura 5 este ilustrată o configuraţie minimală a
MySQL Cluster care conţine:
 un nod server;
 un nod de management;
 două noduri de date (formând un grup de noduri)
pentru disponibilitate crescută.
42
Figura 5 – O configuraţie minimală a MySQL Cluster
În Figura 6 este prezentată o configuraţie MySQL

Cluster pe care s-a aplicat un Scale-out pentru a creşte
performanţa şi capacitatea. Acest rezultat a fost atins prin
adăugarea a două noduri server noi, a două noduri de date şi a
unui nod de management pentru redundanţa proceselor.
Astfel, noua configuraţie conţine:
 trei noduri server;
 două noduri de management (adăugate mai mult
pentru redundanţa operaţiilor de mentenanţă decât
pentru capacitate sau performanţă);
 patru noduri de date (formând două grupuri de
noduri) pentru creşterea performanţei, capacităţii şi
disponibilității.
43
Figura 6 – O configuraţie extinsă MySQL Cluster
Aşa cum se observă în Figura 6, toate nodurile server

din MySQL Cluster sunt conectate la toate celelalte tipuri de
noduri. Toate modificările făcute de nodurile server sunt
stocate în toate nodurile de date şi devin imediat vizibile către
alte noduri server (începând din momentul finalizării
tranzacţiei), ducând la o imagine unitară în baza de date.
A fost acordată o atenţie deosebită proiectării bazate pe
noduri a MySQL Cluster pentru a pentru a oferi disponibilitate
ridicată, astfel:
 dacă un nod de date nu mai funcţionează, atunci
nodurile server pot utiliza orice alt nod de date din
grupul respectiv, pentru a executa tranzacţiile;
 datele din nodurile de date sunt replicate pe toate
nodurile din grupul de noduri respectiv; Dacă un
44
nod de date se defectează, există tot timpul cel puţin

încă un nod care conţine aceeaşi informaţie.
 noduri suplimentare de management pot fi adăugate
de aşa natură încât nicio operaţie de management
sau de arbitrare să nu eşueze în cazul în care un nod
de management se defectează.
Proiectarea clusterului folosind această metodă îi
conferă sistemului următoarele caracteristici: încrederea
utilizatorului, disponibilitate ridicată şi un număr de puncte
singurale de defectare minim.Orice nod poate fi pierdut fără a
afecta sistemul ca întreg. O aplicaţie poate, de exemplu, să îşi
continue execuţia, chiar dacă nodul de date nu mai
funcţionează, admiţând că mai există cel puţin un nod
funcţional în grupul respectiv. Tehnicile utilizate pentru a spori
nivelul de încredere şi disponibilitatea sistemului de baze de
date includ următoarele aspecte:
 datele sunt în mod continuu replicate între toate
nodurile de date din grup; Acest lucru conduce la
timpi foarte reduşi de nefuncţionare în cazul în care
un nod se defectează.
 nodurile sunt executate pe maşini multiple,
permiţând ca MySQL Cluster să opereze chiar după
o defectare fizică a unei maşini;
 nodurile sunt proiectate pe o arhitectură Shared-
Nothing; Fiecare nod de date are propriul sistem de
stocare şi propria memorie de lucru.
 numărul de puncte singulare de defectare este
minimizat. Orice nod (în unele configuraţii chiar
mai multe noduri) pot fi pierdute fără pierderi de
45
date și fără ca aplicaţia care utiliza baza de date să

fie oprită. În mod similar, conexiunile de reţea pot fi
proiectate astfel încât să nu existe un punct singular
de defectare la interconexiuni.
În plus, pentru disponibilitatea ridicată atinsă la nivel de
locaţie prin arhitectura redundantă a MySQL Cluster, poate fi
obţinută, de asemenea, redundanţă geografică, utilizând
replicarea asincronă între două clustere.
Utilizarea replicării la nivel de linie conduce la
abilitatea de a replica un MySQL Cluster pe alt MySQL
Cluster sau chiar pe baze de date MySQL non-cluster. Este
posibilă crearea uneia dintre următoarele configuraţii master /
slave:
 MySQL Cluster pe un MySQL Cluster;
 MySQL Server (MyISAM, InnoDB etc.) pe un
MySQL Cluster;
 MySQL Cluster pe un MySQL Server (MyISAM,
InnoDB etc.).
De asemenea, este posibil ca o singură bază de date
MySQL Cluster să fie replicată pe una sau mai multe instalări
MySQL Cluster, dar şi pe una sau mai multe baze de date,
utilizând motoare de stocare diferite.
Dacă scopul este obţinerea celei mai ridicate
disponibilităţi, o configuraţie de replicare MySQL Cluster cu
canale redundante de replicare ar fi soluţia ideală. Unele dintre
cele mai întâlnite motive pentru implementarea replicării sunt:
replicarea pentru a atinge disponibilitate ridicată în cadrul unui
data center sau într-o reţea WAN geografică; o bază de date
replicată pentru utilizarea în caz de defecţiune; obţinerea unor
46
latenţe mai mici la accesul datelor în diferite puncte geografice;

o bază de date replicată pentru analize de date complexe, dar
care să nu influenţeze baza de date principală de producţie.
1.2 Organizarea semistructurată a volumelor mari de

date. Baze de date NoSQL (Not Only SQL)
Conceptul descris de termenul NoSQL (Not only SQL)

reprezintă un sistem de baze de date care este distribuit, ar
putea să nu necesite scheme fixe pentru tabele, evită, de obicei,
operaţiile de tip join, este, în mod tipic, scalabil pe orizontală,
nu pune la dispoziţie o interfaţă de interogare SQL şi, în cele
mai multe cazuri, este open source (Bucur & Tudorică,
Solutions for working with large data volumes in web
applications, 2011) – unele surse bibliografice folosesc acest
termen chiar cu sensul de sistem complet nerelaţional.
De asemenea, acest concept este asimilat de către surse
aparţinând lumii academice ca fiind o formă structurată de
“magazie” de date (eng. storage; dat fiind că nu există un
termen echivalent în limba română, autorul alege să folosească
în continuare traducerea mot-a-mot a termenului, deşi nu este
adaptată contextului) (Edlich, 2013), (Ivan & Ciurea, 2009),
(Lungu, Velicanu, & Botha, 2009) (Kellerman, 2009). Totuşi,
cei doi termeni par a nu fi în întregime echivalenţi, bazele de
date relaţionale reprezentând, conform definiţiei lor oficiale,
“magaziile structurate de date”, dar, din punct de vedere al
calităţilor, ele opunându-se termenului de NoSQL.
În ciuda celor afirmate anterior, termenii de SGBD
relaţional şi, respectiv, NoSQL nu pot fi etichetaţi ca fiind
47
complet opuşi. Există chiar aplicaţii de tip middleware (cum ar

fi: CloudTPS pentru Google’s BigTable şi produsul Amazon’s
SimpleDB) (Hope, 2006) sau diverse soluţii (cum ar fi:
Percolator pentru Google’s BigTable (Chang, 2008), (Mircea
& Andreescu, 2011), prototipul încă nedenumit oficial pentru
Google’s Hbase (De Sterck & Zhang, 2010), (Hamilton, 2009),
(Kellerman, 2009)) care adaugă facilităţi complete ACID la
anumite sisteme NoSQL.
Deşi conceptul de baze de date NoSQL a apărut cu un
deceniu înainte de era Web 2.0, el este, cu siguranţă, un produs
al acestei perioade. Acestea au început să fie folosite, cu
adevărat, numai atunci când proiectanţii serviciilor web cu un
număr mare de utilizatori au descoperit că SGBD relaţionale
tradiţionale sunt potrivite fie pentru tranzacţii frecvente, dar de
mici dimensiuni, de tip citire / scriere (aplicaţii de tip OLTP –
On-Line Transactional Processing), fie pentru tranzacţii batch
de mari dimensiuni cu multe operaţii de citire şi foarte rare
operaţii de scriere (aplicaţii de tip OLAP – On-Line Analytical
Processing), dar nu şi pentru volume mari de tranzacţii de citire
/ scriere de dimensiuni mari (cum este de cele mai multe ori
cazul pentru aceste servicii web pe scară mare – cum ar fi
Google, Amazon, Facebook, Yahoo şi altele asemănătoare).
Se pare totuşi că cel puţin câţiva dintre aceşti principali
producători SGBD relaţionale încep să ţină cont de această
tendinţă (de exemplu: Microsoft a introdus câteva facilităţi de
tip NoSQL, cum ar fi: izolarea snapshot-urilor, deşi
operaţională la nivelul unui singur tabel, în noul său produs de
tip SGBD relaţional numit Azure; Oracle 11g conţine, de
asemenea, o facilitate asemănătoare denumită Oracle Streams,
48
dar şi aceasta este limitată în mod asemănător cu produsul

Microsoft, de această dată la o singură instanţă a bazei de date)
(Hamilton, 2009). În continuare vor fi enumerate câteva dintre
cele mai importante aplicaţii din această categorie, împreună cu
unele caracteristici ale lor.
1.2.1 Facebook Cassandra
Cassandra este o structură de date de tip cheie – valoare

(key-value store) înalt scalabilă, consistentă, distribuită şi
structurată. Cassandra combină tehnologiile de sisteme
distribuite din Dynamo şi modelul de date din Google
BigTable. Ca şi Dynamo, Cassandra este consistent în cele din
urmă. Ca şi BigTable, Cassandra furnizează un model de date
ColumnFamily-based care este mai bogat decât modelele tipice
de sisteme cheie-valoare (Lakshman & Malik, Cassandra, a
decentralized structured storage system, 2010).
Aplicaţia Cassandra a fost dezvoltată în sistem open
source de Facebook în 2008, fiind proiectată de Avinash
Lakshman (care a fost şi unul dintre autorii lui Amazon's
Dynamo) şi de Prashant Malik (inginer la Facebook). În
prezent, Cassandra este folosită de Facebook, dar, încă, asupra
ei se realizează modificări importante (Lakshman & Malik,
Cassandra, Structured storage system over a P2P network,
2009).
Cassandra este bazată pe un model cheie-valoare clasic
extins cu două nivele de imbricare. O bază de date este
alcătuită din familii de coloane. O familie de coloane este un
set de perechi cheie-valoare (Grinev, 2010).
49
În cadrul primului nivel, valoarea unei înregistrări este,

la rândul ei, o secvenţă de perechi chei-valori. Aceste perechi
de chei-valori imbricate sunt numite coloane, unde cheia este
numele coloanei. Acest nivel de imbricare este obligatoriu – o
înregistrare trebuie să conţină cel puţin o coloană.
În cadrul celui de-al doilea nivel, care este opţional,
valoarea unei perechi cheie-valoare imbricate poate fi, de
asemenea, o secvenţă de perechi cheie-valoare. Atunci când al
doilea nivel de imbricare este prezent, perechile de chei-valori
externe sunt numite super coloane cu cheia denumită ca super
coloana şi perechile chei-valori interne sunt numite coloane.
Atât numele coloanelor, cât şi al supercoloanelor pot fi
folosite în două moduri: ca nume de atribute sau ca valori
(uzual valori referite). Utilizarea numelor de coloane şi
supercoloane ca valori este facilitată de faptul că nu există
limitări în numărul de super coloane şi de coloane din
subordinea oricărei înregistrări şi de faptul că numele sunt de
fapt vectori de octeţi, astfel încât pot fi codificate de fapt orice
tipuri de valori în ele.
Coloanele şi supercoloanele sunt stocate ordonat în
funcţie de valori. Se poate specifica criteriul după care se face
sortarea prin specificarea modului în care Cassandra să trateze
numele de coloane şi supercoloane. Numele pot fi tratate ca
Bytes, Long, Ascii, UTF8, Lexical UUID, sau Time UUID.
Pentru a exemplifica modelul de date descris anterior,
se poate considera următorul exemplu: familia de coloane
Tweets (schiţată în Figura 7) conţine înregistrări referitoare la
articole de pe www.tweets.com. Cheia înregistrării este
considerată a fi de tip Time UUID şi este generată la momentul
50
în care este primit articolul (această facilitate va fi utilizată în

familia de coloane User_Timelines). Înregistrarea va fi
alcătuită din coloane (nu există supercoloane în acest caz).
Coloanele vor reprezenta atributele articolelor (la acest nivel,
organizarea este asemănătoare cu cea din bazele de date
relaţionale).
Figura 7 – Structura familiei de coloane Tweets
1.2.2 Amazon Dynamo şi Simple Storage Service

(Amazon S3)
Pentru a îndeplini cerinţele referitoare la nivelul de

încredere şi la scalabilitate, Amazon a dezvoltat un număr de
tehnologii de stocare a volumelor mari de date, printre care şi
Amazon Simple Storage Service (utilizat şi în afara sistemului
Amazon şi cunoscut, de asemenea, şi cu numele de Amazon
S3) şi Dynamo, un alt sistem de stocare cu disponibilitate
ridicată, distribuit şi scalabil construit pentru platforma
Amazon. Dynamo este utilizat pentru managementul stării
51
serviciilor care au cerinţe foarte mari de nivel de încredere şi

au nevoie de un control strâns asupra echilibrului între
disponibilitate, consistenţă, performanţă şi eficienţă din punct
de vedere al costurilor.
Platforma Amazon conţine un număr mare de aplicaţii
care au cerinţe diverse de stocare. O parte dintre aceste aplicaţii
necesită sisteme de stocare suficient de flexibile încât să
permită proiectanţilor de aplicaţie să îşi configureze sistemul
de stocare pentru a atinge echilibrul dorit între calităţile
specificate anterior.
Multe dintre serviciile platformei Amazon nu au nevoie
decât de acces bazat pe cheie primară la o bază de date. Pentru
numeroase servicii, cum ar fi cele care furnizează lista celor
mai bune vânzări, coşurile de cumpărături, preferinţele
clienţilor, managementul sesiunilor, topul vânzărilor şi
catalogul de produse, utilizarea unei baze de date relaţionale
oarecare ar duce la ineficienţă, precum şi la limitarea scalării şi
a disponibilităţii. Dynamo furnizează o interfaţă simplă, doar
cu cheie primară, care îndeplineşte cerinţele acestor aplicaţii.
Dynamo utilizează o combinaţie a unor tehnologii bine
cunoscute pentru a oferi scalabilitate şi disponibilitate:
 datele sunt partiţionate şi replicate utilizând hashing
consistent (Karger, Leighton, Panigrahy, Levine, &
Lewin, 1997) şi consistenţa este facilitată de
versionalizarea obiectelor (Lamport, 1978);
 consistenţa între replici în timpul modificărilor este
menţinută printr-o tehnică de forma unui cvorum şi
printr-un protocol descentralizat de sincronizare a
replicilor;
52
 Dynamo foloseşte o metodă distribuită de detecţie a

defecţiunilor bazată pe “bârfe” şi pe un protocol de
membership;
 Dynamo este un sistem complet descentralizat care
are cerinţe minime de administrare manuală.
Nodurile de stocare pot fi adăugate sau eliminate
din Dynamo fără a necesita vreo partiţionare sau
vreo redistribuire manuală.
Figura 8 prezintă un model abstract al arhitecturii
platformei Amazon, în care conţinutul web dinamic este
generat de către componentele de randare a paginilor care la
rândul lor interoghează multe alte servicii. Un serviciu
utilizează baze de date diferite pentru a îşi administra starea,
aceste baze de date fiind accesibile numai în interiorul limitelor
serviciului respectiv. Unele servicii acţionează ca agregatori, în
sensul că utilizează alte servicii pentru a produce răspunsuri
compozite. În mod tipic, serviciile agregatoare nu au stări, deşi
utilizează un caching extensiv.
53
Figura 8 - Un model abstract al arhitecturii platformei Amazon
Arhitectura unui sistem de stocare necesară într-o

asemenea structură de producţie este complexă. În afară de
componenta de persistenţă a datelor, sistemul are nevoie şi de
soluţii scalabile şi robuste pentru balansarea încărcării,
membership şi detecţia defecţiunilor, transferul stării,
concurenţă, programarea activităţilor, managementul cererilor,
direcţionarea cererilor, monitorizare de sistem şi alarmare,
precum şi pentru managementul configuraţiei.
54
Descrierea detaliilor fiecăreia dintre soluţii nu este

posibilă în acest cadru restrâns, de aceea acest subcapitol se
concentrează numai asupra tehnicilor de sistem distribuit
utilizate în Dynamo: partiţionare, replicare, controlul
versiunilor, membership, tratarea defecţiunilor şi scalare.
Tabelul 1 conţine o listă a tehnicilor utilizate de
Dynamo şi a avantajelor acestora.
Tabelul 1 - Un sumar al listei tehnicilor utilizate de Dynamo împreună

cu avantajele lor
Problemă Tehnică Avantaje
Partiţionarea Hashing consistent Scalabilitate incrementală
Ceasuri vectoriale
Disponibilitate
împreună cu Dimensiunea versiunii este
ridicată pentru
reconciliere în decuplată de rata modificărilor
scrieri
timpul citirilor
Furnizează o garanţie de
Tratarea
Sloppy Quorum şi disponibilitate şi durabilitate
defecţiunilor
hinted handoff ridicată atunci când anumite
temporare
replici nu sunt disponibile
Recuperarea din Antientropie
Sincronizează replicile
defecţiuni utilizând arbori
divergente în background
permanente Merkle
Păstrează simetria şi elimină
Protocol gossip-
Membership şi necesitatea unui registru
based membership
detecţia centralizat pentru stocarea
şi detecţia
defecţiunilor informaţiilor de membership şi
defectelor
de stare a nodurilor.
1.2.3 Apache CouchDB
Apache CouchDB este o bază de date orientată pe

documente care poate fi indexată şi interogată în stil
55
MapReduce utilizând JavaScript. CouchDB oferă, de

asemenea, replicare incrementală cu detecţie şi rezolvare
bidirecţională a conflictelor.
CouchDB furnizează un API RESTful JSON care poate
fi accesat din orice mediu care permite cereri HTTP. Există un
număr mare de biblioteci client furnizate de terţe părţi care
facilitează acest lucru, folosind limbajul preferat de
programare. Consola de administrate web inclusă în CouchDB
comunică direct cu baza de date, utilizând cereri HTTP emise
din browser.
CouchDB este scrisă în Erlang, un limbaj de
programare robust, ideal pentru construcţia sistemelor
concurente distribuite şi care permite obţinerea unui design
flexibil, uşor de scalat şi extensibil în mod implicit.
Vizualizări
Pentru a rezolva problema structurării datelor semi-

structurate, CouchDB integrează un model de vizualizare bazat
pe JavaScript. Vizualizările reprezintă metoda de agregare şi
raportare a conţinutului documentelor din baza de date şi sunt
construite la comandă pentru agregări, uniuni şi rapoarte asupra
documentelor din baza de date. Vizualizările sunt construite
dinamic şi nu afectează documentele pe care se bazează (pot fi
create oricâte documente bazate pe aceleaşi date).
56
Absenţa unei scheme
Spre deosebire de bazele de date SQL care sunt

proiectate să stocheze şi să raporteze date înalt structurate şi
inter-relaţionate, baza de date CouchDB este proiectată să
stocheze şi să raporteze cantităţi mari de date semi-structurate,
orientate document. CouchDB simplifică masiv crearea de
aplicaţii orientate document, care constituie cea mai mare parte
a aplicaţiilor web colaborative.
Într-o bază de date SQL, pe măsură ce necesităţile se
schimbă, schemele şi arhitecturile de stocare ale datelor trebuie
modificate. Acest lucru generează probleme pentru că apar
cerinţe care nu au fost anticipate în proiectul iniţial, făcând
upgrade-urile distribuite o problemă pentru fiecare maşină care
trebuie să treacă printr-o modificare de schemă.
La baza de date CouchDB nu există nicio schemă, astfel
încât documentele noi care au semnificaţii noi pot fi adăugate
fără probleme alături de documentele mai vechi. Motorul de
vizualizare, utilizând JavaScript, este proiectat să manevreze
uşor tipuri noi de documente, precum şi documente disparate,
dar similare.
Sistem distribuit
CouchDB este un sistem de baze distribuit în mod

omogen. Orice număr de maşini CouchDB (servere, dar şi
clienţi offline) pot avea replici independente ale aceleiaşi baze
de date cu care aplicaţiile au interactivitate completă
(interogare, adăugare, modificare, ştergere). Atunci când
57
maşinile respective sunt reconectate sau când se stabileşte un

program, modificările bazei de date sunt replicate bidirecţional.
CouchDB are incluse facilităţi de detecţie şi
management al conflictelor, iar procesul de replicare este
incremental şi rapid, copiind doar acele documente sau
câmpuri individuale schimbate de la ultima replicare. Cele mai
multe aplicaţii nu necesită nicio planificare specială pentru a
beneficia de avantajele oferite de actualizările distribuite şi de
replicare.
Spre deosebire de încercările complexe de a adăuga
facilităţi distribuite la vechile modele şi sisteme clasice de baze
de date, CouchDB este rezultatul unei proiectări, modelări şi
integrări atente, pornind de la zero. Modelele pentru document,
vizualizare, securitate şi replicare, limbajul specializat de
interogare şi arhitectura robustă de stocare sunt integrate, cu
grijă, pentru a obţine un sistem eficient şi de încredere (Okman,
Gal-Oz, Gonen, Gudes, & Abramov, 2011).
1.2.4 Apache Hadoop
Proiectul Apache Hadoop dezvoltă software open

source pentru prelucrări distribuite, scalabile şi de încredere.
Biblioteca software Apache Hadoop este un framework
care permite procesarea distribuită a unor seturi de date de mari
dimensiuni peste clustere de calculatoare, utilizând un model
simplu de programare. Această bibliotecă este proiectată pentru
scalarea de la servere individuale la un nivel de mii de maşini,
fiecare oferind prelucrare şi stocare locale (Borthakur, et al.,
2011). În loc să se bazeze pe hardware pentru asigurarea unei
58
disponibilităţi ridicate, biblioteca însăşi este proiectată să

detecteze şi să trateze defecţiunile în nivelul aplicaţie, oferind
în acest fel un serviciu cu disponibilitate ridicată bazat pe un
cluster de maşini, fiecare dintre ele în parte putându-se defecta
(Abouzeid, Bajda-Pawlikowski, Abadi, Rasin, & Silberschatz,
2009).
Proiectul Apache Hadoop include următoarele
subproiecte:
 Hadoop Common - utilităţile care asistă celelalte
subproiecte;
 Hadoop Distributed File System (HDFS) - un sistem
distribuit de fişiere care furnizează acces de
performanţă ridicată la datele de aplicaţie;
 Hadoop MapReduce - un framework software
pentru procesarea distribuită a unor volume mari de
date pe clustere de prelucrare (Bhatotia, Wieder,
Rodrigues, Acar, & Pasquin, 2011);
Alte proiecte Apache legate de Hadoop sunt
următoarele:
 Avro - un sistem de serializare a datelor;
 Cassandra - o bază de date scalabilă multi-master
fără puncte singulare de defectare (prezentată într-
un subcapitol anterior al tezei);
 Chukwa - un sistem de colectare a datelor pentru
administrarea sistemelor distribuite de dimensiuni
mari;
 Hbase - o bază de date scalabilă, distribuită care
asigură stocarea structurată a datelor pentru tabele
de mari dimensiuni;
59
 Hive - o infrastructură de depozite de date care

furnizează sumarizarea datelor şi interogări ad-hoc;
 Mahout - o bibliotecă pentru machine learning
scalabil şi pentru data mining;
 Pig - un limbaj de nivel înalt pentru descrierea
fluxurilor de date şi un framework de execuţie
pentru calcul paralel;
 ZooKeeper - un serviciu de mare performanţă de
coordonare a aplicaţiilor distribuite.
1.2.5 O posibilă clasificare a bazelor de date NoSQL
Pentru a putea examina mai detaliat, precum şi pentru a

compara sau măsura performanţele produselor NoSQL, un
prim pas al cercetării efectuate a fost realizarea unei clasificări
a acestor produse astfel încât să se poată determina care dintre
ele îndeplinesc scopuri similare sau au calităţi sau facilităţi
similare.
Deşi au existat câteva încercări în această direcţie,
pentru moment nu există nicio taxonomie oficială pentru acest
tip de software.
O primă clasificare propusă conţine următoarele
categorii şi subcategorii (Tudorică & Bucur, A comparison
between several NoSQL databases with comments and notes,
2011):
A. Sisteme NoSQL propriu-zise, multe dintre ele
create drept componente pentru servicii Web 2.0, cu
60
 Wide Column Store / Column Families (Hadoop /

HBase, Cassandra, Hypertable, Cloudata, Amazon
SimpleDB, SciDB);
 Document Store (CouchDB, MongoDB, Terrastore,
ThruDB, OrientDB, RavenDB, Citrusleaf, SisoDB,
CloudKit, Perservere, Jackrabbit);
 Key Value / Tuple Store (Azure Table Storage,
MEMBASE, Riak, Redis, Chordless, GenieDB,
Scalaris, Tokyo Cabinet / Tyrant, GT.M, Keyspace,
Berkeley DB, MemcacheDB, HamsterDB, Faircom
C-Tree, Mnesia, LightCloud, Pincaster, Hibari,
Scality);
 Eventually Consistent Key Value Store (Amazon
Dynamo, Voldemort, Dynomite, KAI, SubRecord,
Mo8onDb, Dovetaildb);
 Graph Databases (Neo4J, Infinite Graph, Sones,
InfoGrid, HyperGraphDB, Trinity, AllegroGraph,
Bigdata, DEX, OpenLink Virtuoso, VertexDB,
FlockDB, Java Universal Network / Graph
Framework, Sesame, Filament, OWLim, NetworkX,
iGraph).
B. Sisteme NoSQL „moi”, multe dintre ele fiind
sisteme mai vechi sau mai noi, care nu au legătură
cu servicii Web 2.0, dar prezintă unele dintre
trăsăturile descrise ca fiind caracteristici NoSQL
(unele dintre ele au chiar caracteristici complete
ACID şi, din acest motiv, s-ar putea să nu aibă loc
într-o astfel de clasificare a sistemelor NoSQL, fiind
61
necesare analize ulterioare în această direcţie), cu

 Object Databases (db4o, Versant, Objectivity,
Gemstone, Progress, Starcounter, Perst, ZODB,
NEO, PicoLisp, Sterling, StupidDB, KiokuDB,
Durus);
 Grid & Cloud Database Solutions (GigaSpaces,
Queplix, Hazelcast, Joafip, GridGain, Infinispan,
Coherence, eXtremeScale);
 XML Databases (Mark Logic Server, EMC
Documentum xDB, Tamino, eXist, Sedna, BaseX,
Xindice, Qizx, Berkeley DB XML);
 Multivalue Databases (U2, OpenInsight, OpenQM,
Globals);
 Alte baze de date fără legătură cu NoSQL (IBM
Lotus/Domino, Intersystems Cache, eXtremeDB,
ISIS Family, Prevayler, Yserial).
O altă taxonomie propusă prevede următoarele categorii
de baze de date NoSQL:
A. Document store (Apache Jackrabbit, Apache
CouchDB, Lotus Notes, MongoDB, MarkLogic
Server, eXist, SimpleDB, Terrastore);
B. Graph (AllegroGraph, Neo4j, DEX, FlockDB);
C. Key-value store, cu următoarele subtipuri:
 Eventually‐consistent key‐value store (Cassandra,
Dynamo, Hibari, Project Voldemort, Riak);
 Hierarchical key-value store (GT.M);
 Hosted services (Freebase);
62
 Key-value cache în RAM (Citrusleaf database,

memcached, Oracle Coherence, Redis, Tuple space,
Velocity);
 Key-value stores care implementează algoritmul
Paxos (Keyspace);
 Key-value stores pe disc (BigTable, CDB,
Citrusleaf database, Dynomite, Keyspace, membase,
MemcacheDB, Redis, Tokyo Cabinet, TreapDB,
Tuple space, MongoDB);
 Multivalue databases (Extensible Storage Engine -
ESE/NT, OpenQM, Revelation Software's
OpenInsight, Rocket U2);
 Baze de date orientate obiect (db4o, GemStone/S,
InterSystems Caché, JADE, Objectivity/DB,
ObjectStore, Versant Object Database, ZODB);
 Ordered key-value store (Berkeley DB, IBM
Informix C-ISAM, MemcacheDB, NMDB);
 Tabular (BigTable, Hbase, Hypertable, Mnesia),
Tuple store (Apache River).
Se remarcă faptul că cele două taxonomii, deşi aparent
utilizând acelaşi criteriu (metoda de implementare), furnizează
rezultate destul de diferite (produse care sunt în aceeaşi
categorie în una dintre clasificări, apar în categorii diferite în
cealaltă, iar etichetele şi diviziunile între categorii sunt
diferite).
63
1.3 Concluzii parţiale
În acest capitol al tezei au fost abordate două aspecte

referitoare la modalităţile de structurare a volumelor mari de
date şi anume organizarea structurată (bazele de date
relaţionale) şi organizarea semistructurată (bazele de date
NoSQL).
În ceea ce priveşte organizarea structurată a volumelor
mari de date, au fost prezentate în subcapitolul 1.1, soluţiile
oferite de cei mai mari competitori din domeniul bazelor de
date relaţionale (Oracle, IBM, Microsoft).
Subcapitolul 1.2 a fost dedicat bazelor de date NoSQL,
fiind descrise conceptul de bază de date NoSQL şi câteva
aplicaţii considerate de către autor a fi semnificative în acest
domeniu: Facebook Cassandra, Amazon Dynamo şi Amazon
S3, Apache CouchDB şi Apache Hadoop.
O parte importantă a acestui capitol este reprezentată de
realizarea de către autor a unei clasificări a produselor NoSQL,
astfel încât să se poată determina care dintre ele îndeplinesc
scopuri similare sau au calităţi sau facilităţi similare.
Deşi diferite surse bibliografice din literatura de
specialitate indică termenul NoSQL ca fiind total nerelaţional,
termenii de SGBD relaţional şi respectiv NoSQL nu pot fi
etichetaţi ca fiind complet opuşi. Există aplicaţii de tip
middleware, în care cele două concepte sunt îmbinate.
Analiza efectuată în acest capitol asupra modalităţilor
de structurare a volumelor mari de date a condus la alegerea de
către autor a soluţiei oferite de bazele de date NoSQL. Pentru
acest tip de date semistructurate, va fi implementată o aplicaţie
de interfaţă pentru organizarea şi prelucrarea datelor.
64
2 Prelucrarea volumelor mari de date
2.1 Suportul fizic utilizat pentru prelucrarea

2.1.1 Sisteme de calcul de înaltă performanță
Un sistem de calcul de înaltă performanţă (deseori

denumit şi supercalculator sau supercomputer) se consideră a fi
un sistem de calcul ale cărui performanţe se situează la vârf în
epoca sa, în special din punct de vedere al vitezei de calcul.
Supercalculatoarele sunt utilizate pentru sarcini care
utilizează intensiv calcule, cum ar fi: probleme de fizică
cuantică, prognoza vremii, cercetări climatice, modelare
moleculară, simulări fizice etc.
În mod tipic, supercalculatoarele sunt construite ca
unicate de către companii cu tradiţie în domeniu, precum Cray,
IBM şi Hewlett-Packard.
Detalii specifice hardware şi software
Supercalculatoarele propriu-zise reuşesc să obţină

sporul de performanţă necesar prin specializarea într-o anumită
direcţie (de cele mai multe ori calcule matematice), prin
utilizarea unor ierarhii de memorii atent gândite pentru a
elimina timpii de inactivitate (timpi idle) şi prin utilizarea unor
sisteme de I / O al căror scop constă, în primul rând, în
65
obţinerea unei lăţimi de bandă mari şi, în al doilea rând, în

reducerea latenţei (majoritatea supercalculatoarelor nu sunt
destinate procesării tranzacţionale unde latenţa este un factor
important).
Ca la toate sistemele înalt paralelizate, se aplică legea
lui Amdahl. De aceea, trebuie depuse eforturi pentru a elimina
serializarea software şi trebuie utilizat la maxim hardware-ul
pentru accelerarea procesării porţiunilor rămase serializate
(Figura 9). Din Figura 9, se poate observa că, pentru un anumit
procent de procesare rămasă serializată, nu se pot obţine
sporuri de viteză dincolo de un anumit nivel, indiferent câtă
forţă brută de procesare - număr de CPU - se alocă (Parhami,
1999).
Figura 9 – Creşterea de performanţă dată de creşterea numărului de

CPU, depinzând de procentul din prelucrare care este paralelizabil
66
Tehnologii utilizate şi provocări tehnice
Pe lângă limitările teoretice specificate anterior,

supercalculatoarele sunt supuse şi unor limitări tehnologice.
Astfel, sistemele de calcul de înaltă performanţă consumă
cantităţi mari de energie electrică, o mare parte din aceasta
fiind convertită în căldură care la rândul ei necesită răcire. Pe
lângă faptul că sistemele de răcire nu pot fi oricât de
performante, consumul de energie electrică devine o limitare
economică în sine deoarece costurile cu energia electrică
pentru un supercalculator al cărui consum este de 4 MW sunt
de aproximativ 3.5 milioane USD pe an de operare (Qureshi,
Weber, Balakrishnan, Guttag, & Maggs, 2009).
O altă limitare tehnologică majoră este dată de limita
maximă a vitezei cu care informaţia poate fi trimisă, limită care
este dată de viteza luminii. Pentru un supercalculator care
atinge dimensiuni de câţiva metri sau zeci de metri, latenţa dată
de această limitare este de ordinul zecilor de nanosecunde.
Anumite modele de supercalculatoare au încercat să rezolve
parţial această problemă prin optimizarea formei
supercalculatorului (de exemplu: formele cilindrice adoptate de
Seymour Cray). Chiar şi cu aceste optimizări, pentru
supercalculatoarele moderne se estimează latenţe de ordinul a
1–5 microsecunde la trimiterea unui mesaj între CPU (Barroso
& Holzle, 2009), (Benson, Akella, & Maltz, 2010).
De asemenea, o altă provocare tehnologică majoră este
dată de cantităţile enorme de date care trebuie vehiculate în
perioade de timp scurte de la sistemele de stocare, către CPU şi
înapoi. Ken Batcher a remarcat cu un oarecare umor că "Un
67
supercalculator este un echipament pentru transformarea unei

probleme dificile din punct de vedere al timpului de calcul într-
o problemă dificilă din punct de vedere al I / O."
Tehnici de procesare utilizate
Procesarea propriu-zisă se bazează pe tehnici de

procesare Single Instruction Multiple Data - SIMD - numite
alternativ tehnici de procesare vectorială, dar utilizarea acestor
tehnici nu se limitează la lumea supercalculatoarelor.
În particular, consolele video şi plăcile video moderne
utilizează, în mod extensiv, SIMD, ajungând individual la
puteri de procesare potenţiale de câţiva TeraFLOPS. Totuşi
aplicaţiile la care această putere de calcul poate fi folosită sunt
limitate de formele relativ specializate de procesare pe care
aceste echipamente le pot executa (pentru mai multe comentarii
în această direcţie a se vedea în continuare capitolul 2.3).
Sisteme de operare utilizate
Aşa cum se poate observa din Tabelul 2, cele mai multe

sisteme de operare instalate pe supercalculatoarele din Top500
sunt din familia Linux, situaţie care se repetă şi în cazul
sistemelor distribuite, după cum se va vedea în subcapitolele
viitoare.
68
Tabelul 2 – O statistică reprezentând familiile de sisteme de operare

instalate pe supercalculatoarele din Top5002
Familia Număr Procent Rmax Total Rpeak Total Număr
de de din (GFlops) (GFlops) total de
sisteme instalări totalul procesoare
de de
operare instalări
Linux 476 95.2 217,932,444 318,748,391 18,700,112
Unix 16 3.2 3,949,373 4,923,380 181,120
Mixte 4 0.8 1,184,521 1,420,492 417,792
Windows 3 0.6 465,600 628,129 46,092
BSD 1 0.2 122,400 131,072 1,280
În Figura 10 este prezentată evoluţia istorică a

distribuţiei familiilor de sisteme de operare instalate pe
supercalculatoarele din Top500. Coroborând informaţiile din
tabelul 2 cu cele din Figura 10 se poate trage concluzia că
sistemele de operare de tip Linux nu numai că ocupă o poziţie
dominantă pe piaţa supercalculatoarelor, dar şi că această
poziţie se va menţine în viitorul apropiat.
2
Tabel de sinteză. Valorile sunt obţinute din specificaţiile
supercalculatoarelor analizate
69
Sistemele din Top 500, după sistemul de operare

folosit
100%
90%
80% Mixt
70%
60% Linux
50% BSD
40%
30% Unix
20%
N/A
10%
0% Mac OS
5/1/1993
7/1/1996
2/1/1998
9/1/1999
4/1/2001
11/1/2002
6/1/2004
1/1/2006
8/1/2007
3/1/2009
5/1/2012
12/1/1994
10/1/2010
Windows
Figura 10 – Graficul distribuţiei familiilor de sisteme de operare

instalate pe supercalculatoarele din Top500
Programarea calculatoarelor de înaltă performanţă
De regulă, arhitectura paralelă folosită de calculatoarele

de înaltă performanţă impune utilizarea de tehnici speciale de
programare pentru exploatarea eficientă a acestei arhitecturi.
Limbajele de programare folosite, în mod obişnuit, sunt Fortran
sau C, cu utilizarea unor biblioteci speciale pentru a
implementa accesul comun la date între noduri. Se depun
eforturi considerabile pentru optimizarea algoritmilor astfel
încât să ţină cont de caracteristicile maşinii pe care va lucra. În
cazul sistemelor de înaltă performanţă care utilizează şi GPU,
70
sunt utilizate medii de programare precum CUDA sau

OpenCL.
Arhitectura supercalculatoarelor moderne
Arhitecturile calculatoarelor de înaltă performanţă

moderne prezintă câteva trăsături comune care vor fi analizate
în cadrul acestui subcapitol.
Arhitectura la nivel de vârf constă în unul sau mai multe
multiprocesoare Multiple Set Multiple Data - MIMD, fiecare
dintre ele conţinând un număr oarecare de CPU, fiecare dintre
CPU având la rândul său la dispoziţie unul sau mai multe
coprocesoare.
Pe lângă această schemă comună, între
supercalculatoare s-au identificat o serie de factori de
diferenţiere: numărul de multiprocesoare, numărul de
procesoare per multiprocesor, numărul de instrucţiuni
simultane care pot fi executate de un CPU, precum şi tipul şi
numărul de coprocesoare. De fapt, aceşti factori sunt cei care
trasează graniţa între supercalculatoarele propriu-zise şi
clusterele de calculatoare (care vor fi examinate în subcapitolul
următor).
Din acest punct de vedere, un supercalculator propriu-
zis este un sistem de calcul pe care rulează o singură instanţă a
unui sistem de operare şi care conţine / utilizează mai multe
nuclee cu rol de CPU, numărul acestora fiind transparent
pentru nivelul aplicaţie. Nucleelor li se vor distribui task-urile
prin utilizarea multiprocesării simetrice, iar resursele de
71
memorie vor fi partajate prin Non-Uniform Memory Access

(NUMA).
Nucleele vor executa aceeaşi instrucţiune pe un număr
variabil de seturi de date, în acelaşi moment. CPU pot fi
procesoare comune sau procesoare specializate pe prelucrări
vectoriale (a se vedea Tabelul 3 pentru distribuţia acestora), de
mare putere sau de putere mai redusă.
Analizând comparativ datele furnizate de eşantioanele
http://top500.org/stats/list/15/procarch,
http://top500.org/stats/list/25/procarch,
http://top500.org/stats/list/37/procarch (dar şi celelalte liste din
aceeaşi serie), se poate concluziona că numărul de sisteme
bazate pe procesoare vectoriale din Top500 a scăzut în mod
constant, tendinţa pentru viitorul apropiat fiind de eliminare a
acestora din uz.
Tabelul 3 – Utilizarea procesoarelor scalare, respectiv vectoriale în

sistemele de calcul din Top5003
Arhitectura Număr Cotă Rmax Total Rpeak Total Număr
procesorului de % (GF) (GF) total de
sisteme procesoare
Vectorială 1 0.20 122400 131072 1280
%
Scalară 499 99.80 58807626 85048877 7778644
%
Totaluri 500 100% 58930025.59 85179949.00 7779924
La rândul lor, coprocesoarele nu pot să execute cod

obişnuit, însă, cu o programare specializată, pot să depăşească
3
72
performanţele unui CPU (pentru anumite aplicaţii şi tipuri de

coprocesoare, chiar cu câteva ordine de mărime). Numărul de
coprocesoare subordonate unui procesor variază destul de mult
de la un supercalculator la altul.
La ora actuală, legea lui Moore şi economiile de scară
sunt factorii dominanţi în proiectarea supercalculatoarelor. În
plus, costul destul de mare al dezvoltării şi producţiei unui
anumit cip transformă activitatea de creare a unui cip
specializat pentru o singură maşină de calcul, într-o activitate
neeconomică, fiind, astfel, favorizată utilizarea cipurilor
produse în masă, pentru care există suficientă cerere astfel încât
să acopere costurile de producţie (tendinţă demonstrată şi de
distribuţia familiilor de procesoare din Top 500 prezentată în
Tabelul 4).
Tabelul 4 – Distribuţia familiilor de procesoare în Top 5004

Procent
Număr din
Generaţia de Rmax Rpeak Număr
de totalul de
procesoare (GFlops) (GFlops) de nuclee
sisteme sisteme
(%)
Intel Xeon E5
275 55 68,013,575 106,508,539 5,172,979
(SandyBridge)
Xeon 5600-
series 95 19 18,776,653 34,408,353 2,155,648
(Westmere-EP)
Power BQC 22 4.4 44,961,303 52,638,515 4,112,384
Opteron 6200 21 4.2 23,743,676 35,328,656 1,332,592
4
73
Series
"Interlagos"
Opteron 6100-
series "Magny- 19 3.8 5,505,506 7,581,114 815,432
Cours"
Xeon 5500-
series 18 3.6 3,342,090 4,421,213 328,948
(Nehalem-EP)
POWER7 12 2.4 4,907,650 6,153,312 200,896
Xeon 5400-
series 10 2 2,442,592 3,378,569 273,157
"Harpertown"
Opteron Quad
6 1.2 778,812 1,022,993 116,736
Core
POWER6 4 0.8 446,123 593,178 31,552
PowerPC 450 4 0.8 1,184,521 1,420,492 417,792
Intel Xeon E5
3 0.6 34,488,963 55,599,648 3,152,280
(IvyBridge)
SPARC64 IXfx 2 0.4 1,209,700 1,317,077 89,088
Opteron Six
2 0.4 1,033,900 1,335,240 128,400
Core
Opterons 6300
Series ("Abu 1 0.2 97,574 114,509 10,224
Dhabi")
NEC 1 0.2 122,400 131,072 1,280
SPARC64 VII 1 0.2 110,600 121,282 12,032
Xeon 5300-
series 1 0.2 132,800 172,608 14,384
"Clovertown"
SPARC64
1 0.2 10,510,000 11,280,384 705,024
VIIIfx
74
Xeon 5500-
series 1 0.2 1,050,000 1,254,550 138,368
(Nehalem-EX)
ShenWei 1 0.2 795,900 1,070,160 137,200
În acelaşi timp, problemele a căror soluţionare impune
utilizarea unei puteri mari de calcul corespund, de fapt,
formelor de paralelizare cu „cu granulaţie mare” care nu
necesită transferuri masive de informaţie între noduri. Din
acest motiv, în cadrul aplicaţiilor moderne, supercalculatoarele
propriu-zise au fost înlocuite, de regulă, de sisteme cluster
alcătuite din sisteme de calcul „comerciale”.
2.1.2 Prelucrare distribuită. Sisteme cluster grid și cloud
Conceptul de sistem distribuit reprezintă o mulţime de

sisteme de calcul autonome care comunică între ele utilizând o
reţea de calculatoare şi care colaborează pentru atingerea unui
scop comun. Un program care este executat într-un sistem
distribuit şi care foloseşte facilităţile oferite de acesta se
numeşte program distribuit, iar procesul de obţinere a unor
astfel de programe se numeşte programare distribuită.
Conceptul este unul destul de flexibil, acoperind orice forme de
conlucrare în reţea, de la reţelele propriu-zise de arie locală sau
de arie mai largă, până la procese autonome care rulează pe
acelaşi sistem de calcul şi care interacţionează între ele printr-
un sistem de mesagerie.
În continuare sunt descrise, pe scurt, proprietăţile pe
care le prezintă, în mod curent, sistemele distribuite.
Un sistem distribuit conţine câteva entităţi
computaţionale, fiecare dintre ele dispunând de memorie locală
75
(aceasta fiind diferenţa specifică faţă de sistemele propriu-zise

de înaltă performanţă). Entităţile comunică între ele printr-un
sistem de mesagerie sau printr-un alt sistem care să permită
comunicarea şi coordonarea.
Maşinile componente ale unui sistem distribuit fie au un
scop comun (cum ar fi: rezolvarea unei probleme
computaţionale de mari dimensiuni), fie pot avea un grad mai
mare de autonomie, iar scopul sistemului distribuit devine
coordonarea utilizării resurselor pratajate şi oferirea de servicii
avansate de comunicaţie.
Un sistem distribuit trebuie să fie tolerant la scoaterea
din funcţiune a calculatoarelor individuale.
Structura sistemului (topologia reţelei, latenţa
legăturilor, numărul de maşini componente) nu este cunoscută
în avans, sistemul poate fi eterogen din punct de vedere al
calculatoarelor şi legăturilor componente şi pot apărea
schimbări chiar în timpul execuţiei programului distribuit.
Fiecare maşină componentă a unui sistem distribuit
trebuie să aibă doar o viziune limitată, incompletă asupra
sistemului, cunoscând decât o parte a datelor de intrare.
Aplicaţii
Utilizarea unui sistem distribuit este determinată de

două motivaţii posibile.
Prima dintre ele provine din faptul că însăşi natura
aplicaţiei impune existenţa mai multor maşini de calcul
interconectate (de exemplu: un caz în care datele sunt produse
76
într-o locaţie fizică, dar sunt necesare pentru prelucrare într-o

altă locaţie).
Al doilea caz este cel în care, în principiu, ar fi posibilă
utilizarea unui singur sistem de calcul (chiar dacă în anumite
cazuri această posibilitate ar presupune utilizarea unui sistem
de înaltă performanţă), dar este preferabilă utilizarea unui
sistem distribuit din motive de ordin practic (de exemplu: ar fi
preferabilă utilizarea unui cluster alcătuit din sisteme low-end
în locul unui singur sistem high-end).
De asemenea, un sistem distribuit prezintă şi
următoarele avantaje: este mai sigur în exploatare decât un
sistem nedistribuit (nu există niciun punct unic de defectare) şi
este mai uşor de extins şi de administrat decât un sistem
monolitic.
Sistemele distribuite sunt utilizate în următoarele
domenii: reţele de telecomunicaţii (reţele telefonice şi de
telefonie celulară, reţele de calculatoare, reţele wireless de
senzori, algoritmi de rutare); aplicaţii de reţea (www şi reţele
peer-to-peer, jocuri MMO şi comunităţi de realitate virtuală,
baze de date distribuite şi sisteme distribuite de gestiune a
bazelor de date, sisteme de fişiere în reţea, sisteme distribuite
de procesare a informaţiei cum ar fi sistemele informaţionale
bancare sau sistemele de rezervare a tichetelor); sisteme de
control de proces în timp real; prelucrare paralelă (prelucrări
ştiinţifice, randare distribuită).
77
Arhitecturi
Pentru procesarea distribuită sunt utilizate diverse

arhitecturi hardware şi software. La nivel jos este necesară
interconectarea mai multor CPU prin intermediul unui tip
oarecare de reţea, indiferent dacă reţeaua respectivă este una
intrasistem (magistrală de date) sau intersistem (reţea propriu-
zisă). La nivel înalt este necesară interconectarea proceselor
care rulează pe aceste CPU, printr-un sistem oarecare de
comunicaţii.
Un alt element principal al arhitecturilor distribuite este
metoda folosită pentru comunicare şi coordonare între
procesele concurente. Poate fi folosită fie o manieră de lucru
bazată pe un protocol de mesagerie, fie un mod de lucru bazat
pe o bază de date centrală care să elimine necesitatea
comunicării inter-procese.
În continuare sunt prezentate arhitecturile de bază în
care se încadrează sistemele distribuite.
Arhitectura client–server - codul inteligent de pe
maşina client cere date de la server, după care formatează şi
afişează aceste date. Intrările de la client sunt trimise înapoi la
server, atunci când ele reprezintă o schimbare permanentă.
Acest tip de arhitectură nu este, de obicei, asimilată cu o
arhitectură distribuită, în ciuda faptului că respectă definiţia de
bază.
Arhitectura peer-to-peer - o arhitectură în care
niciuna dintre maşinile componente nu îndeplineşte un rol
special în furnizarea de servicii sau în administrarea de resurse
de reţea. Sarcinile şi responsabilităţile sunt distribuite uniform
78
între maşini care pot servi atât ca clienţi, cât şi ca servere, după
necesităţi. Nu este un tip de arhitectură foarte intens folosit.
Arhitecturi strâns cuplate (clustere) - se referă la un
grup de maşini de calcul care lucrează împreună, rulând un
singur proces în paralel. Taskul este subdivizat în părţi care
sunt rezolvate individual de către maşinile componente, după
care rezultatele sunt combinate pentru a constitui rezultatul
final.
Arhitectura pe trei nivele - sistemele pe trei nivele
mută logica de lucru de pe maşina client, pe un strat
intermediar pentru a putea fi utilizaţi clienţi fără stări distincte
(stateless). Acest lucru simplifică instalarea aplicaţiilor şi, de
aceea, majoritatea aplicaţiilor web sunt de acest tip.
Arhitectură pe n-nivele - se referă la aplicaţii web care
trimit cererile lor către alte servicii. De obicei, acest tip de
arhitectură este utilizată în aplicaţiile cloud sau de tip online
office.
Arhitecturi bazate pe spaţiu – sistemele sunt bazate
pe infrastructuri care creează prin virtualizare un singur spaţiu
de adrese. Datele sunt replicate pe maşinile componente ale
arhitecturii în mod transparent, după necesităţile aplicaţiei.
Maşina virtuală generată este independentă temporal, spaţial şi
din punct de vedere al referinţei faţă de maşinile componente.
Ca şi arhitectura peer-to-peer, nu este un tip de arhitectură
foarte intens folosit.
În continuare vor fi analizate cele trei categorii care
constituie în viziunea autorului cele trei subdiviziuni majore ale
sistemelor distribuite: sistemele cluster, sistemele grid şi
sistemele cloud.
79
Sisteme cluster
Un cluster este un grup de calculatoare strâns

interconectate, de cele mai multe ori, prin intermediul unei
reţele locale de mare viteză (deşi sunt posibile şi alte
implementări) care lucrează împreună formând un sistem
unitar. De obicei, clusterele sunt utilizate pentru creşterea
performanţei sau a disponibilităţii peste cea a unui singur
sistem de calcul obişnuit, într-un mod mai eficient din punct de
vedere al costului decât utilizarea unui singur sistem care să
atingă caracteristici similare.
În funcţie de scopul pentru care clusterul a fost construit
(mai multă putere de calcul, mai multă performanţă de I / O sau
mai multă disponibilitate), clusterele sunt clasificate în trei
categorii: clustere computaţionale, clustere de echilibare a
încărcării şi clustere de disponibilitate.
Clusterele computaţionale sunt utilizate ca
substituenţi pentru sistemele de înaltă performanţă. De fapt, cea
mai mare parte a sistemelor din Top500 sunt clustere şi nu
sisteme propriu-zise, Top500 nefăcând nicio distincţie între
cele două tipuri de sisteme.
Clusterele de echilibrare a încărcării (load-
balancing) sunt construite pentru a obţine performanţe de I / O
mai bune şi sunt, de obicei, utilizate de aplicaţii Web sau
aplicaţii COM+ aspect determinat de modul lor de operare care
implică, de regulă, mulţi clienţi, în mod simultan.
Clusterele de disponibilitate (failover clusters) sunt,
la rândul lor, împărţite în două tipuri de clustere, în funcţie de
cât de mult este posibil să se poată recupera activitatea care a
80
precedat o defecţiune. Dacă respectivul cluster poate doar să

treacă sarcina maşinii care s-a defectat către o altă maşină
disponibilă, atunci clusterul se consideră a fi de disponibilitate
ridicată (high-availability clusters). Acest tip de clustere de
disponibilitate ridicată nu pot, de obicei, să păstreze starea
curentă a sistemului de dinainte de defecţiune (care va trebui
refăcută ulterior), ci doar să revină la ultima stare salvată
global. Totuşi, acest tip de clustere nu are nevoie de software
specializat şi nici nu solicită existenţa unui hardware
suplimentar. Un alt subtip de clustere de disponibilitate este cel
tolerant la defecte (fault-tolerant) care furnizează cea mai bună
disponibilitate, incluzând operare neîntreruptă, fără pierderi de
stare, în cazul în care o maşină se defectează. Aceste tip de
clustere impune existenţa unui software capabil să urmărească
starea aplicaţiei şi a unui hardware suplimentar.
Tehnologii
Sistemele cluster utilizată o mare varietate de

tehnologii, dintre acestea remarcându-se:
 MPI este o bibliotecă de comunicaţii care permite
scrierea programelor paralele în C, Fortran, Python,
OCaml şi multe alte limbaje de programare;
 Beowulf, distcc şi MPICH - tehnologii pentru
clustering-ul de aplicaţii;
 Linux Virtual Server şi Linux-HA sunt clustere
bazate pe directoare care asigură distribuţia cererilor
de serviciu peste mai multe noduri ale unui cluster;
81
 MOSIX, openMosix, Kerrighed şi OpenSSI sunt

sisteme cluster integrate în nucleul de sistem de
operare care permit migrarea automată a proceselor
între noduri omogene (ultimele trei fiind
implementări pe o singură imagine de sistem);
 Microsoft Windows Compute Cluster Server bazat
pe platforma Windows Server furnizează pentru
clustere computaţionale facilităţi precum: Job
Scheduler, biblioteca MSMPI şi unelte de
administrare;
 gridMathematica realizează procesarea distribuită în
cluster pentru probleme precum analiza datelor,
algebră computerizată şi vizualizare 3D; Această
tehnologie poate utiliza şi tehnologii conjugate
precum: Altair PBS Professional, Microsoft
Windows Compute Cluster Server, Platform LSF şi
Sun Grid Engine.
 gLite este un set de tehnologii middleware create de
Enabling Grids pentru proiectul E-sciencE (EGEE);
 scheleţii algoritmici sunt un model de nivel înalt de
programare paralelă pentru sisteme paralele şi
distribuite care prezintă avantajul utilizării unor
modele comune de programare pentru a ascunde
complexitatea aplicaţiilor paralele sau distribuite;
Pornind de la un set de bază de modele (skeletons),
pot fi create modele mai complexe prin îmbinarea
celor de bază.
 Global Storage Architecture (GSA) este o soluţie
bazată pe NAS care combină tehnologie proprietară
82
IBM HPC (hardware de stocare şi server, GPFS) cu

elemente open source precum Linux, Samba şi
CTDB pentru a oferi soluţii de stocare distribuită.
GSA asigură disponibilitatea conţinutului sistemului
de fişiere cluster prin protocoale standardizate
precum: CIFS, NFS, FTP şi HTTP.
În prezent, cele mai multe sisteme situate în Top500
sunt sisteme de tip cluster, depăşind, astfel, sistemele propriu-
zise de înaltă performanţă. Tabelul 5 reprezintă distribuţia
tipurilor de arhitecturi în Top500.
Tabelul 5 – Clasificarea sistemelor din Top500 după tipul de sistem5

Arhitectură Număr Procent Rmax Total Rpeak Total Număr
de (GF) (GF) total de
sisteme procesoare
Cluster 417 83.4 137,210,293 214,082,469 12,148,616
Masiv 83 16.6 86,444,045 111,768,995 7,197,780
Parallel
Processing
După cum se poate observa din Figura 11, numărul de

clustere computaţionale intrate în Top500 a crescut constant
de-a lungul anilor, putându-se prognoza, pentru viitorul
apropiat, dominaţia acestora în domeniul procesării de
performanţă, eliminarea sistemelor de tip constelaţie şi
reducerea semnificativă a numărului de sisteme monolitice, de
înaltă performanţă.
5
83
Sistemele Top 500, după arhitectura folosită

100%
90% Date multiple pe o
80% singură instrucţiune
70%
60% Multiprocesor, date
50% multiple
40%
Cluster
30%
20%
10% Multiprocesor, date
0% simple
5/1/1993
6/1/1995
7/1/1997
8/1/1999
9/1/2001
1/1/2010
2/1/2012
12/1/2007
10/1/2003
11/1/2005
Constelaţie
Figura 11 – Arhitecturile utilizate la diverse momente de timp pentru

obţinerea de performanţe computaţionale crescute la sistemele din
Top500
Sisteme grid
Conceptul de prelucrare grid se referă la îmbinarea

resurselor computaţionale din mai multe domenii
administrative (proprietăţi) pentru a atinge un scop comun. Un
sistem grid poate fi privit ca un sistem distribuit ale cărui
sarcini componente sunt neinteractive şi care implică un număr
mare de fişiere. Diferenţa dintre sistemele grid şi sistemele
cluster provine din faptul că sistemele grid sunt slab cuplate,
eterogene şi dispersate geografic. Deşi un sistem grid poate fi
dedicat unei aplicaţii specializate, de obicei, un astfel de sistem
va fi utilizat în domenii şi scopuri diferite. De regulă, sistemele
84
grid sunt construite utilizând biblioteci software destinate

prelucrărilor grid, denumite middleware (Myerson, 2009).
Definiţii
Datorită faptului că nu există o definiţie unanim

acceptată pentru termenul de sistem grid, am ales din literatura
de specialitate mai multe definiţii care pot fi luate în calcul
pentru realizarea unei definiţii de sinteză.
În articolul “What is the Grid? A Three Point
Checklist”, Ian Foster afirmă că sistemele grid sunt sistemele
care prezintă următoarele proprietăţi: resursele de procesare nu
sunt administrate central; sunt utilizate standarde deschise; se
atinge o calitate a serviciului netrivială.
Plaszczak şi Wellner definesc tehnologia grid ca fiind
tehnologia care permite virtualizarea resurselor, furnizarea la
cerere şi distribuţia serviciilor sau a resurselor între organizaţii.
În concepţia IBM, prelucrarea grid reprezintă “abilitatea
ca utilizând un set de standarde şi protocoale deschise, să se
asigure acces la aplicaţii şi date, putere de procesare, capacitate
de stocare, precum la o serie de alte resurse de pe Internet. Un
sistem grid este un tip de sisteme paralele şi distribuite care
permit distribuirea, selecţia şi agregarea resurselor peste
multiple domenii administrative, bazate pe disponibilitatea,
capacitatea, costul resurselor şi cerinţele utilizatorilor de
calitate a serviciilor”.
Buyya şi Venugopal definesc sistemele grid ca “un tip
de sisteme paralele şi distribuite care permit distribuirea,
selecţia şi agregarea de resurse autonome, distribuite geografic,
85
în timpul rulării aplicaţiei, depinzând de disponibilitatea,

capacitatea, costul resurselor şi cerinţele utilizatorilor de
calitate a serviciilor” (o definiţie înrudită cu cea folosită de
IBM).
În cadrul CERN, sistemele grid sunt descrise ca “un
serviciu de distribuţie a puterii de prelucrare şi a capacităţii de
stocare pe Internet”.
În continuare sunt descrise, pe scurt, caracteristicile
sistemelor grid.
Dimensiunile sistemelor grid pot varia considerabil.
Sistemele grid pot fi descrise ca un super calculator
virtual compus din mai multe calculatoare slab interconectate
prin intermediul unei reţele care acţionează împreună.
Calculatoarele componente sunt calculatoare complete
care dispun de toate resursele necesare şi care pot fi folosite
independent de restul sistemului grid. Calculatoarele
componente pot fi achiziţionate ca echipamente destinate
utilizării obişnuite.
Legăturile între componente au performanţă redusă,
favorizând aplicaţiile în care prelucrările multiple pot avea loc
independent, fără a fi necesar să se comunice imediat
rezultatele între procese. În acelaşi timp acest lucru favorizează
dispersia geografică.
Din punct de vedere al programării, dacă problema este
paralelizată în mod adecvat, programe independente care
primesc ca date de intrare o porţiune diferită a aceleiași
probleme, pot rula pe maşini multiple. Acest lucru simplifică
dezvoltarea de aplicaţii faţă de cazul supercalculatoarelor sau al
clusterelor, făcând posibilă programarea şi depanarea pe o
86
singură maşină convenţională şi eliminând complicaţiile date

de concurenţa la resurse.
Consideraţii asupra arhitecturii
Una dintre proprietăţile sistemelor grid este faptul că ele

pot fi formate din resurse computaţionale care aparţin mai
multor indivizi sau organizaţii (multiple domenii
administrative). Acest lucru prezintă atât avantaje, cât şi
dezavantaje.
Avantajele sunt date de facilitarea tranzacţiilor
comerciale (cum ar fi în procesarea utilitară) şi de oferirea
posibilităţii creării reţelelor de sisteme ale voluntarilor.
Un dezavantaj este faptul că maşinile care realizează
prelucrările ar putea să nu fie de încredere. Din acest motiv,
proiectanţii sistemelor trebuie să introducă măsuri care să
prevină proasta funcţionare, să împiedice participanţii
răuvoitori să introducă rezultate false, derutante sau eronate şi
să împiedice utilizarea sistemului ca vector de atac. De cele
mai multe ori acest lucru este realizat prin asignarea aleatoare a
unor lucrări către diverse noduri (despre care se presupune că
au proprietari diferiţi) şi verificarea comparativă a rezultatelor
prelucrării aceleiaşi unităţi de date pe două noduri diferite.
Eventualele discrepanţe vor putea duce la identificarea
nodurilor care funcționează greşit sau care aparţin unor entităţi
răuvoitoare.
Un alt dezavantaj este că, în lipsa unui control central
asupra echipamentelor, nu se poate garanta funcţionarea
nodurilor pe un interval oarecare de timp. Mai mult decât atât,
87
unele noduri (precum maşinile portabile sau cele conectate prin

conexiune on-demand) ar putea fi disponibile pentru
prelucrarea propriu-zisă, dar nu şi pentru comunicaţii pentru
perioade de timp neprevizibile. Aceste diferenţe pot fi
diminuate prin asignarea unor lucrări de dimensiuni mai mari
(reducând în acest fel necesitatea de continuitate a
comunicaţiei) şi re-repartizarea lucrărilor atunci când un
anumit nod nu îşi comunică rezultatele în timpul prevăzut.
Impactul încrederii şi disponibilităţii asupra
performanţei oferite şi a dificultăţii de implementare poate
influenţa decizia proiectantului cu privire la arhitectură
utilizată către alegerea unui cluster dedicat, către utilizarea
maşinilor cu timpi idle din interiorul organizaţiei sau chiar
către externalizarea lucrărilor în defavoarea utilizării reţelelor
grid.
Problema încrederii poate privită şi din direcţie opusă,
în sensul că proprietarii nodurilor participante trebuie să aibă
încredere că sistemul central nu va abuza de accesul care îi este
acordat (interferând cu operarea altor programe, accesul
neautorizat sau distrugerea informaţiei stocate local, transmisia
de date private sau crearea de breşe de securitate). Unele
sisteme grid rezolvă această problemă reducând necesarul de
“încredere” pe care “clienţii” trebuie să o aibă în sistemul
central, prin utilizarea maşinilor virtuale.
De obicei, utilizarea maşinilor publice şi a celor
aparţinând mai multor domenii administrative (incluzând
departamente diferite ale aceleiaşi organizaţii) implică
necesitatea de a rula pe sisteme eterogene, cu diferite sisteme
de operare şi arhitecturi hardware. Cele mai multe limbaje de
88
programare realizează un schimb între investiţia în dezvoltarea

suplimentară a software-ului (pentru asigurarea portabilităţii
suplimentare) şi numărul de platforme care poate fi suportat
(care limitează dimensiunea sistemului grid rezultat).
Limbajele trans-platformă (de exemplu: Java) reduc
necesitatea acestui schimb, dar permit acest lucru, diminuând
performanţa pe oricare dintre noduri (datorită necesităţii
interpretării codului la momentul execuţiei sau lipsei de
optimizare pentru platforma respectivă).
Diverse proiecte middleware au creat infrastructuri
generice pentru a permite diferitelor proiecte ştiinţifice sau
comerciale să utilizeze sisteme grid pre-existente sau să creeze
sisteme grid noi.
Middleware-ul poate fi privit ca un nivel între hardware
şi software. În afară de middleware, trebuie asigurate şi alte
funcţii care pot fi implementate independent sau nu de
middleware. Dintre aceste funcţii se pot enumera:
managementul SLA, încrederea şi securitatea, managementul
virtual al organizaţiei, managementul licenţelor, managementul
portalurilor şi al datelor. De obicei, aceste funcţii sunt asigurate
prin intermediul soluţiilor comerciale.
Sistemele grid pot fi clasificate după diverse criterii. În
continuare sunt prezentate clasificările acestor sisteme după
stadiul de dezvoltare şi perspectiva de piaţă în care sunt
abordate.
După stadiul de dezvoltare, sistemele grid se împart în:
sisteme grid departamentale, sisteme grid de întreprindere şi
sisteme grid globale.
89
Sistemele grid departamentale corespund utilizării

iniţiale a resurselor din cadrul unui singur grup pentru crearea
unui sistem grid (spre exemplu un departament).
Sistemele grid de întreprindere cuprind resursele unei
companii, maşinile de calcul ale acesteia, servind în cadrul
gridului prin utilizarea timpilor idle şi a resurselor de stocare.
Sistemele grid globale cuprind maşini din cadrul mai
multor griduri departamentale şi de întreprindere şi pot fi
utilizate pentru scopuri comerciale sau colaborative.
Aşa cum am precizat anterior, un alt criteriu de
clasificare este cel al perspectivei de piaţă în care sunt
abordate sistemele grid.
Din perspectiva furnizorului, se pot distinge mai multe
pieţe / tipuri de produse specifice:
1. middleware-ul este un produs software specific,
comercializabil care permite distribuirea resurselor
eterogene şi crearea organizaţiilor virtuale; Acesta
se instalează şi este integrat în infrastructura
existentă a companiei / companiilor implicate şi
furnizează un nivel suplimentar între infrastructura
eterogenă şi diverse aplicaţii. Unele dintre cele mai
cunoscute produse de tip middleware sunt Globus
Toolkit, gLite şi UNICORE.
2. prelucrarea utilitară reprezintă furnizarea de putere
de calcul şi de aplicaţii în sistemele grid ca un
serviciu (poate fi o utilitate cu acces deschis sau un
serviciu de găzduire, pentru o organizaţie sau pentru
o organizaţie virtuală); Exemple de competitori pe
această piaţă sunt Sun Microsystems, IBM şi HP.
90
3. aplicaţiile capabile să ruleze în sisteme grid sunt

produse software specifice, capabile să utilizeze o
infrastructură de tip grid;
4. software-ul ca serviciu (Software as a Service -
SaaS) reprezintă oferirea accesului la utilizarea unui
“software care este deţinut, oferit şi administrat la
distanţă, de către unul sau mai mulţi furnizori”
(Gartner, 2007) ca un serviciu. În plus, aplicaţiile
SaaS ale unui furnizor sunt bazate pe un singur set
de cod comun şi definiţii de date. Serviciul respectiv
este utilizat într-un model unul-la-mai-mulţi şi se
foloseşte un sistem de plăţi periodice numit Pay As
You Go (PAYG), bazat pe perioada de timp cât este
utilizat. De asemenea, nu este obligatoriu ca
furnizorii de SaaS să deţină resursele hardware
necesare (ei pot utiliza în continuare prelucrarea
utilitară pentru a îşi acoperi necesarul de hardware).
Această perspectivă este folosită atât pentru
sistemele grid, cât şi pentru sistemele cloud.
Din perspectiva utilizatorului, utilizarea produselor /
serviciilor de tip grid disponibile pe piaţă are implicaţii
financiare şi de organizare diferite. Strategia de implementare
IT dorită de companie, precum şi volumul şi repartizarea în
timp a investiţiilor proiectate cu IT joacă un rol important în
nivelul de adoptare a sistemelor grid în organizaţie.
91
Utilizarea perioadelor de inactivitate ale procesorului
Conceptele de CPU-scavenging, cycle-scavenging,

cycle stealing sau shared computing semnifică crearea unui
sistem grid care să folosească resursele neutilizate dintr-o reţea
(reţea globală sau reţea internă a unei organizaţii). De fapt,
această tehnică foloseşte ciclurile de procesor neutilizate (în
timpul nopţii, în timpul meselor şi al pauzelor, în momentele în
care procesorul nu este utilizat intensiv).
Multe proiecte bazate pe voluntariat utilizează acest
model (de exemplu: BOINC).
În practică, calculatoarele participante donează nu
numai timpul de calcul, ci şi cantităţile de spaţiu de stocare,
RAM şi lăţimea de bandă necesare pentru suportul prelucrării
propriu-zise.
Performanţe obţinute prin utilizarea sistemelor grid
Datorită numărului extrem de mare de sisteme de calcul

componente, câteva dintre sistemele grid de dimensiuni foarte
mari au obţinut performanţe semnificativ mai bune decât cele
mai bune sisteme supercalculator prezente în Top500.
Topul performanţelor obţinute de sistemele grid:
1. Reţeaua Bitcoin - 144 PetaFLOPS
2. BOINC - 5.634 PetaFLOPS (la 4 aprilie 2011)
3. Folding@Home – 5 PetaFLOPS (la 17 martie 2009)
4. MilkyWay@Home - 1.6 PetaFLOPS (în aprilie
2010)
5. SETI@Home - 730 TeraFLOPS (în aprilie 2010)
92
6. Einstein@Home - 210 TeraFLOPS (în aprilie 2010)

7. GIMPS - 61 TeraFLOPS (în aprilie 2010)
Sisteme cloud
Termenul cloud presupune utilizarea mai multor

sisteme server care îndeplinesc aceleaşi funcţii, părând a fi o
singură entitate server în cadrul unei reţele. Potrivit literaturii
de specialitate, se consideră că şi serviciile oferite sunt
integrate în conceptul cloud (Mell & Grance, 2009).
Într-un mediu web tradiţional, un server web rulează pe
un calculator sau pe un grup de calculatoare. Această
configuraţie este proiectată astfel încât să fie capabilă ca,
pentru o anumită cantitate de cereri de serviciu pe unitatea de
timp, să poată să deservească aceste cereri, cu o anumită
latenţă, considerată a fi rezonabilă, pentru fiecare cerere. Dacă
numărul de cereri de serviciu pe unitatea de timp creşte peste
cantitatea proiectată, latenţa răspunsului la fiecare cerere va
creşte corespunzător (cazul extrem este aşa numitul Denial of
Service - DoS, situaţie în care latenţa este atât de mare, încât se
consideră că serverul respectiv nu mai răspunde cererilor de
serviciu). Dacă numărul de cereri scade sub cantitatea
proiectată, o bună parte din capacitatea serverului va rămâne
neutilizată (ThePicky, 2009).
În cazul unui sistem cloud, grupul de sisteme care
găzduieşte serverul web nu are o capacitate proiectată fixă,
acestuia adăugându-i-se sau retrăgându-i-se resurse (de
procesare, de transfer şi de stocare, sub formă de maşini
suplimentare şi / sau unităţi de calcul suplimentare), în funcţie
93
de numărul de cereri pe unitatea de timp. De fapt, resursele

utilizate pentru serverul web sunt folosite, în comun, pentru un
număr mare de servere web diferite, alocarea unităţilor de
resurse pentru unul sau altul dintre servere făcându-se dinamic,
în funcţie de încărcare. Plata pentru serviciul de găzduire a
serverului web este şi ea redimensionată corespunzător cu
încărcarea. Tocmai din pricina acestui model de plăţi (“Pay-
As-You-Go”), sistemele cloud au început să câştige în
popularitate (Wei, Pierre, & Chi, 2011).
Conform Institutului Naţional de Standarde şi
Tehnologii al S.U.A. (The National Institute of Standards and
Technology - NIST) termenul cloud se defineşte astfel:
“Procesarea cloud este un model care permite obţinerea, la
cerere, a unui acces de reţea convenabil, la un set distribuit de
resurse de prelucrare configurabile (de exemplu: reţele,
servere, stocare, aplicaţii şi servicii) care pot fi furnizate şi
recuperate rapid, cu un efort de management minim şi cu
interacţiune cu furnizorul de servicii redusă" (National Institute
of Standards and Technology, 2013).
Sistemele cloud diferă de modelul client-server clasic
prin faptul că aplicaţiile utilizate sunt furnizate de pe server şi
executate prin intermediul unui simplu browser web al
clientului, fără ca pe maşinile client să existe vreo aplicaţie
instalată.
Centralizarea îi asigură furnizorului de servicii cloud un
control complet asupra aplicaţiei care rulează pe partea de
client, eliminând, din punct de vedere al clientului, toate
problemele de management al licenţelor şi de upgrade al
versiunilor instalate. Ca şi la unele sisteme grid, conceptul
94
"Software as a Service" (SaaS) este utilizat pentru a descrie

modelul de afacere.
Modelul îi permite oricărui calculator pe care rulează
orice sistem de operare sau echipament cu abilităţi de navigare
(PDA, telefon mobil etc.) conectat la Internet, să aibă acces la
aceeaşi ofertă de putere de procesare, aplicaţii şi fişiere, în
mediul de operare al cloud-ului. De asemenea, pe lângă
utilizarea aplicaţiilor propriu-zise din cloud, utilizatorii pot
stoca şi accesa fişiere personale (documente, fişiere media
etc.), eliminând necesitatea stocării şi transportului datelor
personale pe suporturi precum discuri optice sau stick-uri.
În acelaşi timp, se consideră că introducerea serviciilor
cloud în activitatea companiilor este benefică şi din punctul de
vedere al securităţii şi respectării legalităţii, eliminându-se
interesul angajaţilor pentru introducerea la locul de muncă de
aplicaţii şi echipamente neverificate sau neconforme.
Din punct de vedere tehnologic, sistemele cloud
furnizează aplicaţiile bazate pe server, precum şi toate
serviciile de date necesare, numai datele de ieşire fiind afişate
pe echipamentele client. Resursele alocate aplicaţiei browser
(în principal memorie RAM) pe echipamentul client sunt
utilizate pentru operaţii de afişare, toate prelucrările şi
modificările realizându-se la nivelul serverului. De asemenea,
rezultatele finale care includ fişierele create ori modificate sunt
stocate permanent pe serverele cloud.
Totuşi, din cauza arhitecturii lor, performanţele
aplicaţiilor cloud sunt dependente de performanţa şi
disponibilitatea legăturii la Internet, dar şi de performanța în
procesare a maşinii client.
95
Un alt avantaj oferit de arhitectura cloud este

capabilitatea de a executa operaţii mari consumatoare de
resurse (cum ar fi: back-up-uri masive sau lucrări care
presupun calcule intensive), fără necesitatea deţinerii sau
utilizării directe a unei maşini de calcul foarte performante.
În concluzie, termenul cloud descrie un model nou de
punere la dispoziţie, livrare şi consum al serviciilor IT bazat pe
protocoale Internet, care implică, de obicei, resurse care pot fi
scalate dinamic şi care sunt de cele mai multe ori virtualizate.
Modelul se bazează pe uşurinţa accesului la resurse aflate la
distanţă, oferită de performanţele actuale ale Internetului (The
Economist, 2009).
În anumite cazuri este posibilă şi utilizarea de aplicaţii
din generaţiile mai vechi care sunt puse la dispoziţie prin
tehnologii de screen-sharing precum Citrix XenApp, dar în
majoritatea cazurilor, aplicaţiile sunt noi şi folosesc tehnologii
web cum ar fi AJAX.
Riscuri ale utilizării serviciilor cloud
Categoriile de riscuri la care pot fi expuşi utilizatorii

serviciilor cloud (Burtica, Mocanu, Andreica, & Tapus, 2012)
sunt reprezentate de: politicile de prag necorespunzătoare,
problemele de interoperabilitate, costurile ascunse,
comportamentele neaşteptate, securitatea informaţiei şi
protecţia datelor private, precum şi continuitatea serviciului.
Politicile de prag necorespunzătoare
Pentru a stabili care sunt momentele la care trebuie
alocate resurse suplimentare unui anumit serviciu sau
96
momentele la care diverse resurse pot fi eliberate, furnizorul de

servicii cloud foloseşte valori prag stabilite prin politici de
prag. Un potenţial utilizator al unui serviciu cloud ar trebui să
testeze modul în care operează aceste servicii, înainte de
contractarea propriu-zisă a serviciului (Tudorică, Challenges
for the NoSQL systems: Directions for Further Research and
Development, 2013).
Problemele de interoperabilitate
Utilizarea de către o întreprindere a doi sau mai mulţi
furnizori de servicii cloud sau schimbarea unui furnizor de
servicii cloud cu un altul ridică probleme de compatibilitate a
formatelor de date folosite de furnizori (Tudorică, Challenges
for the NoSQL systems: Directions for Further Research and
Development, 2013). Cei mai muţi furnizori de servicii cloud
utilizează API-uri bine documentate (având licenţe Creative
Commons), dar care sunt, de asemenea, şi unice în
implementare şi, deci, neinteroperabile. Pentru a elimina
această problemă, există un număr de standarde deschise, în
curs de dezvoltare, printre care şi Open Cloud Computing
Interface al OGF. De asemenea, Open Cloud Consortium
lucrează obţinerea unui consens pentru standarde şi practici în
domeniul sistemele cloud (Open Cloud Consortium, 1999).
Costurile ascunse
Serviciilor cloud prezintă şi costuri ascunse, cum ar fi
de exemplu: costurile companiei legate de comunicaţiile de
date care vor creşte, probabil, precum şi costurile indirecte
legate de timpii pierduţi din cauza latenţei la conectare, în
special, în momentele de vârf de trafic.
Comportamentele neaşteptate
97
Aplicaţiile furnizate ca serviciu pot avea un

comportament neaşteptat, în special dacă nu au mai fost
utilizate până atunci de companie (Tudorică, Challenges for the
NoSQL systems: Directions for Further Research and
Development, 2013).
Securitatea informaţiei şi protecţia datelor private
Utilizarea unui serviciu cloud pentru stocarea datelor
poate expune utilizatorul unei potenţiale violări a caracterului
privat al datelor. În acelaşi timp, furnizorul de servicii cloud
căruia utilizatorul îi încredinţează datele sale ar putea să fie
dintr-o altă ţară, cu legislaţie diferită. Un furnizor de servicii
cloud rău intenţionat poate accesa datele private ale
utilizatorilor pentru cercetări de piaţă sau pentru a stabili un
profil al utilizatorilor (Buyya, Yeo, & Venugopal, 2008). În
cazul accesării unui sistem cloud prin intermediul unei reţele
wireless, riscurile de securitate se măresc, din cauza securităţii
reduse oferite de reţelele wireless (nu trebuie uitat că, spre
deosebire de o arhitectură normală, în cazul utilizării serviciilor
cloud, toate datele vor fi vehiculate prin intermediul reţelei, nu
doar informaţiile de logare sau configurare). De asemenea,
furnizorul de servicii poate distruge sau însuşi voluntar datele
utilizatorului, situaţie care este cu atât mai greu de tratat, în
cazul unui serviciu transnaţional. O altă problemă care trebuie
tratată este problema spionajului economic care poate apărea
atunci când corporaţiile utilizează serviciile cloud. De
asemenea, este dificil sau imposibil ca utilizatorii să poată
consulta jurnalele de audit de securitate. Toate aceste probleme
pot fi soluţionate printr-o soluţie hibridă, şi anume: crearea
unor sisteme cloud private, utilizate de către o singură
98
companie care, astfel, îşi menţine controlul asupra

infrastructurii şi asupra securităţii informaţiei. Totuşi, această
soluţie elimină o bună parte din avantajele legate de cost. Alte
soluţii pentru diversele probleme de securitate ridicate de
arhitecturile cloud includ: utilizarea criptografiei (în mod
particular a Infrastructurii de Chei Publice - PKI), folosirea mai
multor furnizori de servicii cloud, standardizarea API-urilor,
îmbunătăţirea suportului pentru maşini virtuale şi oferirea de
suport legal (Zissis & Lekkas, 2012), (Messmer, 2009),
(Anthes, 2010).
Continuitatea serviciului
Ţinând cont de modul de operare a serviciilor cloud, un
număr mare de utilizatori ar putea fi limitaţi sever, în cazul
unei nefuncţionalităţi a acestor servicii sau a serviciilor de tip
ISP. Aceste evenimente pot avea ca efect o blocare completă a
activităţii. Pentru a preveni astfel de evenimente, sunt utilizate
la nivelul transport al stivei TCP / IP tehnologii precum:
Application Delivery Network - ADN, Content Delivery
Network - CDN şi accelerarea TCP.
Alături de aceste riscuri care afectează utilizatorii
serviciilor cloud, şi alte subiecte ar trebui tratate, din punctul de
vedere al modelului de servicii cloud în sine. Este vorba despre
protecţia mediului şi despre folosirea acestor servicii de către
hackeri.
Protecţia mediului
Furnizorii de servicii cloud susţin că soluţiile cloud sunt
ecologice, dar nu există încă niciun studiu oficial care să ateste
acest lucru, existând chiar unele indicii contrare (Urquhart,
2010). Locaţiile unde sunt găzduite serverele sunt afectate de
99
căldura generată şi necesită resurse puternice de energie

electrică, preferându-se, din acest motiv, ţările cu climat rece şi
resurse regenerabile de energie pentru a reduce efectele asupra
mediului. Datorită acestui aspect, ţările care au condiţii
favorabile precum Finlanda, Suedia şi Elveţia încearcă să
atragă instalarea de centre de date pentru servicii cloud pe
teritoriul lor (Wheeland, 2010).
Utilizarea serviciilor de către hackeri / crackeri
Indivizi care se dau drept clienţi legitimi pot achiziţiona
servicii cloud pentru operaţiuni ilegale, incluzând spargerea de
parole, infectarea de sisteme ţintă sau operaţiuni de tip Denial-
of-Service - DoS (Goodin, 2011).
Avantaje
Riscurile descrise anterior sunt contrabalansate de o

serie de avantaje specifice sistemelor de tip cloud, cele mai
importante fiind prezentate în continuare.
Furnizorii de servicii cloud susţin că prin utilizarea
acestor servicii se reduc sensibil costurile, prin eliminarea
totală sau parţială a costurilor de infrastructură, instruire şi
mentenanţă. Chiar dacă aceste afirmaţii nu au fost încă
verificate printr-un studiu oficial, este sigur faptul că se
modifică momentul în care se realizează cheltuielilor,
cheltuielile cu capitalul iniţial fiind înlocuite prin cheltuieli
operaţionale. Acest lucru se traduce în praguri mai joase de
iniţiere a unei afaceri. De asemenea, nivelul de calificare IT
necesar in-house este mai redus (Gens, 2008).
100
Un alt avantaj este reprezentat de independenţa de

echipamente şi de locaţii care permite desfăşurarea activităţii
oriunde este disponibilă o legătură la Internet (Farber, 2008).
Disponibilitatea creşte, dacă furnizorul de servicii
cloud utilizează multiple locaţii redundante, lucru benefic
pentru continuitatea afacerii şi care facilitează recuperarea după
un dezastru pentru utilizator (King, 2008).
Un alt aspect important este dat de faptul că furnizorul
de servicii cloud monitorizată permanent performanţa.
Nivelul de securitate ar putea fi la fel de bun sau mai
bun decât în cazul unei implementări tradiţionale datorită
centralizării datelor şi nivelului crescut de resurse dedicate
securităţii pe care şi-l pot permite furnizorii de servicii cloud.
Mentenanţa aplicaţiilor cloud este mai uşoară,
nemaifiind necesar să se instalaze aplicaţii de tip client fiecare
maşină de calcul. De asemenea, aceste aplicaţii sunt mai uşor
de depanat şi de îmbunătăţit, toate modificările propagându-se
instantaneu la clienţi.
Componente ale sistemelor cloud
Un model generic al unui sistem cloud cuprinde

următoarele componente: furnizorul, utilizatorul, sistemul
client, aplicaţia, platforma, infrastructura şi serverul.
Furnizorul este organizaţia care furnizează servicii
cloud.
Utilizatorul reprezintă individul sau organizaţia care
utilizează servicii cloud.
101
Sistemul client este alcătuit din hardware şi / sau

software specializat, depinde de sistemul cloud pentru livrarea
aplicaţiilor şi este inutilizabil în absenţa acestuia. Un termen
înrudit este Cloud Desktop as a Service (CDaaS) sau Hosted
Desktop care se referă la containerul unei colecţii de obiecte
virtuale, software, hardware, configuraţii etc. care sunt stocate
în cloud şi care sunt utilizate de client pentru interacţiunea cu
servicii la distanţă şi pentru efectuarea de diverse operaţii.
Aplicaţia este denumirea alternativă pentru termenul
Software as a Service (SaaS) descris anterior.
Platforma - prescurtarea conceptului Platform as a
Service (PaaS) - constă în furnizarea unei platforme de
prelucrare sau stivă de soluţii ca un serviciu. Poate fi
comercializat direct ca serviciu sau, în cele mai multe cazuri,
este utilizat pentru susţinerea aplicaţiilor. Individualizarea
acestei componente facilitează dezvoltarea aplicaţiilor,
eliminând costurile de achiziţie şi de administrare pentru
nivelurile de hardware şi software pe care le maschează (AWS,
2008).
Infrastructura care reprezintă denumirea prescurtată
pentru conceptul Infrastructure as a Service (IaaS) desemnează
o infrastructură virtualizată de sistem de calcul furnizată ca
serviciu. Poate fi achiziţionată direct de către un client sub
forma unei utilităţi, în locul achiziţionării de hardware şi
software server. De obicei, facturarea realizează în funcţie de
resursele utilizate. IaaS a evoluat din serviciile de găzduire pe
servere private virtuale (Pariseau, 2008). De asemenea, este
utilizată ca serviciu consumat intern de sistemul cloud. De
regulă, IaaS este centru de date stratificat pe trei nivele sau
102
chiar pe patru nivele, compus din zeci sau sute de maşini

virtuale.
Serverul este alcătuit din hardware şi / sau software
proiectat special pentru funcţionarea în sisteme cloud,
incluzând sisteme multiprocesor şi sisteme de operare
specializate pentru cloud (Myslewski, 2009), (Duffy, 2009).
În
Hardware şi software la utilizator Client (CdaaS)
Aplicaţie (SaaS)
Platformă (PaaS)
Hardware şi software la furnizor
Infrastructură (IaaS)
Server
Figura 12 este reprezentat un model al unui sistem
cloud, cu cele 5 componente tehnice şi cele 2 entităţi
participante la tranzacţie.
Hardware şi software la utilizator Client (CdaaS)
Aplicaţie (SaaS)
Platformă (PaaS)
Hardware şi software la furnizor
Infrastructură (IaaS)
Server
Figura 12 – Model generic al unui sistem cloud
103
Tipuri de sisteme cloud
Sistemele cloud pot fi clasificate în patru categorii:

sisteme cloud publice, sisteme cloud comunitare, sisteme cloud
hibride şi sisteme cloud mixte.
Sistemele cloud publice reprezintă sistemele cloud în
sensul tradiţional, aşa cum sunt ele descrise anterior.
Sistemele cloud comunitare pot fi stabilite între două
sau mai multe companii care au cerinţe similare şi vor să îşi
partajeze infrastructurile pentru a profita de câteva dintre
beneficiile sistemelor cloud. Această modalitate de construcţie
nu este la fel de eficientă din punct de vedere al costurilor ca
un sistem cloud public, însă oferă nivele crescute de securitate,
protecţie a informaţiilor private şi complianţă. Poate deveni un
model mai eficient din punct de vedere al costurilor, dacă sunt
utilizate maşini de calcul şi alte resurse deja aflate în uz şi
amortizate. Un exemplu de astfel de cloud este "Gov Cloud"
construit de Google.
Sistemele cloud hibride se pot adopta în instituţiile în
care, încă, sunt utilizate servicii tradiţionale, bazate pe
infrastructură localizată, fiind compuse din servicii cloud (fie
proprii, fie exterioare) şi servicii tradiţionale in-house. Acestea
sunt cunoscute şi sub denumirea de hybrid delivery, principalii
producători (HP, IBM, Oracle, VMware şi Fujitsu) oferind
soluţii tehnologice pentru managementul performanţei,
securităţii şi protecţiei datelor private, în cadrul unor astfel de
medii de prelucrare mixte. La rândul lor, aceste sisteme se
împart în:
104
 sistemele cloud hibride de stocare includ soluţii de

stocare interne, dar şi stocare în sisteme cloud
publice; De obicei, sunt utilizate pentru arhivare şi
backup (Storage Networking Industry Association).
 sistemele cloud hibride de găzduire web constau în
mixuri de găzduire cloud şi sisteme server interne
pe care sunt găzduite pagini / aplicaţii web.
Sisteme cloud mixte sunt alcătuite din două sau mai
multe sisteme cloud folosite combinat, pentru obţinerea
diverselor servicii necesare.
Conformitatea cu reglementările în vigoare
Pentru a respecta reglementările în vigoare (FISMA,

HIPAA şi SOX în Statele Unite ale Americii, Data Protection
Directive în Uniunea Europeană sau regulamentele PCI DSS
aplicate în industria cardurilor bancare), utilizatorii sistemelor
cloud sunt, de obicei, obligaţi să adopte arhitecturi cloud
comunitare sau hibride care sunt, în general, mai scumpe şi
oferă mai puţine beneficii. Astfel, Google afirmă faptul că este
capabil să îndeplinească cerinţele regulamentului federal
FISMA (Howard, 2009), iar Rackspace Cloud precizează
conformitatea cu PCI (Rackspace, 2009).
Clienții din Uniunea Europeană care utilizează servicii
cloud de la furnizori din afara UE trebuie să respecte legislaţia
Uniunii Europene cu privire la exportul de date personale
(Helbing, 2010).
Anumiţi furnizori de servicii cloud au obţinut certificări
SAS 70 Type II (de exemplu: amazon.com, salesforce.com,
105
google.com şi Microsoft). Însă, aceste certificări sunt criticate,

din cauza varietăţii şi a lipsei de transparenţă a normelor de
certificare utilizate de către auditori.
Utilizarea Open Source
Software-ul open source a stat la baza implementării

mai multor sisteme cloud, cel mai cunoscut fiind, probabil,
frameworkul Hadoop.
În noiembrie 2007, Free Software Foundation a publicat
licenţa de tip Affero General Public License, o versiune a
GPLv3 care să trateze aspectele legale implicate de utilizarea
software-ului open source într-un mediu interconectat
(O'Grady, 2009). Alte platforme open source disponibile pentru
utilizarea în cloud sunt: AppScale, CloudFoundry, OpenShift şi
Heroku.
2.1.3 Utilizarea unor mijloace alternative de creștere a

performanței
În literatura de specialitate sunt studiate metodele de

creştere a performanţei unui sistem de prelucrare a informaţiei
care se bazează pe optimizări şi algoritmi alternativi (algoritmi
clasici, algoritmi preluaţi din inteligenţa artificială etc.), însă
acestea nu constituie obiectul de studiu al cercetării curente
efectuate de autor. În cadrul acestui subcapitol este tratată o
clasă de metode de prelucrare apărute recent care determină o
creştere importantă a performanţei cu costuri relativ
nesemnificative. Este vorba de metodele cunoscute sub numele
106
generic de Prelucrări de Tip General utilizând Unităţi de

Procesare Grafică (General-Purpose computing on Graphics
Processing Units – GPGPU, GPGP sau GP²U).
Dacă GPU se ocupă, de obicei, doar cu prelucrările
necesare pentru grafica pe calculator, GPGU reprezintă tehnica
utilizării GPU pentru a efectua prelucrări executate de către
CPU, în mod tradiţional. Acest lucru este posibil datorită
adăugării la pipeline-urile de randare din GPU de ultimă
generaţie a unor faze programabile şi a unor unităţi aritmetice
de precizie mai mare, componente care permit dezvoltatorilor
software să utilizeze GPU pentru procesarea unor date diferite
de cele grafice.
Din Tabelul 6 se poate observa că 43 de sisteme din
totalul de 500 analizate utilizează echipamente de tip
coprocesor grafiv, acest aspect indicând eficienţa utilizării
GPGPU pentru creşterea performanţelor de procesare. Deşi
procentul nu este ridicat, el este, totuşi, semnificativ, tinând
cont de faptul că primele sisteme de performanţă înaltă cu acest
tip de accelerare au intrat în Top 500 în iunie 20106.
Tabelul 6 – Procesoare grafice utilizate ca acceleratoare pentru

sistemele de înaltă performanţă (GPGPU) 7
Număr
Tip de Procentaj
de Rmax Rpeak Număr de
accelerator în Top
sisteme (GFlops) (GFlops) nuclee
utilizat 500 (%)
din Top
6
Rezultat al analizei efectuate pe datele din SCS, Development over Time,
Top 500 SuperComputer Sites, 2013
7
107
500
N/A 446 89.2 148,187,171 200,527,111 13,894,107
Nvidia
31 6.2 12,106,171 24,481,254 905,202
Fermi
Intel Xeon
11 2.2 42,131,863 67,790,175 3,830,503
Phi
Nvidia
8 1.6 20,094,200 30,957,401 645,340
Kepler
ATI Radeon 3 0.6 938,700 1,832,963 62,832
Hybrid 1 0.2 196,234 262,560 8,412
Termeni utilizaţi
Pipeline este un set de elemente de procesare a datelor

conectate în serie, astfel încât ieşirea unui element constituie
intrarea pentru elementul următor. De regulă, prelucrările dintr-
un pipeline sunt executate în paralel sau în aceeaşi cuantă de
timp. De obicei, sunt inserate buffere mici de stocare între
elemente.
Vertex este o structură de date care descrie un punct
într-un spaţiu 2D sau 3D, în grafica computerizată. Obiectele
sunt compuse din matrici de suprafeţe bidimensionale
elementare (de obicei triunghiuri), iar verticele definesc poziţia
şi alte atribute ale colţurilor acestor suprafeţe.
Randarea reprezintă procesul de generare
computerizată a unei imagini dintr-un model sau un set de
modele care constituie o scenă. Fişierele care descriu scenele
includ obiecte descrise într-un limbaj de descriere sau o
108
structură de date. Un astfel de fişier va conţine informaţii

geometrice, de punct de vizualizare, texturi, iluminare şi
umbre.
Shader este un set de instrucţiuni software utilizate
pentru a calcula efecte de randare cu un anumit grad de
flexibilitate, utilizând hardware-ul grafic. Shader-ele sunt
folosite pentru programarea pipeline-urilor din GPU. Prin
intermediul shader-elor, efectele aplicate pot fi personalizate.
Tipuri de date disponibile
Adaptoarele grafice anterioare DirectX 9 acceptau doar

tipuri de date care descriau culori paletate sau cu valori întregi,
cele mai cunoscute formate utilizate fiind:
 valoare întreagă pe 8 biţi pentru descrierea culorii
unui pixel – fie este vorba de indexul culorii într-un
tabel de culori, fie este vorba de o culoare
compozită în care componenta de roşu este descrisă
pe 2 biţi, cea de verde pe 3 biţi şi cea de albastru pe
3 biţi;
unui pixel – este vorba de o culoare compozită în
care componenta de roşu este descrisă pe 5 biţi, cea
de verde pe 6 biţi şi cea de albastru pe 5 biţi;
unui pixel – este vorba de o culoare compozită în
care componentele de roşu, verde şi albastru sunt
fiecare descrise pe 8 biţi;
109

unui pixel – câte 8 biţi pentru roşu, verde şi albastru
şi încă 8 biţi pentru componenta alpha
(transparenţă).
Această reprezentare este suficientă pentru a realiza
reprezentări grafice elementare, dar nu se poate utiliza pentru a
realiza prelucrări de tip general, lipsind orice tip de date
numeric în virgulă mobilă.
DirectX 9 Shader Model 2.x acceptă şi două tipuri de
date numerice în virgulă mobilă de precizii diferite, denumite
precizie completă şi parţială (prima dintre ele echivalentă
oarecum cu simpla precizie, iar cea de a doua fiind un tip de
date cu domeniu mai restrâns). Tipul de date pentru precizie
completă era fie FP32, fie FP24 (floating point, 32 de biţi sau
24 de biţi per componentă), fie chiar mai mare, iar tipul de date
pentru precizie parţială era FP16.
Un alt element semnificativ este faptul că deşi FP64 (tip
numeric cu virgulă mobilă, dublă precizie) este disponibil pe
majoritatea absolută a CPU actuale, el este recunoscut doar de
unele GPU (conforme cu IEEE sau nu). Au existat încercări de
emulare a tipurilor în dublă-precizie pe GPU care nu au această
abilitate, dar pierderea de viteză dată de procesul de emulare
anulează beneficiile de viteză date de utilizarea GPU în locul
CPU (Goddeke, Strzodka, & Turek, 2005).
Biblioteci pentru prelucrări de tip general
Cele mai multe operaţii efectuate de un GPU se

realizează într-un mod vectorizat: o singură operaţie poate fi
110
efectuată pe maximum 4 valori simultan, depinzând de

generaţia GPU. Această funcţionare este utilă în grafica
computerizată, pentru că aproape toate tipurile de date de bază
utilizate sunt vectori cu 2 până la 4 elemente. Modul vectorial
de prelucrare poate fi utilizat şi de alte tipuri de aplicaţii,
procesarea SIMD fiind disponibilă de mult timp în CPU.
În ultimii ani, companiile au lansat pe piaţă biblioteci
pentru diverse limbaje de programare, în scopul folosirii
acestor operaţii şi pentru prelucrările de tip general.
În noiembrie 2006, Nvidia a lansat CUDA, un pachet
conţinând un SDK şi un API care permit crearea în limbajul C
de secvenţe de cod care pot fi executate de GPU de pe plăcile
Nvidia GeForce (Owens, Davis, & Luebke, 2013).
De asemenea, AMD oferă un pachet SDK+API pentru
GPU produs de fosta companie ATI (acum parte a AMD);
pachetul respectiv este denumit FireStream SDK şi este
proiectat pentru a fi competitorul direct al Nvidia CUDA
(Advanced Micro Devices, 2013).
OpenCL produs de Khronos Group este proiectat pentru
a fi utilizat împreună cu OpenGL pentru unificarea extensiilor
limbajului C create pentru diferitele arhitecturi; recunoaşte atât
GPU Nvidia, cât şi GPU AMD / ATI, dar şi majoritatea CPU
(Xu, 2010).
Concepte de programare GPGPU
GPU sunt proiectate, în special, pentru prelucrări

grafice şi, din acest motiv, sunt foarte restrictive în termeni de
operare şi de programare. Din acestă cauză, GPU sunt eficiente
111
doar atunci când este vorba de probleme care pot fi rezolvate

prin prelucrarea stream-urilor, iar hardware-ul din GPU nu
poate fi folosit decât în anumite moduri.
Prelucrarea stream-urilor
GPU pot procesa numai vertice şi fragmente

independente, însă ele au avantajul că pot procesa multe
elemente de acest tip, în paralel. Acest lucru se realizează
efectiv, atunci când programatorul doreşte prelucrarea similară
a mai multor vertice sau fragmente. Din acest punct de vedere,
GPU sunt procesoare de stream care operează în paralel,
executând un singur kernel în acelaşi timp, pe multe înregistrări
dintr-un singur stream.
Conceptul de stream descrie un set de înregistrări care
necesită prelucrări similare. Stream-urile furnizează
paralelismul datelor. Kernel-urile sunt funcţii care se aplică
fiecărui element din stream. Pentru GPU, verticele şi
fragmentele sunt elemente din stream, iar shader-ele de
fragment şi de vertex sunt kernel-urile care vor fi executate
asupra elementelor din stream. În momentul în care GPU
procesează independent aceste elemente, nu mai există nicio
posibilitate de a avea la acest nivel date statice sau date
utilizate în comun. Pentru fiecare element în parte, singura
posibilitate de lucru este citirea din intrare, prelucrarea, urmată
de scrierea în ieşire. Se acceptă intrări sau ieşiri multiple, dar
nu se acceptă date care să poată fi folosite simultan ca intrări şi
ieşiri.
112
Intensitatea aritmetică se defineşte ca numărul de

operaţii care pot fie efectuate pe cuvânt de memorie transferat.
Ţinând cont de modul de lucru descris anterior, este important
pentru operaţiile din aplicaţiile GPGPU să aibă intensitate
aritmetică mare (necesar de citiri / scrieri cât mai redus per
operaţie de prelucrare), altfel sporul de viteză va fi redus de
latenţele date de accesul la memorie (Asanovic, et al., 2009).
Astfel, se poate concluziona că aplicaţiile care se
pretează cel mai bine la utilizarea GPGPU vor avea seturi de
date de mari dimensiuni, paralelism înalt şi dependenţă minimă
între elemente.
Concepte de programare a GPU
Resurse computaţionale
GPU poate utiliza următoarele resurse computaţionale:

 procesoare programabile – vertice, primitive şi
pipeline-uri de fragmente care permit unui
programator să execute kernel-uri pe stream-uri de
date;
 raster-izoare – creează fragmente şi interpolează
atribute la nivel de vertex, cum ar fi: coordonate de
textură şi culori;
 unitatea de textură – interfaţă read-only cu
memoria;
 framebuffer – interfaţă write-only cu memoria.
Există şi posibilitatea de înlocuire a framebuffer-ului cu
o textură write-only. Acest lucru se poate îndeplini prin
113
apelarea uneia dintre funcţiile Render to Texture (RTT),

Render-To-Backbuffer-Copy-To-Texture (RTBCTT) sau a mai
recent introdusei structuri de date stream-out.
Texturile ca stream
Cea mai cunoscută modalitate de utilizarea a unui

stream în GPGPU este reprezentată de asimilarea stream-ului
cu o matrice bidimensională, acest lucru potrivindu-se, în mod
natural, cu modelele de randare implementate în GPU. Multe
prelucrări de tip general utilizează matrici bidimensionale:
algebră matriceală, procesarea imaginii, simulări fizice ş.a.m.d.
Atunci când texturile sunt utilizate ca memorie,
apelurile de textură vor fi folosite ca citiri ale memoriei. Aceste
echivalenţe asigură faptul că anumite operaţii vor fi executate
automat de către GPU, nemaifiind nevoie de o implementare
explicită a acestora.
Kernel-urile
Kernel-urile pot fi privite ca secvenţe de cod din

interiorul unei iteraţii. La utilizarea unui GPU, se va specifica
doar secvenţa de cod din interiorul iteraţiei şi setul de date pe
care aceasta va fi aplicată, urmând ca iteraţia să fie
implementată, implicit, de mecanismele native de lucru ale
GPU, prin invocarea unei prelucrări grafice.
114
Controlul execuţiei
Se poate controla execuţia programului în codul

executat secvenţial, prin intermediul structurilor condiţionale
ramificate şi a celor repetitive. Aceste structuri de control,
native pentru prelucrările pe CPU, au fost adăugate recent pe
GPU (Harris & Buck, GPU Gems 2, Chapter 34, 2010) (în
implementările anterioare, scrierile condiţionate ar fi putut fi
implementate prin prelucrări aritmetice la nivel de bit, dar nu
exista această posibilitate pentru iteraţie şi ramificare
condiţionată). GPU de ultimă generaţie permit ramificarea
condiţionată, dar acest lucru este însoţit, ca şi la CPU, de o
scădere a performanţei. Din acest motiv, ar trebui evitată
ramificarea în interiorul iteraţiilor, indiferent dacă este vorba
de prelucrări executate pe CPU sau pe GPU. Atunci când nu
există un suport hardware în această direcţie, se pot utiliza
diferite tehnici precum: rezoluţia statică a ramificaţiilor (static
branch resolution), pre-calcularea (pre-computation), predicaţia
(predication), separarea iteraţiilor (loop splitting) (Suleman,
2011) şi Z-cull (Owens, et al., 2007).
Operaţii executate de GPU

GPU poate executa următoarele tipuri de operaţii:
maparea, reducţia, filtrarea unui stream, împrăştierea,
colectarea, sortarea şi căutarea.
Operaţia de mapare aplică acelaşi tip de prelucrare
tuturor elementelor dintr-o matrice. Multiplicarea tuturor
valorilor dintr-un stream cu o constantă reprezintă un tip de
115
mapare. Maparea se implementează firesc pe GPU, acest lucru

constând în aplicarea unui kernel elementelor dintr-un stream.
Reducţia este operaţia care operaţia care permite
separarea unui stream de dimensiuni mai reduse (posibil chiar
de un singur element) dintr-un stream mai mare. În general,
reducţia are o implementare recursivă, fiecare stream de
dimensiune mai mică obţinut putând fi intrarea pentru
generarea unui stream de dimensiune şi mai mică.
Filtrarea unui stream reprezintă, în esenţă, o formă
neuniformă de reducţie. Filtrarea implică eliminarea
elementelor din stream care îndeplinesc anumite criterii.
Operaţia de împrăştiere se defineşte la nivelul GPU de
shader-ul de vertex. Acesta poate să modifice poziţia
vertexului, operaţie echivalentă cu controlul locaţiei în care va
fi depozitată informaţia în matrice. De asemenea, alte extensii
sunt posibile, cum ar fi: controlul dimensiunii ariei afectate de
un vertex (echivalentă cu controlul numărului de elemente
învecinate din matrice afectate de o operaţie). Shader-ul de
fragmente nu poate efectua, direct, operaţii de împrăştiere din
cauza faptului că locaţia fiecărui fragment în matrice este fixată
la crearea fragmentului şi nu poate fi afectată programatic.
Procesorul de fragmente poate citi texturi în mod
aleator, fiind astfel posibilă colectarea datelor dintr-un subset
oarecare al matricei de date vizate.
Operaţia de sortare transformă un set neordonat de
elemente într-un set ordonat. Cele mai multe implementări ale
sortării pe GPU sunt bazate pe reţele de sortare (Owens, et al.,
2007).
116
Căutarea permite programatorului să găsească un

element particular sau elementele vecine unui anumit element
particular într-un stream. Această abilitate a GPU nu se referă,
în principal, la accelerarea căutării unui element individual, ci
la posibilitatea de a rula un număr mare de căutări, în paralel.
Structuri de date
Prin utilizarea de GPU pot fi manipulate diverse

structuri de date:
 matrici dense;
 matrici rare;
 structuri adaptive.
Aplicaţii în care se utilizează GPGPU
Până în acest moment au fost realizate implementări

care utilizează GPGPU pentru următoarele aplicaţii:
criptografie şi criptanaliză (implementările metodelor MD6,
AES, DES, RSA, ECC, spargerea parolelor); partea de calcul
SHA256 din metoda Bitcoin peer-to-peer currency; accelerarea
MATLAB utilizând Parallel Computing Toolbox şi MATLAB
Distributed Computing Server, dar şi pachete din terţe surse
cum ar fi: Jacket; algoritmul k-nearest neighbour; clustere şi
sisteme bazate pe procesare paralelă (supercalculatoare care
utilizează Message Passing Interface şi Single-System Image);
procesare distribuită, Beowulf; procesare grid; ferme de servere
(clustere de balansarea încărcării); simulări de sisteme fizice
(Conway's Game of Life, simularea ţesăturilor, curgerea
117
fluidelor necompresibile - ecuaţiile Navier-Stokes); fizică

statistică (modelul Ising); teoria distanţei laticelor; segmentare
– 2d şi 3d; metode nivel-mulţime; reconstrucţie CT;
transformări Fast Fourier; maparea tonurilor; calcul ştiinţific
(simularea Monte Carlo a propagării luminii); prognoza vremii;
cercetări climatice; modelare moleculară; mecanică cuantică;
astrofizică; bioinformatică; procesarea semnalului audio
(procesarea efectelor audio şi de sunet – procesarea digitală a
semnalului); procesarea analogică a semnalului; procesarea
vorbirii; procesarea imaginilor digitale; procesare video
(decodare video şi post-procesare (compensarea mişcării)
accelerată hardware video decoding, transformarea inversă
discretă cosine (iDCT), decodare pe lungime variabilă (VLD),
cantitatizare inversă (IQ), deblocare în buclă, procesarea
stream-urilor de biţi (CAVLC / CABAC), deîntreţesere,
deîntreţesere spaţio-temporală, reducerea zgomotului,
amplificarea marginilor, corecţia culorii); codare şi pre-
procesare accelerată hardware; Raytracing; iluminare globală
(maparea fotonilor, radiozitate, împrăştierea pe subsuprafeţe);
calcul geometric (geometria constructivă a solidelor, câmpuri
de distanţă detecţia coliziunilor, calculul transparenţei,
generarea umbrelor); finanţe computaţionale; imagerie
medicală; vizualizare computerizată; procesarea semnalului /
procesarea semnalului digital; proiectarea controalelor; reţele
neuronale; operaţii cu baze de date; metodele laticeale
Boltzmann; automatizarea proiectării în domeniul electronicii;
aplicaţii antivirus; detecţia intruziunilor.
118
2.2 Prelucrarea volumelor mari de date structurate
Conceptul de date structurate este asimilat, de regulă,

cu termenul de de baze de date, în sensul tradiţional al acestuia,
deşi termenii nu sunt sinonimi. Tinând cont de şi de faptul că
bazelor de date utilizate în aplicaţii comerciale sunt, în
principal, baze de date relaţionale, se poate spune că atunci
când se vorbeşte despre date structurate, în majoritatea
cazurilor se vorbeşte, de fapt, despre date stocate în baze de
date relaţionale.
De obicei, aplicaţiile tranzacţionale construite cu baze
de date relaţionale (aplicaţiile On Line Transactional
Processing- OLTP) nu stochează şi nu manipulează volume
foarte mari de date şi, din acest motiv, nu fac obiectul acestei
lucrării.
Spre deosebire de acestea, aplicaţiile de tip depozite de
date construite folosind, în principal, baze de date relaţionale
manipulează şi analizează volume mari de date. De asemenea,
pe piaţă sunt disponibile şi implementări care au la bază şi alte
modele de date, însă acestea nu au o cotă semnificativă de
piaţă. În Figura 13 se poate observa faptul că soluţiile de vârf
sunt cele furnizate de companiile Teradata, Oracle, IBM,
Microsoft şi SAP, toate acestea fiind construite pornind de la
baze de date relaţionale (Woodie, 2013).
119
Modernitatea soluţiei
Facilităţi oferite
Figura 13 – Prezenţa pe piaţă a diverselor soluţii comerciale de tip
depozit de date (februarie 2016)
În evoluţia domeniului depozitelor de date s-au
înregistrat două perioade importante: perioada depozitelor date
tradiţionale, cunoscută şi sub numele şi generaţia 1.0, care a
început în momentul apariţiei celor două definiţii şi filosofii
concurente ale depozitelor de date elaborate de William H.
Inmon şi Ralph Kimball (Inmon, Building the Data Warehouse,
2002) (Kimball & Ross, 2002) şi perioada celei de-a doua
generaţii de depozite de date, denumită şi generaţia 2.0,
descrisă de Inmon (Inmon, DW 2.0 - Architecture for the Next
120
Generation of Data Warehousing, 2006) şi care a început,

oficial, odată cu propunerea unei arhitecturi complet noi pentru
depozitele de date (Inmon, Strauss, & Neushloss, DW 2.0: The
Architecture for the Next Generation of Data Warehousing,
2010).
În cadrul acestui subcapitol se analizează cele două
perioade din evoluţia depozitelor de date, în general, precum şi
diferenţele dintre acestea, în special, pentru că în prezent îşi
face apariţia o nouă generaţie de depozite de date care
integrează structura tradiţională a depozitelor de date cu
avantajele oferite de bazele de date de tip NoSQL. Soluţiile
hibrid depozit de date – bază de date NoSQL sunt tratate
detaliat în subcapitolul 4.1 al acestei lucări.
2.2.1 Depozite de date tradiţionale (generaţia 1.0)
Arhitectura datelor
Proiectarea arhitecturii unui depozit de date presupune

efectuarea unor etape cheie care sunt necesare pentru achiziţia,
modelarea, curăţarea, pre-procesarea, procesarea şi integrarea
datelor din diverse surse, pentru obţinerea unui depozit de date
de întreprindere (Inmon, Building the Data Warehouse, 2002)
(Krishnan, 2013):
1. analiza cerinţelor de afacere;
În această etapă cerinţele sunt colectate din diverse
surse din întreprindere. Cerinţele trebuie să reflecte
necesităţile de date din perspectiva analizelor necesare,
precum şi necesităţile de disponibilitate, accesabilitate
şi securitate a datelor.
121
2. analiza datelor
Datele din diverse surse OLTP sunt analizate pentru a
evidenţia tipurile de date, regulile de afacere, calitatea
şi granularitatea datelor. La acest pas vor fi descoperite
şi documentate orice fel de cerinţe speciale.
3. modelarea datelor
Modelele datelor din aplicaţiile OLTP sursă sunt
mapate la un model al depozitului de date care, de
obicei, este un model relaţional, aşa cum s-a precizat
anterior. Modelul destinaţie poate fi un model de date în
FN 3, o schemă stea / galaxie sau un „fulg de zăpadă”.
De asemenea, în această etapă sunt proiectate zonele
cheie din depozitul de date, în funcţie de subiectul
analizelor dorite şi, respectiv, relaţiile între aceste zone.
Tot în această etapă, se definesc ierarhiile, se realizează
proiectarea fizică a bazei de date utilizate, se creează
zona de acumulare a datelor şi schema depozitului de
date. În cazul în care va fi utilizat un Operational Data
Store (ODS), cunoscut şi sub numele de magazin de
date operaţional care reprezintă o bază de date care
integrează date din multiple surse, atunci se defineşte şi
se creează modelul ODS-ului.
4. mutarea datelor
Această etapă presupune proiectarea, dezvoltarea şi
implementarea activităţilor de extragere, încărcare şi
transformare a datelor. Ea este împărţită în trei procese
distincte: extragerea datelor din surse, încărcarea zonei
de acumulare, extragerea datelor din zona de acumulare
şi încărcarea depozitului de date, precum şi
122
transformarea datelor încărcate în depozitul de date de

la modelul din aplicaţiile OLTP sursă, la modelul
specific depozitului de date. Datele eronate generate în
această etapă a prelucrării, sunt colectate şi prelucrate
ulterior. Pe parcursul desfăşurării celor trei procese,
mutarea şi prelucrarea datelor este verificată din punct
de vedere al acurateţii datelor şi al conservării cantităţii
de date.
5. calitatea datelor
Această etapă se execută atât în timpul operaţiilor de
extragere, transformare şi încărcare (Extract-
Transform-Load –ETL), cât şi în zona de acumulare a
datelor. Datele din diverse surse sunt analizate pentru a
elimina orice elemente care ar putea duce la coruperi de
date sau probleme de integritate referenţială. Se pot
utiliza în această fază diverse unelte de control al
calităţii datelor (de exemplu: Halo BI, Siebel Data
Quality, Trillium Software). Este important să se
descopere şi să se marcheze toate erorile apărute în
această etapă, pentru a putea fi reprocesate.
6. transformarea datelor
Sunt aplicate toate regulile de transformare a datelor de
la zona de acumulare la depozitul de date. De
asemenea, se realizează agregări şi sumarizări de date,
precum şi criptarea datelor.
7. prezentarea datelor
În această etapă se pregătesc straturile semantice şi
vizualizările pentru accesul utilizatorilor şi se aplică
123
regulile de securitate (autorizare, identificare,

autentificare, acces).
Infrastructură
Pentru a putea funcţiona corespunzător, un depozit de

date trebuie să aibă o infrastructură complexă (Figura 14) a
cărei arhitectură minimală trebuie să conţină următoarele
componente (Krishnan, 2013):
 sisteme sursă;
 sisteme de transfer al datelor de tip Extract-Transfer-
Load / Change Data Capture - ETL / CDC şi, respectiv,
Extract-Transfer-Load / Extract-Load-Transfer, abreviat
ETL / ELT (Tauro A. , 2013);
 baze de date – un depozit de date conţine mai multe
baze de date cu funcţii diferite: zone de acumulare a
datelor, magazine de date operaţionale (ODS),
depozitul de date propriu-zis, magazine de date
(datamarts) şi baze de date analitice.
La rândul ei, infrastructura depozitului de date poate fi
implementată folosind tehnologii diferite pentru nivelele
funcţionale diferite, cum ar fi (Wrembel & Koncilia, 2007):
 baze de date: de obicei, sunt utilizate baze de date
relaţionale precum: Oracle, SQL Server, DB2 sau
Teradata, dar se folosesc şi unele baze de date
nerelaţionale, cum ar fi: Ingres, PostGres sau Sybase;
 reţele de calculatoare: reprezentate de conexiuni de
întreprindere cu lăţimi de bandă de 10 Mbs / 100 Mbs /
100 Mbs;
124
 echipamente de stocare: sunt folosite, de regulă, soluţii

de tip Storage Area Network (SAN), adică reţele de
stocare. Depozitele de date de dimensiuni mai mici pot
fi stocate în întregime pe echipamente de tip Network-
Attached Storage (NAS);
Figura 14 – Infrastructura unui depozit de date
 servere: infrastructura de server pentru depozite de date,

datamart-uri şi baze de date analitice poate fi constituită
din sisteme de calcul cu 4, 8 sau 16 procesoare dual-
core sau quad-core cu 8, 16, 64 sau 128 GB de RAM
DDR3. Sistemul de operare poate fi Unix, Linux sau
Windows pe 32 sau 64 de biţi. Există şi cazuri în care
un sistem de calcul de dimensiuni mai mari este
partiţionat în multiple servere virtuale care constituie
125
infrastructura pentru diversele componente din Figura

14.
Dificultăţi întâmpinate în implementarea depozitelor de

date
Cauzele care au dus la eşecul proiectării depozitelor de

date în organizaţii, finalizat prin implementări parţial sau total
nereuşite, sunt reprezentate fie de proiectarea defectuoasă, fie
de problemele apărute pe parcursul implementării sau, ulterior,
în timpul exploatării. Deşi nu sunt disponibile statistici oficiale,
literatura de specialitate (Nicholson, 2013), (Dine, 2011),
(Amin & Arefin, 2010), (Madsen, 2005), (Cuvelier, 2013)
indică rate de eşec în implementarea şi exploatarea depozitelor
de date situate între 50% şi 75%. Aceleaşi surse afirmă faptul
că problemele generate de proiectarea defectuoasă a
depozitelor de date nu sunt legate de volumul (mare) de date
prelucrat, ci de alte cauze.
În schimb, principalele probleme întâmpinate în timpul
exploatării depozitelor de date sunt legate de performanţă şi
scalabilitate, ambele fiind aspecte legate de prelucrarea unor
volume mari de date.
Performanţă
Problemele de performanţă ale depozitelor de date sunt

generate de partajarea resurselor din infrastructură, partajare
care este utilizată atât în abordările top-down, cât şi în cele
bottom-up sau dimensionale ale depozitelor de date.
126
Principalele tehnologii din infrastructură care duc la

apariţia problemelor de performanţă sunt (Malinowski &
Zimányi, 2008):
 sistemele de stocare: bazele de date sursă au propriul
lor sistem de stocare care este parte a unui cluster de
stocare de dimensiuni mai mari. ODS-ul (dacă este
implementat), zona de acumulare şi, respectiv, bazele
de date ale depozitului de date sunt, de regulă, stocate
pe o singură arhitectură de stocare. Această
infrastructură partajată duce la apariţia următoarelor
cauze posibile pentru probleme de performanţă:
o intrările şi ieşirile utilizează, în mod concurent,
aceleaşi conexiuni de reţea;
o datele tranzitate între surse, zona de acumulare
şi baza de date a depozitului de date urmează un
traseu destul de complex de la surse la zona de
acumulare şi, în continuare, la ETL, stocare, din
nou ETL şi depozitul de date; Un astfel de
traseu complex presupune consum de resurse de
sistem şi de reţea, pentru administrarea
transferului datelor şi induce latenţe.
o întârzierile generate de conexiuni, tranzacţiile
care rulează mai lent, precum şi accesul întârziat
la sistemul de stocare determinat de ocuparea
acestuia sunt, de asemenea, caracteristici
obişnuite ale acestei arhitecturi.
 serverele: de obicei, serverele utilizate pentru diversele
componente ale depozitului de date sunt, de fapt, partiţii
virtuale ale unui server fizic de dimensiuni mai mari
127
(din motive de cost şi de simplitate în utilizare şi

administrare); de regulă, zona de acumulare şi depozitul
de date propriu-zis sunt pe acelaşi server, iar bazele de
date analitice sunt, în mod normal, instalate pe servere
separate. Acest mod de implementare, cunoscut şi sub
denumirea de shared-everything, poate determina
apariţia următoarelor probleme:
o memoria, timpul de procesor şi magistralele de
sistem sunt partajate de către toate aplicaţiile
care rulează pe sistem;
o stocarea este partajată între programe;
o transferurile de date sunt, de obicei, asigurate de
reţeaua de întreprindere şi nu de către conexiuni
dedicate.
Arhitectura shared-everything limitează aplicabilitatea
depozitelor de date. Performanţele scăzute ale depozitelor de
date pot fi generate de următorii factori: creşterea cantităţii de
date, creşterea numărului de utilizatori, introducerea unor noi
aplicaţii precum cele de data mining sau On Line Analytical
Processing - OLAP. De obicei, problemele apar la trei până la
şase luni de la implementare, la bazele de date de volum mai
mare şi, respectiv, la aproximativ un an de la implementare, la
bazele de date de volum mai mic (Krishnan, 2013).
La apariţia acestor probleme, administratorul bazei de
date şi administratorul de sistem realizează acţiuni de tuning de
performanţă pe bazele de date afectate. Cele mai utilizate
tehnici sunt: optimizarea interogărilor, adăugarea de indecşi,
adăugarea de sisteme de stocare (partiţionare, replicarea /
paralelizarea sistemului de stocare) şi capacităţi de server
128
(procesoare, RAM etc.), precum şi managementul datelor care

este fundamentat pe tehnici bazate pe calendar sau, mai ales, pe
frecvenţa utilizării şi prioritatea accesului, dar şi compresia
datelor şi crearea de tabele agregate sau vizualizări
materializate (Malinowski & Zimányi, 2008). Însă, succesul
este limitat, problemele de performanţă reapărând, mai
devreme sau mai târziu, din aceleaşi motive enunţate anterior.
Scalabilitate
Scalabilitatea bazei de date indică abilitatea
infrastructurii de a suporta creşterea activităţii în depozitul de
date. Creşterea activităţii poate fi determinată de creşterea
volumului de date prin adăugarea de noi date şi / sau de
creşterea numărului de utilizatori de diverse nivele, fapt care
duce la creşterea numărului de cereri de date. Ambele situaţii
afectează performanţa şi apelează la scalabilitate. Unele dintre
tehnicile de creştere a performanţei enumerate anterior
(adăugarea de sisteme de stocare şi capacităţi de server)
generează, în acelaşi timp, şi creşterea scalabilităţii.
Partiţionarea, adăugarea de infrastructură şi optimizarea
nu duc la obţinerea unei scalabilităţi nelimitate, construindu-se,
însă, depozite de date cu volume foarte mari de date (Inmon,
Strauss, & Neushloss, DW 2.0: The Architecture for the Next
Generation of Data Warehousing, 2010). Pentru a obţine astfel
de depozite de date pot fi utilizate următoarele tehnici:
 proiectarea şi implementarea de depozite de date
parţiale pentru diversele compartimente ale afacerii
(lucru care de fapt neagă scopul depozitului de date în
sine);
129
 crearea unui număr mare de datamart-uri (având ca

efect creşterea complexităţii arhitecturii);
 utilizarea mai multor tipuri de baze de date pentru
adaptarea la diversele cerinţe de performanţă (fapt care
necesită, însă, activităţi de întreţinere suplimentare).
Aşa cum se poate observa, depozitele de date
tradiţionale prezintă diverse inconveniente funcţionale.
Apariţia soluţiilor de depozite de date la cheie (data warehouse
appliances; a se vedea Subcapitolul 2.2.3), a soluţiilor de tip
cloud şi a metodelor de virtualizare au determinat dezvoltarea
unor platforme noi, precum şi oferirea unor alternative noi de
construcţie pentru depozitele de date care pot fi utilizate pentru
a reproiecta / reimplementa soluţiile curente sau pentru a le
extinde, crescându-le performanţa şi scalabilitatea.
Tipuri de arhitecturi utilizate în construcţia depozitelor

de date
Depozitele de date tradiţionale au la bază una dintre

cele două filosofii arhitecturale elaborate de William H. Inmon
şi, respectiv, Ralph Kimball:
1. Arhitectura „fabrică de informaţie” (Figura 15), în
engleză Information factory architecture, utilizează o metodă
de modelare a datelor bazată pe Forma Normală 3, în care
datele sunt achiziţionate în forma cea mai apropiată de sursa
lor, adăugându-se nivele suplimentare la arhirectura de bază,
pentru a realiza activităţile de analiza a datelor, raportare,
precum şi alte servicii.
La această arhitectură abordarea este top-down. Mai
multe sisteme sursă din întreprindere trimit date către o zonă de
130
acumulare dintr-un depozit de date centralizat, zonă în care se

aplică reguli de curăţare şi de îmbunătăţire a calităţii datelor.
Datele preprocesate sunt, în final, transformate şi încărcate în
depozitul de date. După încărcarea în depozitul de date, în
funcţie de necesităţile afacerii respective, se construiesc nivele
virtuale care pot fi accesate de către alte aplicaţii, pe baza unor
vizualizări şi tabele agregate. De regulă, sunt create datamart-
uri distincte pentru a realiza transformări complexe ale datelor.
Figura 15 – Arhitectura „fabrică de informaţie”

Această arhitectură prezintă următoarele avantaje şi
dezavantaje (Krishnan, 2013):
 Avantaje:
o furnizează o viziune globală a datelor la scara
întregii întreprinderi;
131
o este centralizată;
o aplică global regulile şi controlul;
o permite actualizarea datelor într-un singur
punct;
o prezintă o performanţă ridicată;
o poate fi construită în mai mulţi paşi;
 Dezavantaje:
o riscuri ridicate de defectare;
o operaţiile de îmbunătăţire a calităţii datelor pot
întârzia procesarea datelor şi trimiterea către
depozitul de date;
o întreţinerea este scumpă;
o necesită o infrastructură foarte scalabilă.
2. Arhitectura „magistrală”, în limba engleză BUS

architecture, cunoscută, de asemenea, şi ca arhitectura Kimball
(Figura 16), se bazează pe un conglomerat de datamart-uri
strâns integrate care are la bază, la rândul lui, un model
dimensional al datelor. Modelul de date permite analiştilor din
organizaţie să definească şi să construiască datamart-uri pentru
fiecare compartiment din organizaţie, iar legătura între
diversele datamart-uri se face prin utilizarea unui set comun de
dimensiuni.
Arhitectura „magistrală” impune realizarea depozitului
de date prin tehnica bottom-up. Această tehnică presupune
crearea mai multor datamart-uri orientate pe diverse subiecte,
care, apoi, vor fi reunite prin construcţia unui set de dimensiuni
comune denumit BUS. BUS-ul va fi alcătuit din datele cele mai
reprezentative care sunt partajate între datamart-uri. Utilizarea
132
arhitecturii magistrală permite crearea unui depozit de date prin

consolidarea datamart-urilor într-un nivel virtual. Astfel,
această arhitectură este bazată pe un model dimensional de
dimensiuni şi fapte.
Figura 16 – Arhitectura BUS
Arhitectura „magistrală” prezintă următoarele avantaje

şi dezavantaje (Krishnan, 2013):
 Avantaje:
o implementarea rapidă a unui număr mare de
module administrabile;
o proiectare facilă la nivel de datamart;
o risc mai redus de defectare;
o construcţie incrementală cu obţinerea rapidă a
celor mai importante datamart-uri;
o nu are nevoie de o infrastructură atât de
puternică precum arhitectura „fabrică de
informaţii”;
133
 Dezavantaje:
o datamart-urile au raza de acţiune limitată la
subiectul pentru care au fost construite;
o trebuie ca toate cerinţele să fie îndeplinite
înainte de pornirea propriu-zisă a proiectului;
o crearea unor fluxuri operaţionale
corespunzătoare pentru analize complexe de
inteligenţa afacerii este complicată.
Trăsături comune ale depozitelor de date de generaţie

1.0
Potrivit analizei realizate anterior, niciuna dintre cele

două arhitecturi nu este complet avantajoasă sau
dezavantajoasă, dificultăţile de implementare enumerate,
aplicându-se ambelor arhitecturi. Printre implementările
realizate de-a lungul timpului, au existat şi implementări mixte
care au îmbinat plusurile şi minusurile celor două filosofii de
construcţie (Wrembel & Koncilia, 2007). Indiferent de modelul
de arhitectură adoptat, orice implementare de depozit de date
tradiţional va fi confruntată cu următoarele probleme:
 dependenţa de bazele de date relaţionale - acest aspect
limitează posibilitatea de a crea arhitecturi flexibile;
Pentru a asigura calitatea datelor depozitului de date,
este necesar şi obligatoriu să se respecte retricţiile
impuse datelor, însă acest lucru nu este necesar şi
obligatoriu şi pentru construirea depozitului de date.
 arhitectura shared-everything - cu excepţia depozitelor
de date Teradata, toate celelalte soluţii comerciale
existente pe piaţă se bazează pe această arhitectură,
134
acest lucru având efecte directe asupra performanţelor,

scalabilităţii şi, nu în ultimă instanţă, asupra
competitivităţii şi a succesului lor de piaţă (a se vedea
Figura 13);
 creşterea explozivă a volumului de date însoţită de o
creştere exponenţială a complexităţii interogărilor;
 evoluţia cererilor de scalabilitate şi performanţă;
 imposibilitatea de predicţie a volumelor de prelucrare
necesare;
 asistenţă pentru analize oferită de produsele
companion;
 evoluţia utilizatorilor de la consumatori de rapoarte
statice, la exploratori de analize interactive;
 limitările tehnicilor tradiţionale de sharding /
partiţionare.
Ţinând cont de incapacitatea arhitecturilor generaţiei
1.0 de a rezolva aceste probleme, se poate concluziona că sunt
necesare tehnici noi de construcţie a depozitelor de date.
2.2.2 Generaţia a doua de depozite de date (generaţia 2.0)
Aşa cum s-a menţionat în subcapitolul anterior, cea de-a

doua generaţie de depozite de date, denumite generic DW 2.0,
a fost prezentată pentru prima dată de către Inmon (Inmon, DW
2.0 - Architecture for the Next Generation of Data
Warehousing, 2006). O soluţie alternativă pentru depozitele de
date din generaţia 2.0 este reprezentată de modelul de
arhitectură a datelor Decision Support Systems 2.0 (DSS 2.0),
descris de Imhoff şi White (Imhoff & White, 2008).
135
A doua generaţie de depozite de date a fost proiectată

pe baza unor modele arhitecturale mai scalabile şi flexibile
decât generaţia 1.0, dar care sunt, în continuare, bazate pe
principii specifice bazelor de date relaţionale. Această nouă
generaţie de depozite de date beneficiază de pe urma apariţiei a
unor noi tehnologii, precum: soluţiile de depozite de date la
cheie, bazele de date NoSQL columnare şi arhitecturile hub-
and-spoke (compuse dintr-un concentrator central de date sau
servicii şi o serie de linii de comunicaţie sau deservire radiale)
care cresc substanţial nivelele de performanţă şi scalabilitate
care pot fi atinse.
DW 2.0
Unul dintre aspectele cheie ale arhitecturii DW 2.0 este

clasificarea în funcţie de ciclul de viaţă al datelor, în scopul
creării unei arhitecturi scalabile. Pentru a rezolva problemele
apărute la depozitele de date din prima generaţie, au fost
reproiectate trei componente distincte ale arhitecturii DW 2.0,
pe baza clasificării menţionate anterior:
 arhitectura datelor – o nouă organizare dependentă de
ciclul de viaţă al datelor;
 infrastructura – rearanjată pe baza arhitecturii şi ciclului
de viaţă al datelor;
 datele nestructurate – introducerea în componenţa
depozitului de date a unor noi tipuri de conţinut (text,
imagini, email-uri şi alte tipuri de conţinut specifice
Web 2.0).
Figura 17 descrie arhitectura DW 2.0 propusă de Inmon
(Inmon, Strauss, & Neushloss, DW 2.0: The Architecture for
136
the Next Generation of Data Warehousing, 2010). Elementele

care diferenţiază această arhitectură de arhitectura generaţiei
1.0 sunt:
 datele sunt împărţite în patru niveluri distincte, bazate
pe tipurile de date şi cerinţele afacerii cu privire la
aceste date; Conceptul este asemănător cu cel din
managementul ciclului de viaţă al informaţiei. Spre
deosebire de acesta, se adăugă faptul că nivelul de
metadate este extins peste toate cele trei nivele care nu
conţin date actualizate în timp real:
o nivelul datelor integrate (date actuale referitoare
la cerinţele afacerii care sunt actualizate la
câteva ore sau zile);
o nivelul datelor near line (date istorice a căror
vechime variază între trei şi cinci ani);
o nivelul datelor arhivate (date near line a căror
importanţă s-a diminuat).
 metadatele sunt stocate separat pentru fiecare nivel;
 fiecare nivel are o componentă de date nestructurate
corespunzătoare;
 fiecare nivel poate fi creat pe o platformă hardware /
software diferită pentru că metadatele permit integrarea
virtuală a nivelelor;
 costuri mai scăzute în raport cu prima generaţie de
depozite de date;
 servicii de mentenanţă diminuate faţă de prima
generaţie de depozite de date;
 reprezintă un bun suport pentru o guvernanţă puternică;
 furnizează flexibilitate şi scalabilitate.
137
138
Date tranzacţionale
Date
interactive
Actualizate
Aplicaţie
Aplicaţie
Aplicaţie
Aplicaţie
în timp real
Sumar
Subiecte
propriu-
Date
zise
Date detaliate snapshot
Interne,
afacere
Date de
continue
externe
Referinţe, Date
Date integrate Text
date de
Actualizate colectat
master profil
Subiect
Subiect
Subiect
Subiect
Identificator
Metadate locale
text
Subiect
Subiect
Subiect
Sumar
Legături
Figura 17 – Arhitectura DW 2.0 (prima parte)

Date tehnice
Text la
subiect
Subiecte
propriu-
Date
zise
Interne,
afacere
Date de
continue
externe
Referinţe, Date
Date near line Text
date de
Recente colectat
master profil
Subiect
Subiect
Subiect
Subiect
Identificator
iect
iect
iect
e metadate al întreprinderii
Metadate locale
hnice
text
Referinţe,
Date integrate Text
date de
Actualizate colectat
master profil
Subiec
Subiec
Subiec
Subiec
Identificator
Metadate
text
Subiect
Subiect
Subiect
Sumar
Legături
Date tehnice
Text la
subiect
Subiecte
propriu-
Date
zise
Interne,
afacere
Date de
continue
externe
Referinţe, Date
Date near line Text
date de
Recente colectat
master profil
Subiect
Subiect
Subiect
Subiect
Identificator
Metadate locale
text
Subiect
Subiect
Subiect
Sumar
Legături
Date tehnice
Text la
Depozitul de metadate al întreprinderii
subiect
Subiecte
propriu-
Date
zise
Interne,
afacere
Date de
continue
externe
Referinţe, Date
Date arhivate Text
date de
Mai vechi colectat
master profil
Subiect
Subiect
Subiect
Subiect
Identificator
Metadate locale
text
Subiect
Subiect
Subiect
Sumar
Figura 17 – Arhitectura DW 2.0 (partea a doua)

Legături
Date tehnice
Text la
subiect
139
Arhitectura DW 2.0 – schiţată pentru prima oară în

(Inmon, DW 2.0 - Architecture for the Next Generation of Data
Warehousing, 2006) şi descrisă complet în (Inmon, Strauss, &
Neushloss, DW 2.0: The Architecture for the Next Generation
of Data Warehousing, 2010) – este relativ nouă şi conţine
elemente care permit adaptarea sa la noile tipuri de conţinut
generate de aplicaţiile Web 2.0.
DSS 2.0
Arhitectura DSS 2.0 a fost elaborată de Claudia Imhoff

şi Colin White (Imhoff & White, 2008) şi este prezentată în
Figura 18.
Spre deosebire de DW 2.0 care realizează o
compartimentare după ciclul de viaţă al datelor, modelul DSS
2.0 propune o compartimentare a sarcinilor de lucru ale
inteligenţei afacerii analitice şi operaţionale, după tipurile de
obiecte analizate (procese sau date) şi adaugă la cele două
compartimente un al treilea compartiment pentru analiza
conţinuturilor (fapt care se adaptează bine la orientarea către
conţinuturi a aplicaţiilor Web 2.0).
Cele trei module pot fi valorificate folosind reguli şi
politici de afacere implementate prin intermediul unei
platforme integrate de asistare a deciziei numită inteligenţa
deciziei.
140
Figura 18 – Arhitectura DSS 2.0
141
Această structură tratează diferite tipuri de nevoi ale

inteligenţei afacerii ale căror caracteristici specifice sunt
sintetizate în Tabelul 7. Potrivit acestui tabel, modelul
presupune existenţa a diferite tipuri de utilizatori de la diverse
nivele din ierarhia afacerii, utilizatori care au comportament de
interogare şi cerinţe diferite.
Tabelul 7 – Tipurile de nevoi ale inteligenţa afacerii tratate de modelul

DSS 2.0
Inteligenţa Inteligenţa Inteligenţa
afacerii afacerii tactică afacerii
strategică operaţională
Scop de Atingerea Administrarea Monitorizarea şi
afacere obiectivelor iniţiativelor tactice optimizarea
afacerii pe pentru atingerea proceselor
termen lung obiectivele operaţionale de
strategice afacere
Utilizatori Directori Analişti de afaceri Manageri de
primari executivi şi şi manageri de compartiment,
analişti de compartiment utilizatori
afacere operaţionali şi
procese
operaţionale
Cadru de Luni, ani Zile, săptămâni, Segmente de zi,
timp luni zile
Date Date istorice Date istorice Date curente, date
cu latenţă redusă,
date istorice
Mod de Orientat pe Orientat pe Orientat pe
operare utilizator, centrat utilizator, centrat evenimente,
pe date pe date centrat pe procese
142
DSS 2.0 este implementată ca o soluţie front-end care

realizează integrarea metadatelor reprezentative în
întreprinderile actuale.
Implementarea DW 2.0 şi DSS 2.0 în viitoarele depozite

de date
În prezent, provocările cu care se confruntă depozitele

de date nu derivă doar din volumul mare de date, ci şi din
faptul că tipurile şi formatele de date nou apărute ca produs al
aplicaţiilor Web 2.0 nu se conformează regulilor de prelucrare
a datelor din depozitele de date clasice. Regulile proiectate
pentru date relaţionale nu pot fi aplicate pe text nestructurat,
imagine, video, date generate de echipamente şi date
achiziţionate de la senzori. Depozitele de date viitoare vor
trebui, de asemenea, să fie capabile să prelucreze evenimente
complexe şi fluxuri de date, dar şi să recunoască structuri de
date orientate obiect sau structuri Service Oriented
Architecture (SOA) drept componente ale prelucrărilor de date.
Evoluţia viitoare a depozitelor de date va trebui să ia în
calcul integrarea diferitelor tipuri de date şi a modului în care
ele sunt utilizate. Ţinând cont de varietatea acestor tipuri de
date şi a dimensiunilor lor relative, pentru o obţine o evaluare
uniformă a performanţei şi a dimensiunii depozitelor de date,
este mai indicat să se evalueze volumul de date în număr de
sarcini de lucru, definite ca prelucrări elementare efectuate pe
un tip oarecare de date şi nu în unităţi clasice de măsurare a
cantităţii de informaţie (biţi, octeţi) (Krishnan, 2013).
În concluzie, activitatea acestor depozite de date va fi
orientată pe sarcini, arhitectura şi structura lor va porni de la
143
structuri eterogene de date, iar infrastructurile vor fi optimizate

pentru lucrul cu sarcini.
Modelele arhitecturale DW 2.0 şi DSS 2.0 care permit,

aşa cum s-a precizat în cadrul acestui subcapitol, integrarea
tipurilor de date şi satisfacerea cerinţelor noi stau la baza
depozitelor de date de generaţie următoare. Aceste modele sunt
centrate pe utilitate şi scalabilitate din punctul de vedere al
utilizatorului. Adăugarea sarcinii de lucru ca unitate de
procesare / reper de evaluare determină creşterea
funcţionalităţii şi a scalabilităţii infrastructurii, permiţând
compartimentarea în arhitecturi discrete, implementate pe
suporturi independente, suprapartiţionând, practic, depozitul de
date.
2.2.3 Soluţii la cheie pentru depozite de date
Termenul de soluţie la cheie pentru depozite de date

(data warehouse appliance) este un termen de marketing care
descrie un ansamblu integrat de servere, soluţii de stocare,
sisteme de operare, SGBD şi software, preinstalate,
preconfigurate şi preoptimizate pentru a funcţiona ca un
depozit de date. Se consideră că acest termen a fost introdus
oficial în 2008 de către compania Teradata, la lansarea
produselor sale Teradata 550P, Teradata 2500 şi Teradata 5550
(Kobielus, 2008). Precursorii acestui tip de produse au fost
soluţiile la cheie pentru depozitele de date existente pe piaţă.
Astfel, în anii 80, primele produse de acest tip au fost
comercializate de compania Britton-Lee, (Monash Research,
2008).
144
Conceptul de soluţie la cheie pentru depozite de date se

poate referi atât la un ansamblu complet hardware / software
provenind de la unul şi acelaşi furnizor (cum ar fi: Teradata -
Teradata Data Warehouse Appliance, Oracle - Oracle Exadata
Database Machine, IBM - IBM PureData System, SAP – SAP
Sybase IQ, EMC – EMC Greenplum şi Exasol -
EXAAppliance), cât şi la o combinaţie hardware / software
provenind de la mai mulţi furnizori diferiţi (precum: soluţiile
Dell / Microsoft – Dell Parallel Data Warehouse, HP /
Microsoft - HP AppSystem for SQL 2012 Parallel Data
Warehouse şi Quanta / Microsoft – Quanta Analitycs Platform
System) (Microsoft, 2014). Platforma hardware utilizată se
proiectează astfel încât să asigure combinaţia performanţă /
fiabilitate / disponibilitate ridicate, considerată de furnizor ca
fiind optimă pentru un depozit de date (ex. procesare masiv-
paralelă, sisteme de stocare RAID etc.; aceste caracteristici au
fost discutate în subcapitolul 2.1).
Soluţiile la cheie pentu depozite de date sunt destinate
implementării de depozite de date de dimensiuni mari care
variază între câţiva teraocteţi până la câţiva petaocteţi.
Primele specificaţii tehnologice documentate ale
soluţiilor la cheie pentru depozite de date au fost elaborate în
2009 de către un consorţiu de firme cuprinzând printre alţii pe
Microsoft, HP şi Dell (Campbell, 2014), iar în momentul de
faţă este disponibilă a doua ediţie a acestor specificaţii (Eric
Kraemer, 2014).
Ţinând cont de faptul că producătorii nu furnizează
produse cu structuri şi specificaţii asemănătoare şi că
organizaţiile în care se implementează depozitele de date au
145
cerinţe diferite care generează astfel arhitecturi diferite,

soluţiile la cheie pentru depozite de date pot fi clasificate în
următoarele categorii (Technology Bussiness Research, 2014):
 soluţii hardware care reprezintă o configuraţie
optimizată pentru prelucrările specifice depozitelor de
date, dar care nu este furnizată împreună cu software;
 soluţii hardware şi software, adică soluţii optimizate
pentru operaţiile de prelucrare, transfer şi stocare
specifice depozitelor de date, însoţite de soluţii de
management;
 soluţii hardware, software şi servicii care conţin o
soluţie optimizată pentru operaţiile de prelucrare,
transfer şi stocare specifice depozitelor de date, un
sistem de operare gazdă, o stivă de aplicaţii şi un set de
servicii;
 soluţii software reprezentate de o stivă de aplicaţii care
poate rula pe hardware obişnuit sau în cloud;
 soluţii virtualizate, adică aplicaţii software virtualizate
însoţite de programe hipervizor necesare pentru
management care pot rula pe hardware obişnuit sau în
cloud.
Technology Bussiness Research a aplicat în anul 2014
un chestionar complex pe un eşantion alcătuit din 1300 de
companii utilizatoare de soluţii la cheie de diverse tipuri.
Rezultatele chestionarului au evidenţiat motivele utilizării de
către managementul din diversele companii a soluţiilor la
cheie, precum şi avantajele pe care aceştia le percep ca urmare
a folosirii acestor soluţii.
146
În Figura 19 sunt reprezentate, pe baza rezultatelor

chestionarului, preferinţele utilizatorilor pentru categoriile de
soluţii la cheie ale clasificării descrise anterior.
Soluţii hardware
4% 12%
16%
Soluţii hardware +
software
29% Soluţii hardware +

software + servicii
Soluţii software
39%
Soluţii virtualizate
Figura 19 – Nivelul preferinţelor clienţilor pentru diversele categorii de

soluţii la cheie
În Figura 20 sunt ilustrate avantajele percepute de

utilizatori, în ordinea descrescătoare a importanţei lor.
41%
Acces la date 33%
31%
Avantaje competitive 30%
30%
Compatibilitate 27%
21%
Valoare adăugată / noi… 19%
17%
Management 15%
14%
Down-time / disponibilitate 12%
0% 10% 20% 30% 40% 50%
Figura 20 – Avantajele utilizării soluţiilor la cheie pentru depozite de

date
147
De asemenea, chestionarul evidenţiază şi beneficiile pe

care le poate oferi o soluţie la cheie pentru depozite de date.
După impactul pe care prezenţa / absenţa soluţiilor la cheie îl
are asupra deciziei de cumpărare a unei astfel de soluţii, aceste
beneficii se clasifică în două categorii: beneficii critice şi
beneficii suplimentare.
 beneficii critice (absenţa lor determină insatisfacţia
clienţilor în raport cu produsul şi poate duce la
renunţarea la achiziţie):
o funcţionalităţi specifice solicitate de client;
o securitatea / protecţia datelor;
o costul de operare care trebuie să fie mai redus
decât cel pentru o posibilă soluţie asamblată din
componente;
o fiabilitate;
o disponibilitate ridicată / furnizarea unui serviciu
cu nivel crescut;
o compatibilitate cu aplicaţiile deja existente la
client;
o preţul care trebuie să fie mai redus decât suma
preţurilor componentelor care ar trebui
asamblate pentru a obţine o soluţie similară.
 beneficii suplimentare (prezenţa lor creşte nivelul de
satisfacţie al clienţilor):
o reprogramabilitate (abilitatea de a include noi
funcţii);
o uşurinţa administrării / management centralizat
de la o consolă unică;
148
o utilizare facilă, necesitând mai puţină instruire

decât o soluţie asamblată din componente;
o rapiditatea instalării;
o existenţa unui suport software inclus în preţul de
achiziţie (de preferat) sau ca un serviciu separat;
o disponibilitatea de seturi de servicii profesionale
(proiectare, consultanţă, instruire etc.), în scopul
maximizării returnării investiţiei.
Analizând aceste informaţii, se poate concluziona că
soluţiile la cheie prezintă o serie de avantaje economice şi
tehnologice clare, însă, cu toate acestea, nu este indicată
utilizarea lor în orice situaţie în care se doreşte implementarea
unui depozit de date.
Astfel, se recomandă folosirea acestor soluţii atunci
când:
 reducerea de costuri este mai importantă decât
obţinerea unei performanţe maxime, prin utilizarea unei
arhitecturi perfect adaptate şi optimizate pentru
depozitul de date implementat;
 se impune diminuarea atât a cheltuielilor, cât şi a
eforturilor de administrare, folosind o metodă integrată
de management bazată pe o consolă unică;
 se solicită ca produsul achiziţionat să prezinte o
disponibilitate ridicată; Aceasta poate fi implementată
prin proiectare dedicată hardware şi software şi / sau
prin virtualizare şi abstractizare;
 se doreşte obţinerea rapidă şi cu costuri reduse a
scalabilităţii, prin intermediul unei arhitecturi modulare,
pre-proiectate şi pre-integrate;
149
 există deja o implementare de depozit de date care are o

performanţă scăzută;
 există deja o implementare de depozit de date care şi-a
atins limitele de stocare;
 există în companie know-how în construirea de
depozite de date şi este necesară asistenţă la
implementare, proiectare şi simplificarea acestora;
 se preferă achiziţionarea unei soluţii la cheie cu
performanţă şi comportament predictibile.
Nu este recomandată utilizarea de soluţii la cheie
pentru depozite de date în următoarele cazuri:
 nicio astfel de soluţie nu oferă capacitatea de stocare
necesară;
 soluţiile la cheie existente pe piaţă nu oferă
funcţionalităţile dorite de client;
 soluţiile la cheie disponibile pe piaţă nu sunt
compatibile cu aplicaţiile deja existente la client;
 se doreşte obţinerea unei performanţe cât mai ridicate,
prin optimizarea avansată a arhitecturii.
2.3 Măsurarea performanței în prelucrarea

Pentru a măsura performanţele unui sistem de calcul,

procesor, echipament de stocare, GPU, program, SGBD etc. se
utilizează benchmark-uri. Termenul benchmark are un dublu
sens, însemnând atât actul de măsurare a performanţei unui
obiect folosind, de obicei, o scară relativă, comparativă, cât şi
150
aplicaţia sau pachetul de aplicaţii utilizate pentru aprecierea

respectivă.
2.3.1 Probleme întâmpinate în benchmarking
Activitatea de benchmarking implică repetarea unei

serii de prelucrări al căror timp de execuţie se interprează, în
general, în funcţie de scopul benchmark-ului respectiv. Acest
mod de lucru predispune la o serie de dificultăţi care vor fi
enunţate în continuare.
Furnizorii de aplicaţii sau echipamente au posibilitatea
de a-şi optimiza produsele pentru cele mai cunoscute aplicaţii
benchmark, putând obţine, astfel, rezultate semnificative. Însă,
în urma optimizării produsele pot avea rezultate mai slabe pe
prelucrări reale.
Cele mai multe benchmark-uri se concentrează,
exclusiv, asupra timpilor de execuţie obţinuţi, ignorând
celelalte caracteristici importante ale obiectului evaluat, cum ar
fi: securitate, disponibilitate, nivel de încredere, integritatea
execuţiei, mentenabilitate, scalabilitate, abilitatea de a reloca
rapid capacități de calcul etc.). Pentru majoritatea aplicaţiilor
reale se încearcă realizarea unui echilibru între viteză şi aceste
caracteristici. În cazul bazelor de date, se mai adaugă şi alte
caracteristici, dificil de testat cum ar fi: completitudinea ACID,
respectarea regulilor de scalabilitate şi a cerinţelor de nivel al
serviciului.
În general, benchmark-urile nu măsoară costul total de
proprietate. Transaction Processing Performance Council
Benchmark acoperă parţial acest neajuns, conţinând şi o
151
metrică preţ / performanţă. Cu toate acestea, şi această metrică

poate fi înşelată de către furnizori, prin raportarea unor preţuri
scăzute în mod artificial, prin diverse tehnici. O altă metrică
care ar putea fi semnificativă este performanţă atinsă per
consum de energie.
De asemenea, există dificultăţi şi în adaptarea
benchmark-urilor la mediile de prelucrare şi de stocare
distribuite (în special grid şi cloud), deoarece aceste medii sunt
concepute, de obicei, numai pentru un anumit tip de aplicaţii.
Conceptul de performanță este un concept subiectiv,
majoritatea utilizatorilor apreciind drept performanţă,
predictibilitatea obiectului evaluat în a atinge un anumit nivel
de serviciu.
Performanța multor arhitecturi server se diminuează
puternic la nivele de încărcare apropiate de 100%, nivele la
care nu se realizează aproape niciodată benchmark-uri.
Multe benchmark-uri se focalizează numai asupra unei
singure aplicaţii sau clase de aplicaţii (de exemplu: numai
aplicaţii de tip office), excluzând chiar şi cazul execuţiei
simultane a altor aplicaţii. De asemenea, majoritatea
benchmark-urilor sunt proiectate pentru rularea pe maşini reale,
nu pe maşini virtuale, acestea având caracteristici diferite, deşi
din ce în ce mai multe sisteme sunt virtualizate în domeniul de
faţă.
Un alt dezavantaj este reprezentat de faptul că multe
benchmark-uri nu se bazează pe o metodă ştiinţifică de lucru,
adică nu se stabileşte o dimensiune optimă a eşantionului, nu se
folosesc variabile de control, nu se verifică repetabilitatea
testelor etc.
152
2.3.2 Clase de benchmark-uri
În ce urmează se prezintă o clasificare a benchmark-

urilor, furnizându-se şi exemple pentru fiecare categorie în
parte.
Benchmark-uri standardizate industrial (auditate şi
verificabile): Business Applications Performance Corporation
(BAPCo); Embedded Microprocessor Benchmark Consortium
(EEMBC); Standard Performance Evaluation Corporation
(SPEC); Transaction Processing Performance Council (TPC).
Benchmark-uri open source: DEISA Benchmark
Suite (pentru aplicaţii HPC); Dhrystone (performanţă în
operaţii aritmetice cu numere întregi); Coremark (pentru
echipamente embedded); Fhourstones (performanţă în operaţii
aritmetice cu numere întregi); HINT (performanţa globală a
sistemului); Iometer (performanţa I / O pentru sisteme
monolitice şi clustere); Linpack / LAPACK; Livermore loops;
NAS parallel benchmarks; NBench: (benchmark sintetic:
aritmetică întreagă, operaţii în memorie, aritmetică în virgulă
mobilă); PAL (modelări fizice în timp real); Phoronix Test
Suite: pachet de benchmark-uri cross-platformă (Linux,
OpenSolaris, FreeBSD, OSX şi Windows); POV-Ray: randare
3D; Tak (un benchmark simplu, testând performanţa în operaţii
recursive); TATP Benchmark (Telecommunication Application
Transaction Processing Benchmark); TpoX (benchmark
tranzacţional pentru baze de date XML); Whetstone
(performanţă în operaţii aritmetice cu numere în virgulă
mobilă).
153
Benchmark-uri pentru MS Windows: Aplicaţii

BAPCo: MobileMark, SYSmark, WebMark; Aplicaţii
Futuremark: 3DMark, PCMark; Whetstone; Worldbench;
PiFast; SuperPrime; Super PI; PassMark; Windows System
Assessment Tool (inclus în Microsoft Windows Vista,
Windows 7 şi Windows 8).
Alte benchmark-uri: BRL-CAD; Khornerstone;
iCOMP (scala comparativă de performanţă de la Intel);
Performance Rating (schemă de modelare utilizată de AMD şi
Cyrix pentru compararea produselor proprii cu produsele
concurente); Vmmark (benchmark de virtualizare); Sunspider
(benchmark de browsere); BreakingPoint Systems (benchmark
pentru evaluarea traficului pe servere şi echipamente de reţea);
Glaesemann, K. R.; van Dam, H. J. J.; Carr, J. F. (2011). "MSC
Benchmark 1.0". Pacific Northwest National Lab. descrie un
benchmark pentru sistemele masiv paralele în condiţii de
încărcare ridicată simultană pe conexiunile de reţea, memorie
şi CPU.
În continuare vor fi prezentate câteva dintre cele mai
cunoscute benchmark-uri, împreună cu câteva rezultate recente
generate de utilizarea lor.
2.3.3 Performanţa la transferul în / din baze de date

relaţionale
Creşterea performanţei în ceea ce priveşte scalarea unui

sistem este dificil de măsurat, deoarece testele de performanţă
cele mai cunoscute din domeniul bazelor de date – cele
furnizate de Transaction Processing Performance Council – nu
154
au fost, în general, aplicate pentru a urmări evoluţia

performanţei unui sistem la scalarea sa liniară (creşterea unitate
cu unitate a numărului de procesoare sau de noduri folosind
hardware identic). Totodată, există foarte puţine teste care
compară performanţa a două sau mai multe baze de date
concurente, în condiţii identice de lucru (acelaşi hardware,
acelaşi sistem de operare, aceeaşi configuraţie). Din acest
motiv, în acest moment, se poate evalua, doar, valoarea
indicatorilor bruţi de performanţă pentru rularea unui anumit
SGBD, într-o anumită configuraţie, pe un anumit sistem de
calcul sau cluster de sisteme de calcul, cu un anumit sistem de
operare.
Dincolo de lipsa unui criteriu clar de comparaţie, se
poate afirma totuşi că DB2 şi Oracle pot oferi o scalabilitate
semnificativă către baze de date de dimensiuni de ordinul
teraocteţilor şi utilizarea unui număr mai mare de 8 procesoare
per configuraţie.
Din acest punct de vedere SQL Server prezintă
dezavantaje, configuraţiile obişnuite pe instalările de SQL
Server având la bază, în principal, servere MPS pe patru căi şi,
mai puţin, de 500 de GB în dimensiunea bazei de date. Cu toate
că au fost introduse sisteme MPS Intel de putere mai mare, nu
au apărut foarte multe implementări semnificative. Punctul slab
cel mai important al SQL Server este dat de incapacitatea sa de
a furniza baze de date clusterizate nativ (necesare în principal
pentru BI). Microsoft emulează o bază de date clusterizată, prin
utilizarea bazelor de date federalizate şi a viziunilor UNION
ALL. Totuşi, această soluţie nu favorizează în mod real
scalabilitatea.
155
Anexele 4 şi 5 reproduc rezultatele testelor efectuate cu

benchmark-ul Transaction Processing Performance Council,
variantele TPC-C şi, respectiv, TPC-H.
Potrivit analizelor efectuate (Transaction Processing
Performance Council, 2013), bazele de date Oracle şi IBM au
performanţe mai bune pe instalările mari, destinate unor
aplicaţii de tip OLTP, dar în aplicaţiile de tip OLAP, sistemele
de baze de date ale tuturor celor trei producători de vârf
(Oracle, IBM, Microsoft) obţin rezultate aproximativ mixte
(constant surclasate de soluţiile EXASOL), indiferent de
dimensiunea instalării (benchmark-ul TPC-H este aplicat
segregat pe categorii dimensionale de instalări: 100 GB, 300
GB, 1.000 GB, 3.000 de GB, 10.000 GB li respectiv 30.000
GB).
TPC-C
Ca benchmark pentru sisteme OLTP, TPC-C simulează

un mediu complet în care o populaţie de operatori terminali
execută tranzacţii cu baza de date. Benchmark-ul este centrat
pe activităţile principale ale unui mediu dependent de ordinea
intrărilor. Aceste operaţii includ: introducerea şi livrarea
ordinelor, înregistrarea plăţilor, verificarea statutului ordinelor
şi monitorizarea nivelului stocurilor în depozite. Trebuie
subliniat că ţinta benchmark-ului nu constă în specificarea
modului în care ar trebui mai bine implementat un sistem. Cât
timp benchmark-ul portretizează activitatea unui furnizor en-
gros, TPC-C nu este limitat la activitatea unui anumit segment
de afaceri, ci, dimpotrivă, trebuie să reprezinte orice domeniu
156
care are de-a face cu administrarea, vânzarea sau distribuirea

unui produs sau serviciu (Raab, Kohler, & Shah, 2013).
În modelul de afacere TPC-C, un vânzător en-gros de
componente operează un număr de depozite asociate unor
regiuni de vânzări. Benchmark-ul TPC-C este proiectat să
scaleze, pe măsură ce compania se extinde şi noi depozite sunt
create. Pe măsură ce benchmark-ul este scalat, anumite cerinţe
de consistenţă sunt menţinute. Fiecare depozit deserveşte zece
regiuni de vânzări şi fiecare regiune are trei mii de clienţi. În
oricare moment, un operator din orice regiune poate selecta una
dintre cele cinci operaţii oferite de aplicaţia companiei. Ca şi
operaţiile înseşi, frecvenţa tranzacţiilor individuale este
modelată după scenarii realiste.
Cele mai frecvente tranzacţii constau în introducerea
unui nou ordin care, în medie, conţine zece produse diferite.
Fiecare depozit încearcă să menţină stocuri de 100.000 de
bucăţi din produsele din catalogul companiei şi adresează
cereri pentru completarea stocului respectiv, pe măsura
necesităţilor. De obicei, în realitate, un depozit nu va avea toate
produsele necesare pentru un ordin. De aceea, TPC-C solicită
ca aproximativ zece procente din ordine să fie aprovizionate de
un alt depozit. O altă tranzacţie frecventă constă în
înregistrarea unei plăţi făcute de un client. În anumite cazuri,
operatorii vor solicita starea unui anumit ordin emis precedent,
vor procesa un pachet de 10 ordine pentru livrare sau vor
interoga sistemul pentru lipsuri potenţiale, prin examinarea
stocurilor la depozitul local. Metrica de performanţă raportată
de TPC-C măsoară numărul de ordine care pot fi procesate
complet pe minut şi este exprimată în tpm-C.
157
TPC-H
TPC-H este un benchmark pentru sisteme suport de

decizii sau sisteme OLAP care constă dintr-o colecţie de
interogări orientate pe afacere şi generate ad-hoc, precum şi
unele modificări concurente ale datelor. Interogările şi datele
care populează baza de date au fost alese astfel încât să
reprezinte domenii economice cât mai variate, menţinând,
totuşi, o oarecare uşurinţă în implementare.
Acest benchmark evidenţiază sistemele suport de
decizie care examinează volume mari de date, execută
interogări de un grad înalt de complexitate şi furnizează
răspunsuri unor întrebări de afacere critice.
TPC-H evaluează performanţa diferitelor sisteme suport
de decizie, prin executarea unui set de interogări asupra unei
baze de date standard, în condiţii controlate. Interogările TPC-
H prezintă următoarele caracteristici: furnizează răspunsuri la
întrebări economice, simulează generarea de interogări ad-hoc
(de exemplu: prin point and click pe un GUI), sunt mult mai
complexe decât tranzacţiile OLTP, includ o gamă largă de
operatori şi constrângeri selective, generează o activitate
intensă a serverului de baze de date de pe maşina aflată în test,
sunt executate pe o bază de date care îndeplineşte cerinţe de
populaţie şi de scalare specificate, sunt implementate cu
restricţii derivate din existenţa unei legături strânse cu o bază
de date de producţie activă (Transaction Processing
Performance Council, 2013).
Operaţiile TPC-H sunt modelate astfel:
158
 baza de date este disponibilă continuu, douăzeci şi

patru de ore pe zi, şapte zile pe săptămână, pentru
interogări ad-hoc de la multipli utilizatori, dar şi
pentru modificări ale datelor din orice tabel; fac
excepţie sesiuni de întreţinere mai puţin frecvente
(în medie o dată pe lună);
 baza de date TPC-H oglindeşte fidel (se admite o
oarecare întârziere) starea bazei de date OLTP, prin
funcţii de reîmprospătare care vor executa împreună
un număr oarecare de modificări, cu impact asupra
bazei de date suport de decizie;
 datorită naturii globale a datelor de afaceri stocate în
baza de date TPC-H, interogările şi funcţiile de
reîmprospătare pot fi executate în orice moment, în
special, în relaţie una cu alta. În plus, amestecul
dintre interogări şi funcţii de reîmprospătare trebuie
să respecte cerinţele ACID, deoarece interogările şi
funcţiile de reîmprospătare se pot executa
concurent;
 pentru a realiza un compromis optim între
performanţă şi cerinţe operaţionale, administratorul
bazei de date poate stabili, în mod definitiv, nivelele
de blocare şi regulile de programare concurentă
pentru interogări şi funcţii de reîmprospătare.
Cea mai mică bază de date necesară pentru benchmark
este de 10.000 de furnizori şi conţine aproximativ zece
milioane de înregistrări, reprezentând o capacitate brută de
stocare de aproximativ 1 gigabyte. Alte implementări conforme
159
ale benchmark-ului pot conţine populaţii mai mari pentru baza

de date (strict specificate, asemeni populaţiei indicate anterior).
Metrica de performanţă utilizată de TPC-H se numeşte
TPC-H Composite Query-per-Hour Performance Metric
(QphH@Size) şi reflectă aspecte multiple ale capacităţii
sistemului de a procesa interogări. Aceste aspecte includ
dimensiunea bazei de date pe care se aplică interogările,
puterea de procesare a interogărilor atunci când interogările
sunt adresate într-un singur flux, dar şi numărul de interogări
executate în unitatea de timp, atunci când interogările sunt
concurente. Metrica TPC-H preţ / performanţă este exprimată
ca USD/QphH@Size. Organizaţia TPC consideră că o
comparaţie a rezultatelor TPC-H măsurate pe baze de date de
dimensiuni diferite poate duce la interpretări eronate şi
descurajează astfel de comparaţii.
Baza de date TPC-H trebuie implementată utilizând un
sistem de gestiune a bazelor de date disponibil comercial, iar
interogările trebuie executate printr-o interfaţă care utilizează
SQL dinamic.
2.3.4 Performanţa la transferul în / din baze de date

NoSQL
Datorită faptului că bazele de date NoSQL au început să

fie utilizate recent, este firesc să nu existe, încă, implementări
pentru multe din uneltele specifice zonei bazelor de date
relaţionale (cum ar fi: interfețe de administrare, produse de
automatizarea optimizării etc.). În aceeaşi situaţie se află şi
aplicaţiile pentru măsurarea performanţei bazelor de date
160
NoSQL (Baru, Bhandarkar, Nambiar, Poess, & Rabl, 2013),

singurul exemplu făcut public de o asemenea aplicaţie fiind
Yahoo! Cloud Serving Benchmark (YCSB) (Cooper,
Silberstein, Tam, Ramakrishnan, & Sears, 2010). Din acest
motiv, una dintre direcţiile de cercetare pentru lucrarea curentă
este şi elaborarea unui pachet software cu funcţionalitate
echivalentă.
Pentru a analiza comparativ unele produse din gama
denumită generic NoSQL, iniţial, a fost necesar să se selecteze
un grup de produse de acelaşi tip, având funcţionalităţi şi
capabilităţi similare. Pornind de la taxonomiile analizate în
subcapitolul 1.2, au fost selectate numai produse din clasa
“Wide Column Store” din prima taxonomie (care este
echivalentă relativ cu clasa “Key-value store” din cea de a doua
taxonomie), iar din cadrul acestora au fost alese numai
produsele cu aplicaţii considerate a fi semnificative la
momentul actual. Rezultatul a fost reprezentat de produsele
Hbase şi Cassandra care, pe lângă caracterisiticile precizate
anterior, prezintă şi avantajul că sunt bazate pe acelaşi
framework, şi anume Hadoop.
De asemenea, pentru a identifica avantajele şi
dezavantajele utilizării bazelor de date NoSQL, în comparaţie
cu cele relaţionale, a fost adăugat un element de referinţă din
clasa bazelor de date relaţionale, şi anume aplicaţia MySQL.
Aceasta este un produs open source, ca şi celelalte două luate
în discuţie, doar că este vorba de o bază de date complet
relaţională.
161
O analiză calitativă
Înainte de analiza propriu-zisă a performanţelor

produselor luate în discuţie, au fost analizate facilităţile oferite,
astfel încât să se poată confirma sau infirma justeţea catalogării
produselor comparate, ca fiind produse de aceeaşi clasă.
Facilităţile căutate au fost:
 persistenţa;
 capacitatea de replicare;
 capacitatea de construcţie a unor sisteme de înaltă
disponibilitate;
 capacitatea de a efectua tranzacţii;
 capacitatea de a conştientiza localizarea proprie în
rack (facilitate necesară pentru anumite soluţii de
virtualizare);
 limbajul în care a fost implementat produsul;
 influenţe şi sponsori;
 tipuri de licenţiere disponibile.
Rezultatele comparaţiei sunt ilustrate în Tabelul 8. Se
poate observa că cele trei produse oferă aceleaşi facilităţi (care
nu sunt implementate sau nu funcţionează similar), singurele
diferenţe apărând la tranzacţii, limbaj de implementare şi tip de
licenţiere. Soluţia dublă de licenţiere disponibilă la momentul
actual pentru MySQL este rezultatul seriei de achiziţii din
ultimii ani (Sun a cumpărat MySQL, Oracle a cumpărat Sun).
162
Tabelul 8 – Tabelul comparativ cu facilităţile oferite de cele trei

produse selectate
Facilitate Cassandra HBase MySQL
Persistenţa da da da (utilizând o
conexiune
atipică)
Capacitatea de da da da
replicare
Capacitatea de Sistem Sistem distribuit Sistem distribuit,
construcţie a distribuit disponibil prin
unor sisteme de MySQL Cluster
disponibilitate
ridicată
Capacitatea de Consistent în Consistent local (la Consistent
a efectua cele din urmă nivel de linie) (ACID)
tranzacţii
Capacitatea de da da da
a conştientiza (moştenită de (moştenită de la (cu MySQL
localizarea la Hadoop) Hadoop) Cluster)
proprie în rack
Limbajul în Java Java ANSI C / ANSI
care a fost C++
implementat
produsul
Influenţe şi Dynamo and BigTable Oracle
sponsori BigTable,
Facebook/Dig
g/Rackspace
Tipuri de Apache 2.0 Apache 2.0 GPL+FLOSS /
licenţiere licenţă
disponibile comercială
163
O analiză cantitativă
Evaluarea cantitativă a performanţelor celor trei

produse a avut două componente, una legată de dimensiunile
maxime ale unei baze de date care poate fi construită cu
produsul respectiv şi una legată de performanţa de viteză
propriu-zisă a unei baze de date de dimensiuni moderate
construite cu produsul respectiv.
Evaluare după dimensiunea instalărilor disponibile
Informaţiile utilizate pentru această evaluare au fost

obţinute din multiple surse. Nu vor fi furnizate valori
comparative pentru cel de-al treilea produs (MySQL), datorită
faptului că bazele de date NoSQL sunt proiectate, în mod
specific, pentru volume de date de mari dimensiuni,
neexistând, astfel, termeni de comparaţie în această direcţie. Se
ştie că cele mai mari instalări de MySQL care pot fi construite
fără memory caching şi sharding extins se situează în jurul a 1
milion de înregistrări de dimensiuni medii, peste această
dimensiune regăsirea informaţiei devenind prea lentă pentru a
fi utilă (Peters, 2010).
Nu există o măsură oficială pentru dimensiunea unei
instalări de baze de date, dar pot fi luaţi în considerare
următorii factori (valorile sunt preluate de pe site-urile
companiilor producătoare):
 Număr de înregistrări / rânduri / documente stocate:
din acest punct de vedere pentru Hbase sunt date
valori cuprinse între 6 şi 450 de milioane de
164
înregistrări, cele mai multe instalări aflându-se în

zona 6 la 25 de milioane de înregistrări; pentru
Cassandra sunt date valori de 2 până la 150 de
milioane de înregistrări;
 Numărul de noduri într-o instalare: 5 până la 110 de
noduri pentru Hbase, majoritatea instalărilor având
6 până la 20 de noduri; 4 până la 150 de noduri
pentru Cassandra, cu majoritatea instalărilor având
5 până la 25 de noduri;
 Dimensiunea maximă a unei instalări: este mai puţin
documentată, unele surse dând ca dimensiuni
maxime ale instalărilor existente în prezent de 140
de TB, pentru Hbase şi, respectiv,150 de TB, pentru
Cassandra.
Evaluare după performanţa transferului
Măsurătorile au fost efectuate utilizând ca aplicaţie de

benchmark produsul YCSB. Instalările celor trei produse pe
care s-au efectuat măsurătorile au avut aceleaşi dimensiuni, şi
anume:
 o bază de date de 120 de milioane de înregistrări de
dimensiuni reduse (1kB);
 6 noduri;
 dimensiune instalată de 0.12 TB.
Au fost măsurate performanţele la citire şi, respectiv,
scriere în două tipuri de medii considerate a fi reprezentative
pentru două clase reale de utilizări, şi anume o situaţie în care
165
numărul de operaţii de scriere este aproximativ egal cu

numărul de operaţii de citire (comportament tipic pentru o
aplicaţie OLTP) şi, respectiv, o situaţie în care numărul de
operaţii de scriere este mult mai redus decât numărul de
operaţii de citire – într-un raport de aproximativ 1 la 20
(comportament tipic pentru o aplicaţie OLAP). Rezultatele
măsurătorilor sunt prezentate în Figura 21 şi Figura 22 pentru
sistemele OLTP şi, respectiv, în Figura 23 şi Figura 24 pentru
sistemele OLAP. În cele patru grafice, pe abscisă este înscrisă
intensitatea activităţii simulate (în operaţii pe secundă), iar pe
ordonată este dată latenţa înregistrată (în milisecunde).
Figura 21 – Latenţa la citire într-un mediu OLTP (Cooper, Silberstein,

Tam, Ramakrishnan, & Sears, 2010)
166
Figura 22 – Latenţa la scriere într-un mediu OLTP (Cooper,

Silberstein, Tam, Ramakrishnan, & Sears, 2010)
Pornind de la aceste figuri, se pot trasa următoarele

concluzii cu privire la performanţa disponibilă pentru o
aplicaţie OLTP:
 peste o cantitate de aproximativ 7000 de operaţii de
citire sau scriere pe secundă, atât MySQL, cât şi
implementarea sa alternativă numită Sherpa devin
neutilizabile – latenţa devine prea mare pentru o
aplicaţie reală;
 performanţa la scriere a Hbase este mult mai bună
decât a celorlalte produse, dar acest lucru se
datorează faptului că operaţiile sunt realizate în
memoria RAM şi nu pe disk, aşa cum fac celelalte
produse. De asemenea, performanţa la scriere a
produselor Cassandra, Sherpa şi MySQL ar putea fi
167
îmbunătăţită prin utilizarea unui disc separat de

jurnalizare (Cooper, Silberstein, Tam,
Ramakrishnan, & Sears, 2010).
Figura 23 – Latenţa la citire într-un mediu OLAP (Cooper, Silberstein,

Tam, Ramakrishnan, & Sears, 2010)
În ceea ce priveşte performanţa disponibilă pentru o
aplicaţie OLAP, pe baza graficelor din Figura 23 şi Figura 24
se poate concluziona:
 într-un mediu în care numărul de operaţii de scriere
este mai redus, performanţele oferite de MySQL şi
Sherpa sunt sensibil mai bune decât în cazul
anterior, reuşind să ţină pasul cu produsele NoSQL
(deşi, ținând cont de faptul că dimensiunea bazei de
date supuse la benchmark nu a fost foarte mare,
această tendinţă s-ar putea să nu continue pentru
instalări mai mari);
168
Figura 24 – Latenţa la scriere într-un mediu OLAP (Cooper,

Silberstein, Tam, Ramakrishnan, & Sears, 2010)
 din nou Hbase obţine rezultate foarte bune la

scriere, datorită faptului că operaţiile sunt realizate
în memoria RAM şi nu pe disc.
În acest capitol doi au fost abordate soluţiile de

prelucrare a volumelor mari de date organizate structurat
(depozite de date). În ceea ce priveşte suportul fizic pentru
prelucrarea datelor, au fost prezentate două aspecte: prelucrarea
utilizând sisteme de calcul de înaltă performanţă şi prelucrarea
distribuită (sisteme cluster, sisteme grid şi sisteme cloud).
De asemenea, au fost abordate mijloace alternative de
creştere a perfomanţei de prelucrare, şi anume metodele
169
cunoscute sub numele generic de Prelucrări de Tip General

utilizând Unităţi de Procesare Grafică (General-Purpose
computing on Graphics Processing Units – GPGPU, GPGP sau
GP²U).
Performanţa de prelucrare a datelor a fost analizată
având în vedere cele două modalităţi de structurare: date
structurate şi date semistructurate.
Deşi bazele de date relaţionale şi NoSQL au unele
trăsături şi funcţionalităţi comune, comportamentul lor nu este
similar în diverse cazuri de utilizare. Acest lucru sugerează că
ele nu pot fi interschimbate pentru rezolvarea oricărei probleme
şi că, pentru fiecare tip de problemă în parte, ar trebui ales acel
tip de bază de date care se potriveşte mai bine situaţiei.
170
Partea a doua – viitorul Big Data
3 Soluții de structurare a volumelor mari de date

în sistemele NoSQL
3.1 Trecerea de la organizarea structurată a

volumelor mari de date la organizarea
semistructurată
3.1.1 Obligativitatea utilizării soluţiilor NoSQL

(conjectura lui Eric Brewer / teorema CAP)
Conjectura lui Brewer din anul 2000 s-a bazat pe

cercetările sale teoretice la UC Berkley şi pe observaţiile făcute
în timpul activităţii la Inktomi (Browne, 2010), deşi Brewer şi
alţii au comentat compromisurile care trebuie făcute în
sistemele de înaltă scalabilitate cu câţiva ani înainte de
momentul respectiv (Fox, Gribble, Chawathe, Brewer, &
Gauthier, 1997), (Fox & Brewer, Harvest, Yield, and Scalable
Tolerant Systems, 1999).
Practic, conjectura lui Brewer (mai cunoscută sub
denumirea de teorema CAP) spune că există trei cerinţe
primare de sistem atunci când e vorba de proiectarea şi
implementarea aplicaţiilor în medii distribuite şi anume:
consistenţa (Consistency – C), disponibilitatea (Availability –
A) şi toleranţa la căderea unei partiţii (Partition tolerance – P).
Teorema CAP afirmă că cele trei cerinţe primare nu pot fi
171
asigurate simultan (ci numai două câte două) (Gilbert & Nancy,
2002).
Ţinând cont de cele afirmate de această teoremă, există
doar câteva posibilităţi de implementare a aplicaţiilor în
sisteme distribuite şi anume:
 renunţarea la toleranţa la partiţionare, prin
amplasarea tuturor componentelor necesare pentru o
tranzacţie pe o singură maşină. Acest lucru nu evită
imobilizarea completă a sistemului prin defectarea /
blocarea maşinii gazdă, dar sunt eliminate măcar
efectele de desincronizare între partiţii. Bineînţeles,
acest lucru presupune şi faptul că sistemul nu este
de fapt distribuit, iar scalabilitatea este sever
limitată (în subcapitolele anterioare s-a afirmat şi
ilustrat cu date statistice faptul că toate sistemele
înalt scalabile sunt sisteme distribuite);
 Renunţarea la disponibilitate: o altă manieră de
lucru este oprirea serviciului de fiecare dată când
apare un eveniment nedorit de partiţionare până
când datele sunt din nou consistente. Controlul unui
sistem care operează în acest mod creşte
exponenţial în complexitate cu numărul de noduri.
În plus, în foarte puţine cazuri se poate renunţa la
utilizarea sistemului chiar şi pentru perioade scurte
de vreme;
 Renunţarea la consistenţă: în multe cazuri unele
inconsistenţe pot fi tolerate transformându-le în
excepţii de afacere care vor fi tratate prin diverse
mecanisme ale intreprinderii (relaţii cu clienţii etc.);
172
 Trecerea de la ACID la BASE: este de preferat ca

această trecere să nu fie privită în mod absolut, în
tehnologiile acestui moment ne-existând o graniţă
rigidă între cele două domenii.
Ultimul caz expus este şi cel care este cel mai uşor de
acceptat şi este de fapt cazul în care se încadrează sistemele
NoSQL. Pe cale de consecinţă logică, pentru aplicaţiile
bazate pe volume mari de date este nevoie de sisteme
distribuite, iar o soluţie bună pentru impasul reprezentat
de teorema CAP este reprezentată de utilizarea sistemelor
NoSQL.
3.1.2 Trăsături ale sistemelor NoSQL
Principalele trăsături ale sistemelor NoSQL sunt

următoarele:
1. modelează logic datele utilizând scheme de date
extensibile slab tipizate (mapări, familii de coloane,
documente, grafuri etc.) în locul modelării datelor în
tupluri ce urmează scheme relaţionale fixe;
2. sunt proiectate pentru scalare orizontală prin modele
de distribuire a datelor pe mai multe noduri,
respectând principiile teoremei CAP (a se vedea
subcapitolul anterior). Acest lucru se datorează
necesităţii de a suporta mai multe data center şi
provizionare dinamică de noduri (elasticitate);
3. pot asigura persistenţa datelor pe disc, în memorie,
în amândouă sau folosind alte dispozitive inserate în
sistem.
173
4. suportă diferite interfeţe NoSQL (în mod tipic mai

mult de una) pentru accesul la date.
Variaţiunile celor patru trăsături de mai sus duc la
apariţia câtorva trăsături cheie date în lista de mai jos împreună
cu exemple de produse care manifestă trăsăturile respective:
 Interfeţe (Figura 25): REST (HBase, CouchDB,
Riak etc.), MapReduce (HBase, CouchDB,
MongoDB, Hypertable etc.), Get/Put (Voldemort,
Scalaris etc.), Thrift (HBase, Hypertable, Cassandra
etc.), limbaje specifice ale API-urilor (MongoDB).
Interfeţe
Limbaje specifice
REST Map Reduce Get / Put Thrift
ale API-urilor
Figura 25 – Interfeţe disponibile

 Modele logice ale datelor (Figura 26): orientate pe
seturi cheie - valoare (Voldemort, Dynomite etc.),
orientate pe familii de coloane (BigTable, HBase,
Hypertable etc.), orientate pe documente (Couch
DB, MongoDB etc.), orientate pe grafuri (Neo4j,
Infogrid etc.)
Model logic al datelor
Bază de date de Bază de date de

Mapare chei-valori Familie de coloane
documente grafuri
Figura 26 – Modele logice ale datelor
174
 Modele de distribuţie a datelor (Figura 27):

consistenţă şi disponibilitate (HBase, Hypertable,
MongoDB etc.), disponibilitate şi partiţionabilitate
(Cassandra etc.). Combinaţia consistenţă şi
partiţionabilitate nu este suportată de nici unul
dintre produsele examinate.
Model de distribuţie a datelor

Suport pentru mai Suport pentru
Suport pentru CAP
multe Data Center provisionare dinamică
Figura 27 – Modele de distribuţie a datelor

 Persistenţa datelor (Figura 28): bazată pe memorie
(ex. Redis, Scalaris, Terrastore), bazată pe disc (ex.
MongoDB, Riak etc.), bazată pe o combinaţie de
memorie şi disc (ex. HBase, Hypertable,
Cassandra). Tipul de stocare utilizată relevă cazurile
de utilizare avute în vedere la proiectarea aplicaţiei.
În multe cazuri este preferată varianta combinată
memorie / disc pentru că asigură o combinaţie între
performanţă şi durabilitate prin stocare pe disc după
ce suficient de multe scrieri în memorie au fost
efectuate.
Persistenţa datelor
Combinaţie de Dispozitive externe
Bazată pe memorie Bazată pe disc
memorie şi disc inserate în sistem
Figura 28 – Tipuri de persistenţă a datelor
175
Încadrarea NoSQL în IT-ul de intreprindere
La momentul actual nu toate aplicaţiile de intreprindere

sunt uşor de modelat relaţional, aşa cum există şi aplicaţii care
nu au nevoie de proprietăţi ACID stricte (în special consistenţa
şi izolarea pot lipsi). De asemenea situaţia de azi diferă de cea
din anii 80 sau 90 atunci când marea majoritate a datelor
existente într-o intreprindere erau structurate, trebuiau generate
şi accesate într-o manieră controlată şi constituiau
“înregistrările” tranzacţiilor afacerii (Akella, Kubach, Löffler,
& Schmid, 2011). Fără discuţii, asemenea tipuri de date
continuă şi vor continua să existe şi întotdeauna vor trebui
modelate, stocate şi accesate utilizând SGBD relaţionale. Dar
pe lângă aceste date avem de-a face cu o explozie a volumelor
mari de date necontrolate, nestructurate şi orientate pe
informaţie care s-a petrecut în ultimii 15 ani odată cu apariţia
web-ului, a comerţului digital, a aplicaţiilor de socializare etc.
Intreprinderile nu au nevoie de SGBD-uri relaţionale pentru a
le stoca şi a le regăsi, dat fiind că proprietăţile cheie ale SGBD
relaţionale nu se potrivesc cu natura şi utilizarea acestor date
(Mazumder, 2010).
Figura 29 încearcă să sumarizeze noile modele din
Managementul informaţiei în intreprinderile centrate pe web.
Iar bazele de date NoSQL sunt o alegere mai bună pentru
tratarea acestor tendinţe (comparativ cu SGBD-urile
relaţionale) ţinând cont de suportul pe care îl oferă astfel de
sisteme datelor nestructurate, scalabilităţii orizontale prin
partiţionare, înaltei disponibilităţi etc.
176
Accesul la informaţie
Modelul informaţiei
•Mai multe operaţii de cautare
bazate pe informaţie limitată •Mai multe atribute per
în locul unui număr mai redus entitate
de interogări complexe •Necesitatea de a stoca din ce
•Mai mulţi utilizatori în ce mai multă "informaţie
•Mai predictibilitate în adiţională"
modelele de acces •Mai multă lipsă de structură
•Înalta disponibilitate este Datele •Entităţile sunt mai
obligatorie pentru ca intreprin dependente în natură, uneori
utilizatorii să poată avea în ierarhii pe multiple nivele
acces oricând este nevoie derii
Modelul de stocare
•Volume mai mari de date

•Necesitatea de a fi pregătiţi
pentru scalare în exterior şi
virtualizare
•Necesitatea de a fi pregătiţi
pentru migrarea în sisteme
cloud externe
Figura 29 – Modele nou apărute în Managementul informaţiei

Următoarele sunt câteva cazuri de utilizare care suportă
punctul de vedere de mai sus (Chaudhuri, 2012):
 Log Mining - jurnale de server, jurnale de aplicaţie,
jurnale de activitate a utilizatorilor sunt generate în
multiple noduri ale clusterelor. Pentru rezolvarea
problemelor de producţie, uneltele de Log mining
pot accesa jurnale peste mai multe servere, pot
relaţiona şi analiza datele din ele. Astfel de soluţii
de analiză sunt uşor de implementat cu baze de date
NoSQL;
 Înţelegerea facilităţilor de socializare - multe
intreprinderi din zilele noastre furnizează
177
utilizatorilor lor (utilizatori interni, clienţi,

parteneri) facilităţi de socializare prin forumuri,
bloguri etc. Mining-ul în aceste date nestructurate
poate duce la concluzii de maximă importanţă
referitoare la opiniile utilizatorilor, de aşa natură
încât să se poată îmbunătăţi serviciile oferite.
Utilizarea sistemelor NoSQL se potriveşte perfect în
acest context;
 Integrarea feed-urilor de date externe - în multe
cazuri intreprinderile trebuie să utilizeze date venind
de la partenerii lor. Desigur, chiar şi după un număr
de discuţii şi negocieri, intreprinderile au un control
redus asupra formatului datelor care le sunt
furnizate. De asemenea există multe situaţii în care
aceste formate se schimbă frecvent datorită
schimbărilor din afacerile partenerilor. Bazele de
date NoSQL pot fi utilizate cu foarte mult succes
pentru a rezolva aceste probleme cât timp o soluţie
ETL (extracţie / transfer / încărcare) este proiectată
şi dezvoltată;
 Sisteme EAI (integrarea aplicaţiilor de
intreprindere) cu volume mari de date - cele mai
multe intreprinderi au volume mari de date în
circulaţie prin sistemele EAI (fie ele bazate pe
produs sau dezvoltate personalizat). Aceste mesaje
care circulă prin EAI trebuie uzual stocate în mod
persistent pentru scopuri de siguranţă şi auditare.
Din nou bazele de date NoSQL pot fi potrivite ca
sisteme de stocare a datelor pentru acest scenariu,
178
ţinând cont de variaţia din structura datelor între

sistemele sursă şi destinaţie, dar şi de volumul mare
de date vehiculate;
 Sisteme de procesare de front end - dată fiind
explozia comerţului digital (în termeni de volum al
comenzilor), numărul de aplicaţii şi de cereri de
serviciu trimise prin diverse canale către sistemele
vânzătorilor en-detail, ale băncilor, furnizorilor de
asigurări, ale furnizorilor de servicii de
divertisment, ale firmelor de logistică etc. este
enorm. De asemenea, ţinând cont de restricţiile şi
modelele comportamentale asociate cu diverse
canale, formatele în care informaţia este capturată
diferă puţin în fiecare caz şi diverse tipuri de reguli
sunt impuse. Peste aceasta, multe dintre aceste
cereri nu au nevoie de procesare şi reconciliere
imediată la back end. Mai degrabă este nevoie ca
aceste cereri să fie capturate fără nicio întrerupere,
fără să conteze momentul şi locul de unde
utilizatorii formulează comenzile. Mai târziu
informaţiile capturate pot fi reconciliate şi
actualizate cu datele din sistemele back end după
care utilizatorilor li se actualizează statutul
comenzilor lor. Acest scenariu este un alt exemplu
în care sistemele NoSQL pot fi utilizate iniţial
pentru stocarea intrărilor de la utilizatori. În acest
caz potrivirea bazelor de date NoSQL este chiar
perfectă ţinând cont de volumele mari de date
vehiculate, diferenţele în structura datelor de intrare
179
şi faptul că se poate accepta consistenţa în cele din

urmă, aceasta urmând să fie obţinută în etapa de
reconciliere;
 Servicii de intreprindere de managementul
conţinutului - managementul conţinutului este
utilizat pe larg la momentul actual pentru diverse
scopuri, în variate componente funcţionale ale
intreprinderii cum ar fi departamentele de vânzări,
marketing, vânzări en-detail sau resurse umane. De
cele mai multe ori acest lucru presupune şi punerea
în comun a cerinţelor diverselor grupuri
(concretizate în diferenţe în structura metadatelor)
într-o platformă comună de servicii pentru
managementul cunoştinţelor. Bazele de date NoSQL
sunt o bună potrivire şi în acest context;
 Unificări şi achiziţii - intreprinderile înfruntă
provocări uriaşe în timpul unificărilor şi achiziţiilor,
dat fiind că sunt nevoite să unifice sisteme diferite
având aceleaşi funcţii. Bazele de date NoSQL pot fi
utilizate pentru rezolvarea acestei probleme fie prin
crearea rapidă a unei aglomerări de date temporare,
fie prin crearea unei aglomerări de date permanente
care va acomoda structurile aplicaţiilor existente ale
companiilor care se unesc.
În următoarele paragrafe, pornind de la Figura 30, vor fi
expuse câteva beneficii majore derivate din caracteristicile de
bază ale bazelor de date NoSQL (aşa cum au fost ele prezentate
mai sus), în cele trei domenii majore de decizie pentru orice
180
intreprindere: reducerea costurilor, timp de răspuns mai scăzut

şi calitate superioară (Bizer, Boncz, Brodie, & Erling, 2011).
Flexibilitatea afacerii
Model al datelor extensibil (Adaptare

la schimbările în cerinţe)
Scalabilitate orizontală (Adaptare la

schimbările de volum)
Cost total de utilizare mai

Satisfacţia utilizatorilor finali
scăzut
Abilitatea de a rula pe sisteme "de pe raft" Perfomanţă mai bună (Timp de căutare
(reduce investiţiile şi costurile de operare) mai scăzut pentru date dsitribuite)
Caracteristici predictibile la creşterea Înaltă disponibilitate (Sistemul este

volumului de date (costuri mai scăzute ale întotdeauna disponibil pentru utilizatorii
mentenabilităţii) finali)
Figura 30 – Beneficii cheie derivate din caracteristicile de bază ale

sistemelor NoSQL
Agilitatea afacerii – timp de răspuns mai redus
Bazele de date NoSQL pot creşte agilitatea afacerii în

două moduri principale, descrise în cele ce urmează.
181
Modelul de date fără schemă ajută în acomodarea

oricăror schimbări de afacere oferind un timp de răspuns mai
scăzut şi impact mai redus asupra aplicaţiilor şi funcționalității
existente. În cele mai multe cazuri efortul de migrare pentru
orice schimbare va fi aproape zero.
Scalabilitatea orizontală creează capabilitatea inerentă
de a suporta trafic mult mai mare din partea utilizatorilor de aşa
natură încât să acomodeze pentru variaţiuni sezoniere sau
schimbări bruşte în modelul de utilizare. Arhitecturile orientate
pe scalabilitate orizontală sunt de asemenea primul pas către
sisteme gen cloud care în mod esenţial asigură continuitatea
afacerii în diverse situaţii de utilizare.
O mai mare satisfacţie a clientului – calitate superioară
În IT-ul intreprinderilor de azi calitatea aplicaţiilor este

în principal decisă de satisfacţia utilizatorilor. Utilizarea
bazelor de date NoSQL poate ajuta la atingerea acestui
deziderat prin tratarea unor probleme ridicate de utilizatori
(care sunt de altfel şi cele mai frecvente şi mai dificil de
rezolvat).
Bazele de NoSQL creează oportunităţi de îmbunătăţire
drastică a performanţelor aplicaţiilor. Conceptul de bază al
distribuirii datelor asigură faptul că operaţiile de I/O pe discuri
nu mai sunt punctul de gâtuire din performanţa aplicaţiei. Mai
degrabă performanţa devine guvernată de rata de transfer. Mai
mult decât atât, multe din soluţiile NoSQL oferă şi paradigme
de generaţie nouă de prelucrare rapidă a datelor precum
182
MapReduce, Sorted Columns, Bloom Filter, Appended only

BTree, Memtable etc.
Un alt aspect important în asigurarea satisfacţiei
utilizatorului este disponibilitatea. Utilizatorii doresc să
acceseze aplicaţiile aşa cum şi atunci când doresc, de aşa
natură încât să îşi ducă la bun sfârşit diversele operaţii atunci
când găsesc timp pentru ele. Astfel, indisponibilitatea unei
aplicaţii devine ceva ce trebuie evitat cu orice preţ. Cele mai
multe dintre bazele de date NoSQL sunt echipate să suporte
astfel de cerinţe de disponibilitate, ţinând cont de conceptele de
consistenţă strictă sau consistenţă în cele din urmă.
Cost total de utilizare mai scăzut
În piaţa competitivă a momentului, unde cheltuielile cu

IT-ul ale intreprinderii sunt urmărite intens, obţinerea calităţii
dorite la un cost cât mai scăzut este un obiectiv principală. Din
acest punct de vedere, bazele de date NoSQL depăşesc
considerabil SGBD-urile relaţionale, în special atunci când
volumele de date care trebuie stocate şi prelucrate sunt mari.
Cerinţa de bază de scalabilitate orizontală asigură faptul
că sistemele NoSQL pot rula şi pe sisteme de calcul obişnuite.
Acest lucru reduce nu numai costurile de achiziţionare a
hardware-ului, dar şi costurile de operare (electricitate,
întreţinere etc.). Tot pe această cale este asigurat şi faptul că
astfel de aplicaţii pot utiliza infrastructură de generaţia
următoare (cloud, data center virtualizat etc.).
Pe termen lung, o necesitate mai scăzută de mentenanţă
este de asemenea un beneficiu de cost. Spre exemplu, în cazul
183
SGBD-urilor relaţionale care stochează volume mari de date,

creşterea performanţei acestora este o artă care necesită
cunoştinţe specializate (care la rândul lor au un cost ridicat).
Prin comparaţie, bazele de date NoSQL furnizează întotdeauna
răspunsuri rapide şi uniforme chiar dacă volumul de date creşte
în salturi. Indexarea şi cache-ingul au acelaşi comportament.
Cu produsele NoSQL, dezvoltatorii trebuie să se ocupe mai
puţin de hardware, discuri, reindexare, layout-ul fişierelor
ş.a.m.d., timpul astfel câştigat putând fi folosit pentru
implementarea propriu-zisă a aplicaţiei.
3.2 Soluții de organizare semistructurată a volumelor

mari de date
Promisiunile date de sistemele NoSQL au generat mult

entuziasm, dar există încă o seamă de obstacole de depăşit până
când aceste sisteme să poată deveni atractive pentru o bună
parte din intreprinderi. Acest subcapitol încearcă să comenteze
câteva dintre cele mai mari provocări apărute (Tudorică,
Challenges for the NoSQL systems: Directions for Further
Research and Development, 2013).
184
• Acceptarea unui compromis între

precizie, viteză şi federalizare
(forma "de intreprindere" a Asigurarea
Cadru teoremei CAP) portabilită-
mental • Inerţia de îndepărtare de soluţiile ţii
Selecţia
SGBDR Calea de
cazurilor de
adoptare
utilizare
Provocări
• Starea incipientă a NoSQL
Bugetare tactice Economia
de scară
• Lipsa de standarde
Lipsa de
încredere
Selecţia Suportul
produsului producţiei
Figura 31 – Provocări la adresa intreprinderilor care doresc să adopte

soluţii NoSQL
În afară de nivelul ridicat de rezistenţă dat de anumite

idei preconcepute şi de lipsa de încredere, cele mai importante
provocări tactice întâmpinate la momentul actual sunt cele
descrise în cele ce urmează (sintetizate în Figura 31 de mai sus)
(Jacobs, 2009), (Poulovassilis, 2013), (Labrinidis & Jagadish,
2012).
Identificarea aplicaţiilor / scenariilor de utilizare

potrivite pentru baze de date NoSQL
Deşi este uşor să se dovedească teoretic că nu toate

datele de intreprindere necesită un sistem relaţional cu
constrângeri ACID, perioada lungă de timp în care au fost
utilizate numai soluţii de acest tip fac dificilă alegerea datelor
care pot fi prelucrate şi stocate folosind soluţii ne-relaţionale.
Cei mai mulţi manageri IT (dar şi angajaţi din domeniul IT
care au responsabilităţi legate de aplicaţii) nu au o idee clară
185
despre nivelul de performanţă ce se poate atinge şi continuă să

rămână adversari ai ideii îndepărtării (parţiale) de SGBD
relaţionale. Datele constituie cel mai valoros bun al IT-ului de
intreprindere. Din acest punct de vedere, abilitatea de a lua
decizii pentru administrarea aceloraşi date folosind o soluţie
care nu este atât de înrădăcinată şi de larg răspândită presupune
utilizarea unui alt cadru mental, dar şi suport susţinut (şi chiar
încurajare / insistenţă) din partea managementului de vârf
(Bollier, 2010).
Selectarea soluţiei cele mai potrivite
Următoarea provocare majoră este identificarea

produsului sau a uneltei potrivite pentru a fi utilizată ca bază de
date NoSQL. La momentul actual sunt disponibile mai mult de
25 de produse / soluţii diferite (Edlich, 2013) (multe dintre ele
au fost menţionate în subcapitolul 1.2) cu abordări diferite ale
celor patru trăsături fundamentale (a se vedea şi subcapitolul
3.1). Deoarece în mod tipic fiecare dintre produsele disponibile
tratează puţin diferit aceste patru trăsături fundamentale este de
obicei foarte dificilă selecţia unui produs care să acopere toate
necesităţile. În trecutul recent, această stare de lucruri a dus în
câteva cazuri chiar la adoptarea de soluţii NoSQL diferite în
diversele compartimente ale unei intreprinderi, lucru care a
avut efecte negative, împingând câteodată la readoptarea de
soluţii relaţionale din simpla nevoie de standardizare (Boyd &
Crawford, Six Provocations for Big Data, 2011).
186
Obţinerea economiei de scară
Această provocare derivă practic din cea de la punctul

anterior. Dacă o organizaţie este nevoită să utilizeze multiple
soluţii ne-relaţionale (din cauza faptului că nici una dintre ele
nu îndeplineşte toate condiţiile) asigurarea economiei de scară
în termeni de personal (dezvoltatori, administratori, personal de
suport), de infrastructură (costuri cu hardware-ul, de licenţiere,
de suport şi de consultanţă) precum şi în termeni de structură
(componente comune şi servicii) devine o problemă dificilă. O
asemenea situaţie, comparată cu o situaţie de utilizare a unui
SGBD relaţional, devine cu adevărat semnificativă, dat fiind că
majoritatea organizaţiilor îşi rulează aglomerările de date ca
servicii de date concurente.
Obţinerea portabilităţii soluţiei
Ţinând cont de stadiul incipient în care se află bazele de

date NoSQL, este de aşteptat ca în anii următori să apară o
mulţime de modificări în termeni de consolidare a furnizorilor
de soluţii, evoluţie a facilităţilor şi standardizare. Din acest
punct de vedere, cea mai bună strategie ar fi ca o intreprindere
să nu se fixeze puternic pe un anume produs / soluţie
disponibilă azi, de aşa natură încât să se poată muta cu uşurinţă
pe un eventual produs mai bun. Dată fiind situaţia curentă a
produselor / serviciilor NoSQL, care lucrează de cele mai
multe ori în moduri divergente, portabilitatea devine un subiect
important de luat în considerare atunci când managerii dintr-o
anume organizaţie decid să utilizeze produse ne-relaţionale.
187
Acest lucru este necesar pentru pura protecţie a investiţiilor

curente.
Obţinerea tipului potrivit de suport. Evaluarea

complexităţii dezvoltării de aplicaţii şi a administrării
Nu foarte multe dintre bazele de date NoSQL

enumerate în subcapitolul 1.2 au în acest moment soluţii de
suport pentru organizaţii externe. Chiar şi acelea care au o
astfel de soluţie, nu se pot compara cu nume mari precum
Oracle, IBM sau Microsoft. În special suportul pentru
recuperare de date, back-up şi reparare ad-hoc a datelor este o
mare problemă în mintea personalului de decizie, dat fiind că
multe dintre bazele de date NoSQL nu oferă mecanisme
robuste de rezolvare a acestor probleme.
Există milioane de dezvoltatori în lume, în fiecare
segment de afaceri în parte, care sunt familiarizaţi cu
conceptele şi programarea SGBD-urilor relaţionale. Prin
contrast, aproape toţi dezvoltatorii de aplicaţii NoSQL încă
învaţă. Situaţia va fi desigur rezolvată natural cu trecerea
timpului, dar pentru moment e mult mai uşor de găsit un
programator sau administrator experimentat pentru o aplicaţie
relaţională decât un expert în NoSQL.
Este adevărat că ţintele proiectate ale multora dintre
aplicaţiile NoSQL sunt de a oferi o soluţie cu zero
administrare, dar realitatea curentă nu atinge încă acest rezultat.
Sistemele NoSQL de azi necesită destul de multe cunoştinţe
pentru instalare şi destul de mult efort pentru întreţinere.
188
Bugetarea pentru costul global
În comparaţie cu soluţiile competitorilor majori din

lumea SGBD-urilor relaţionale, despre SGBD-urile NoSQL nu
se cunosc în mod tipic foarte multe date legate de performanţă
sau scalabilitate. Acest lucru pune persoanele de decizie dintr-o
intreprindere într-o situaţie fără indicii legate de cât trebuie
cheltuit pe hardware, licenţe, management de infrastructură şi
suport. Aceasta este o piedică majoră în calea efectuării unei
estimări bugetare. Din acest motiv, soluţiile NoSQL sunt încă
evitate în favoarea soluţiilor relaţionale cunoscute.
Uneori, chiar dacă astfel de valori sunt disponibile, ar
putea să nu fie suficiente pentru a crea un model de cost total
de utilizare (în sensul de a compara cu produs relaţional în
termeni de analiză de cost Capex+Opex). De multe ori,
numărul mare de sisteme de calcul necesare pentru asigurarea
scalabilităţii orizontale face ca persoanele de decizie să prefere
la prima vedere o soluţie clasică cu scalabilitate verticală (deşi
costurile acesteia din urmă ar putea fi mai mari la o analiză
completă de cost total de utilizare).
Maturitate
SGBD-urile relaţionale sunt utilizate de o lungă

perioadă de vreme. Partizanii NoSQL vor argumenta că această
“vârstă înaintată” este un semn al învechirii lor dar, pentru
majoritatea managerilor IT, maturitatea soluţiilor relaţionale dă
siguranţă. În majoritate, sistemele relaţionale sunt stabile şi
bogate în funcţionalitate. Prin comparaţie, cele mai multe
189
alternative NoSQL sunt în versiuni pre-producţie, cu multe

facilităţi cheie absente încă. O astfel de facilitate absentă în
multe cazuri este un utilitar matur de administrare (cu o
interfaţă grafică uşor de utilizat şi o multitudine de funcţii
oferite). Cercetarea practică descrisă în cadrul prezentei lucrări
(capitolul 0) vizează acest subiect.
Activitatea la vârful tehnologiei este o perspectivă
atractivă pentru mulţi dezvoltatori, dar intreprinderile trebuie să
manifeste o precauţie extremă faţă de astfel de produse.
OLAP şi Inteligenţa Afacerii
Bazele de date NoSQL au evoluat pentru a acoperi

cerinţele crescătoare ale aplicaţiilor moderne Web 2.0. În
consecinţă, cele mai multe facilităţi oferite sunt orientate spre
acoperirea acestor cerinţe. Dar datele dintr-o aplicaţie au
valoare pentru afacere dincolo de ciclul insert-read-update-
delete al unei aplicaţii Web tipice. Intreprinderile analizează
informaţia din bazele de date de corporaţie pentru a îşi creşte
eficienţa şi competitivitatea, iar Inteligenţa Afacerii este un
subiect important pentru toate companiile de dimensiuni medii
sau mari.
Bazele de date NoSQL oferă puţine facilităţi pentru
interogări ad-hoc. Chiar interogările simple necesită o oarecare
expertiză în programare, iar uneltele de Inteligenţa Afacerii
disponibile în acest moment nu oferă conectivitate către baze
de date NoSQL (Cuzzocrea, Song, & Davis, 2011).
O oarecare soluţie pentru această stare de lucruri este
furnizată de soluţii nou apărute precum HIVE sau PIG, care pot
190
uşura accesul la date stocate în clustere Hadoop şi poate, peste

ceva vreme, la alte baze de date NoSQL (Bonnet, Laurent,
Sala, Laurent, & Sicard, 2011). Quest Software a dezvoltat de
asemenea un produs - Toad for Cloud Databases - care permite
efectuarea de interogări ad-hoc pe o varietate de baze de date
NoSQL (Dell Corporation, 2013).
Concluzii
Bazele de date NoSQL capătă o importanţă crescătoare

în peisajul bazelor de date şi atunci când sunt utilizate cum
trebuie oferă beneficii reale. Trebuie notat totuşi că
intreprinderile ar trebui să fie conştiente de limitările şi
problemele care sunt asociate cu astfel de baze de date.
3.3 Implementarea unei soluții de organizare
semistructurată a volumelor mari de date
Toate cele expuse în subcapitolul anterior nu înseamnă

că intreprinderile nu ar trebui să adopte soluţii NoSQL
(aşteptând să vadă care este evoluţia acestor produse). Este
adevărat că soluţiile nerelaţionale sunt într-un stadiu incipient
de adopţie pe scară largă de către intreprinderi. Dar potenţialul
major al bazelor de date NoSQL pentru intreprinderile
viitorului nu ar trebui pierdut din vedere. Acest lucru este în
special adevărat dat fiind faptul că intreprinderile se vor
confrunta în viitorul apropiat cu volume din ce în ce mai mari
de date semi-structurate / nestructurate şi consistente în cele
din urmă, în timp ce volumele de date strict structurate şi care
respectă filosofia ACID nu vor avea o evoluţie similară,
191
rămânând la nivele scăzute. Deci este important ca, în acest

moment cel puţin, să se treacă la obişnuirea factorilor de
decizie din intreprinderi cu necesitatea de a utiliza produse ne-
relaţionale pentru manipularea datelor intreprinderii. În această
trecere este necesară introducerea / rezolvarea / cercetarea /
dezvoltarea a cel puţin câtorva elemente cheie de natură
tehnologică, umană şi procesuală. Figura 32 redă o imagine de
ansamblu a acestor elemente, ele urmând a fi detaliate în
subcapitolele următoare.
Construirea Modelarea Construirea de
Adoptarea unui abstracţiilor de scalabilităţii şi redundanţă Construirea unei
singur produs / acces la date performanţei explicită platforme de
soluţie (asigură un (dezvoltă o bună (protecţie servicii de date
(găsirea celui anume nivel de înţelegere a împotriva (izolează
mai potrivit) siguranţă la conceptelor pierderilor de complexitatea)
schimbare) cheie) date)
Tehnologie
Punerea la punct a unei Dezvoltarea relaţiilor cu comunitatea

echipe dedicate (care produsului (care este interesată în
crede în produs) buna sa funcţionare)
Oameni
Dezvoltare iterativă
(Demonstraţie → Testare → Punere la punct → Extinde →
Standardizare)
Proces
Figura 32 – Elemente necesar a fi obţinute pentru adoptarea cu succes

a utilizării unui sistem NoSQL într-o aplicaţie de intreprindere
Adoptarea unui (singur) produs
Există o mulţime de soluţii NoSQL în acest moment pe

piaţă, soluţii care oferă abordări alternative ale celor patru
trăsături cheie expuse în subcapitolul 3.1. În acelaşi timp,
192
diferitele cazuri de utilizare dintr-o intreprindere pot impune

diverse tipuri de caracteristici. Evident, aşa cum s-a argumentat
mai sus folosirea mai multor produse într-o intreprindere nu
este dezirabilă, măcar din perspectiva necesităţii economiei de
scară. Soluţia este, evident, utilizarea unui singur produs,
alegerea acestuia depinzând de aplicaţiile ţintă. Este de reţinut
şi faptul că deşi în anumite produse anumite facilităţi ar putea
lipsi, ele pot fi obţinute de obicei pe căi alternative sau urmează
oricum să fie introduse în versiuni ulterioare. De asemenea,
majoritatea produselor care vor ajunge la maturitate în viitorul
apropiat vor oferi la acel moment soluţii diferite prin
configurare. Astfel, atât timp cât un produs acoperă majoritatea
necesităţilor (chiar dacă nu pe toate) el poate fi considerat ca
fiind o bună opţiune de start.
Regulile de bună practică pentru selecţia unui produs /
soluţie sunt (Boyd & Crawford, Six Provocations for Big Data,
2011), (Boyd & Crawford, Critical Questions For Big Data,
2012) :
 se va acorda o importanţă mai mare suportului oferit
de produs pentru modelul logic al datelor necesar
pentru aplicaţie. Acest lucru va decide în esenţă cât
de uşor se va adapta aplicaţia la diverse necesităţi
prezente sau viitoare ale afacerii;
 se va investiga capacitatea modelului fizic al datelor
oferit de produs pentru a se obţine o imagine a
capacităţii produsului de a se scala pe orizontală, a
disponibilităţii, consistenţei şi partiţionabilităţii
necesare conform cu necesităţile aplicaţiilor. Tot în
193
acest punct se vor aprecia şi posibilităţile de backup

şi mecanismele de recuperare;
 interfaţa oferită trebuie să fie conformă cu mediul
standard de operare utilizat în intreprindere. Ţinând
cont de faptul că fiecare produs NoSQL oferă de
obicei o varietate de interfeţe, această cerinţă poate
fi uşor acoperită;
 modelul de persistenţă oferit nu este foarte
important atât timp cât produsul oferă scalabilitate
orizontală (Bhatewara & Waghmare, 2012).
Pentru a ilustra regulile de bună practică enunţate, în
rândurile următoare va fi făcută o analiză comparativă a unui
set de produse NoSQL. O astfel de analiză poate fi un bun
punct de pornire pentru intreprinderi care se gândesc serios la
adoptarea unui produs ne-relaţional chiar în acest moment.
Analiza începe prin eliminarea din setul de produse
listate în subcapitolul 1.2.5 a celor care sunt în mod evident
nepotrivite pentru utilizarea în contextul de intreprindere.
Etapele din care se alcătuieşte procesul de filtrare sunt
următoarele (Tauro, Aravindh, & Shreeharsha, 2012):
 pentru cele mai multe intreprinderi abilitatea
aplicaţiilor de a suporta structuri de date rezonabil
de complexe este obligatorie. Cazul contrar ar
însemna ca ar cădea în responsabilitatea aplicaţiei să
implementeze structurile complexe, ceea ce este
foarte greu de făcut. Această condiţie este
îndeplinită de toate produsele din zona perechi de
chei – valori până la scheme relaţionale. Din acest
194
punct de vedere, produse precum Voldemort, Tokyo

Cabinet etc. nu pot fi utilizate;
 un al doilea criteriu este abilitatea de a suporta
volume mari de date prin scalabilitate orizontală
bazată pe partiţii / shard-uri şi la un preţ scăzut.
Absenţa unei astfel de abilităţi elimină aproape toate
avantajele bazelor de date NoSQL faţă de cele
relaţionale. În acest mod, anumite produse precum
Neo4J (deşi acesta are un model foarte bogat de
date bazat pe grafuri), Redis, sau CouchDB sunt
eliminate de pe listă;
 un ultim criteriu este oferirea unei forme oarecare
de suport comercial pentru intreprinderi. Acest
criteriu elimină produse precum Cassandra (există
şanse ridicate ca acest produs să capete curând
suport tehnic fie prin Rackspace, fie prin Cloudera,
ținând cont că produsul Cassandra este deja utilizat
în sisteme comerciale precum Twitter, Digg sau
Facebook).
Odată efectuat procesul de filtrare de mai sus, pe lista
produselor comparate rămân MongoDB, Riak , Hypertable şi
HBase. Tabelul următor sumarizează caracteristicile cheie ale
acestor patru produse. O intreprindere poate evalua propriile
cerinţe detaliate în raport cu acest tabel atunci când doreşte
selecţia unei soluţii NoSQL din lista scurtă vizată.
195
Tabelul 9 – O analiză comparativă utilizabilă în stabilirea sistemului

NoSQL potrivit pentru o anumită aplicaţie8
Facilităţi MongoDB Riak HyperTable HBase
Model logic al Rich Rich Familii de Familii de
datelor Document cu Document coloane coloane
suport pentru
documente
imbricate
Suport pentru CA AP CA CA
CAP
Adăugarea sau Suportată Suportată Suportată Suportată
eliminarea
dinamică a unui
nod
Suport multi Suportat Suportat Suportat Suportat
data center
Interfeţe O varietate de JSON peste REST, Thrift, C++, Thrift
API-uri HTTP Java
specifice
pentru
limbaje de
programare
(Java,
Python, Perl,
C# etc.) +
REST
Model de Disc Disc Memorie + Memorie +
persistenţă Disc (ajustabil) Disc
(ajustabil)
Performanţă 4 (produs 5 (produs scris 4 (produs scris 3 (produs
comparativă (pe scris în C++) în Erlang) în C++) scris în Java)
o scară de la 1
8
tabel construit din specificaţiile produselor analizate
196
la 5)
Suport 10gen.com Basho Hypertable Inc Cloudera
comercial Technologies
Construirea abstracţiilor pentru accesul la date
Construcţia unui strat separat de abstractizare pentru

accesul la datele din bazele de date NoSQL este obligatorie.
Existenţa unui astfel de abstract este avantajoasă în mai multe
moduri. În primul rând dezvoltatorii de aplicaţii nu trebuie să
ţină cont de detaliile de nivel jos ale soluţiei. Acest lucru
avantajează scalarea în termeni de personal instruit. Tot acest
lucru uşurează şi modificarea pe viitor a soluţiilor dezvoltate
dacă acest lucru este necesar. De asemenea, acest lucru permite
ca diversele cerinţe ale mai multor aplicaţii să poată fi
rezolvate într-o manieră standardizată (precum SQL, eventual
fără facilităţi complexe precum JOIN, GROUP BY etc.)
(Graefe, 1993). Spre exemplu, în interfaţa C# / .NET pentru
MongoDB a fost adăugat de curând un astfel de strat de
abstractizare reprezentat prin biblioteca MongoDB.Linq care
implementează componenta .NET Language Integrated Query
peste MongoDB (MongoDB Inc., 2013).
Crearea unui model pentru performanţă şi scalabilitate
Fără legătură cu soluţia care a fost aleasă, modelarea

scalabilităţii şi performanţei utilizând tehnici standardizate
(precum Queuing Network Model, Layered Queuing
Network etc.) este extrem de recomandată. În urma acestei
197
analize vor fi obţinute date care pot fi utilizate pentru

dimensionarea grosieră a server-elor şi respectiv pentru
proiectarea topologiei cluster-ului, dar şi pentru estimarea
costului de licenţiere, administrare etc. Această analiză va
deveni în esenţă intrarea primară pentru toate formele de
bugetare, ajutând astfel la luarea unei decizii.
Construcţia redundanţei explicite
Pentru a preveni orice pierdere de date, nu există altă

soluţie decât replicarea datelor într-un server de back-up. Deşi
multe dintre serverele de baze de date NoSQL oferă replicare
automată, totuşi ele prezintă şi un punct unic de defectare
(nodul master). Din acest motiv este mai bine ca datele să fie
protejate printr-un back-up secundar iar pentru recuperarea şi
repararea automată a datelor să fie disponibile script-uri
prefabricate. Pentru a putea asigura asemenea măsuri este
necesară înţelegerea modelului fizic al produsului NoSQL,
identificarea opţiunilor pentru posibilele mecanisme de
recuperare şi examinarea acestor opţiuni pentru a vedea dacă
ele corespund cerinţelor şi practicilor de intreprindere. Din
acest punct de vedere, produsul MongoDB oferă o
funcţionalitate superioară, permiţând crearea de seturi de
replici (MongoDB Inc., 2013).
198
Construirea unei platforme pentru servicii comune de

date
Precum în cazul bazelor de date relaţionale comune de

servicii, pot fi construite baze de date NoSQL comune de
servicii pentru a obţine economie de scară în termeni de
infrastructură şi suport. O astfel de unificare ajută şi la
schimbarea şi îmbunătăţirea pe viitor a aplicaţiilor. Unificarea
ar trebui să fie ţinta finală pe lista de necesităţi de maturizare a
produsului (de atins pe termen mediu sau lung). Chiar dacă e o
ţintă pe termen lung, vizualizarea ei încă de la bun început va
ajuta la luarea unei decizii corecte atunci când aceasta este
necesară.
Punerea la punct a unei echipe dedicate în intreprindere
În fiecare intreprindere există un număr de oameni care

manifestă interes pentru învăţarea de concepte noi,
neconvenţionale. Formarea unui grup din astfel de indivizi care
să îşi petreacă o parte din timp sau chiar tot timpul de lucru
pentru a cerceta şi evalua evoluţia lucrurilor în domeniul
NoSQL, problemele şi provocările cunoscute, ideile din
următoarea generaţie, va ajuta în direcţionarea proiectelor care
utilizează o astfel de tehnologie. De asemenea un astfel de grup
poate ajuta persoanele de decizie prin eliminarea miturilor şi
furnizarea de informaţii corecte.
199
Dezvoltarea relaţiilor cu comunitatea produsului
După adoptarea unui anumit produs are sens

dezvoltarea unei relaţii cu comunitatea produsului respectiv de
aşa natură încât intreprinderea şi comunitatea să se ajute
reciproc. Cele mai multe produse NoSQL au comunităţi foarte
active care sunt mai mult decât doritoare să ajute. O relaţie de
acest tip va ajuta fiecare dintre părţi. Cunoaşterea de la bun
început a problemelor şi soluţiilor poate ajuta intreprinderea în
luarea deciziilor referitoare la anumite funcţionalităţi sau
versiuni. De asemenea intreprinderea poate influenţa evoluţia
produsului prin solicitarea de facilităţi (importante atât pentru
organizaţie, cât şi pentru comunitate). Pe de altă parte
comunitatea este cea care cunoaşte problemele de detaliu,
cunoaştere necesară pentru a face ca un produs să fie robust şi
bogat în facilităţi. De asemenea, dezvoltările de succes din
intreprinderi medii sau mari ajută comunitatea să evolueze.
Dezvoltarea iterativă
Prin comparaţie cu maturitatea relativă a SGBD-urilor

relaţionale, singura cale pentru produsele NoSQL de a atinge
acelaşi stadiu cu riscuri minime este abordarea unei
metodologii de dezvoltare iterative. Spre exemplu ideea
construirii unei platforme comune de servicii de date, împreună
cu introducerea unei abstractizări standardizate a datelor nu se
poate întâmpla peste noapte, dintr-un singur pas. Mai degrabă
lucrul după un model orientat pe iterativitate şi re-fabricare va
duce la obţinerea rezultatului respectiv. În acest tip de evoluţie
200
tehnologică, schimbarea soluţiei la mijlocul drumului este

nerecomandată. De asemenea, un mod flexibil de a vedea
lucrurile ajută la crearea unui cadru mental pentru acceptarea
modificărilor, atât pentru management, cât şi pentru cei ce
implementează produsul.
Totuşi, pentru o abordare iterativă, este foarte important
să se definească un set de matrici de criterii de decizie. Un
exemplu de asemenea set poate fi un ghid (cu modele) care să
direcţioneze clasificarea unui obiect ca fiind mai potrivit pentru
modelare relaţională sau pentru modelare NoSQL, sau un ghid
de dimensionare a infrastructurii, o listă de cazuri de test
obligatorii etc.
La adoptarea în intreprinderi a bazelor de date NoSQL

cea mai mare provocare este schimbarea cadrului mental al
persoanelor de decizie – convingerea lor că nu toate datele /
obiectele se potrivesc cu modelarea relaţională. Cea mai bună
metodă pentru a realiza acest lucru este testarea unei soluţii
NoSQL pentru tipul potrivit de cazuri de utilizare, demonstrând
modul în care aplicaţiile bazate pe NoSQL pot fi soluţii mai
eficiente decât cele relaţionale, dacă sunt utilizate în contextul
potrivit. Ajută de asemenea identificarea câtorva proiecte (nu
neapărat critice pentru intreprindere, dar care au mai ales o
bună vizibilitate) pentru care implementări ne-relaţionale s-ar
potrivi. Succesul (sau chiar eşecul) unui astfel de proiect ajută
la schimbarea cadrului mental. Un astfel de proiect ar ajuta de
asemenea la învăţarea a ceea ce este necesar să fie făcut diferit
201
pentru a implementa mai bine soluţii NoSQL. Această politică

a paşilor mărunţi este vitală dacă intreprinderea vrea să îşi
remodeleze mecanismele de managementul informaţiei în
viitorul apropiat pentru adoptarea de soluţii ne-relaţionale.
Pe lângă regulile de bună practică formulate şi
informaţiile obţinute prin analize comparative, realizarea
acestui capitol a dus şi la selectarea produsului ţintă pentru
aplicația prezentată într-un capitol urmăror. Se poate observa
prin parcurgerea subcapitolelor precedente că produsul
MongoDB, pe lângă faptul că a fost selectat între cele patru
produse ce îndeplinesc condiţiile minimale pentru utilizarea
într-o intreprindere, îndeplineşte şi câteva condiţii
suplimentare. Din acest motiv, aplicaţia care este descrisă în
capitolul 0, dar şi cercetările care vor fi continuate ulterior au
ca ţintă produsul MongoDB, un produs open source realizat şi
suportat de 10gen.
202
4 Soluții de prelucrare a volumelor mari de date în

sistemele NoSQL
Capitolul de faţă analizează modul în care poate fi

construită o soluţie de prelucrare a volumelor mari de date de
diverse naturi, date structurate relaţional, date nestructurate dar
mai ales date semistructurate, acestea constituind de fapt
componenta cea mai semnificativă a volumelor mari de date,
aşa cum s-a văzut în subcapitolele anterioare.
De asemenea este prezentată o aplicaţie realizată de
autor pentru măsurarea performanţelor infrastructurii fizice
integrate într-o soluţie de prelucrare a volumelor mari de date.
4.1 Soluții de prelucrare a volumelor mari de date

organizate semistructurat. Soluţii hibride depozit
de date / bază de date NoSQL
Următoarea generaţie de soluţii de prelucrare a

volumelor mari de date, aşa cum s-a arătat şi în subcapitolul
2.2, este alcătuită din soluţii de prelucrare mixte, care sunt
capabile să preia datele din multiple surse, fie ele structurate,
semistructurate sau nestructurate.
Subcapitolul de faţă descrie o soluţie ideală care îmbină
elemente şi facilităţi deja prezente la cele câteva soluţii
integrate de prelucrare a datelor mixte existente în acest
moment, dar şi facilităţi inexistente la acest moment care sunt
esenţiale în opinia autorului pentru a asigura completitudinea
unei astfel de soluţii.
203
Figura 33 reprezintă structura generică a unei astfel de

soluţii de prelucrare, al cărei rol este să preia şi să integreze
toate sursele de date din întreprindere. Sunt incluse aici atât
sursele de date tradiţionale, cât şi noile surse de date discutate
în subcapitolul 1.2 şi denumite generic Big Data (The
Economist, 2010).
Ierarhia reprezentată în această figură conţine trei nivele
logice distincte: un nivel al surselor de date de diverse tipuri
(au fost incluse aici datele din sursele tradiţionale cum ar fi
aplicaţiile OLTP, OLAP precum şi aplicaţii mai vechi, dar şi
datele din surse noi cum ar fi datele semistructurate şi
nestructurate sau date produse de aplicaţii de generaţie Web 2.0
precum datele audio, video şi de geolocalizare), un nivel al
tehnologiilor folosite pentru organizarea (administrarea,
prelucrarea primară) acestor date incluzând aici sistemele de
gestiune de baze de date relaţionale şi nerelaţionale, dar şi
motoare de inferenţă şi prelucrări semantice şi în sfârşit nivelul
superior care face analiza acestor date.
204
Nivelul de
analiză
Analiză
Interfeţe
Nivelul semantice /
tehnologic (de Motoare de
reguli
gestiune)
SGBD
NoSQL
relaţional
Nivelul
Date audio Modele /
datelor / video / de date
localizare numerice
Date
Date
OLTP / semistructu
moştenite
Depozite de rate şi
din aplicaţii
date nestructura
mai vechi
te
Figura 33 – Structura generică a unei soluţii de prelucrare a volumelor

mari de date din generaţia următoare
4.1.1 Nivelul datelor şi nivelul de gestiune
Diversitatea surselor de date disponibile în epoca

actuală face ca primul nivel, cel al datelor sau surselor de date,
să fie un nivel de complexitate ridicată. În companiile de
dimensiuni mai mari şi cu un oarecare istoric sunt probabil
disponibile date din foarte multe sau chiar din toate
sortimentele descrise mai jos.
Date din sisteme şi aplicaţii vechi – uzual aceste date
sunt date structurate sau semistructurate. În această categorie
205
sunt uzual clasificate datele seismice, de climă, de la

recensăminte, date de planificare urbană, date socio-
economice, date furnizate de diverse sisteme industriale sau de
utilităţi.
Date tranzacţionale (date provenite din surse OLTP) –
în sistemele clasice de prelucrare a volumelor mari de date
(depozite de date) aplicaţiile tranzacţionale reprezintă sursa
principală de date. Din motive de scalabilitate şi de nivele de
semnificaţie luate în considerare la construirea depozitelor de
date, nu toate datele din aceste surse ajung să devină parte a
depozitelor de date. Mai precis, foarte multe date din surse
precum aplicaţiile ERP (Enterprise Resource Planning), SCM
(Supply Chain Management) sau CRM (Customer Relationship
Management) sunt eliminate în timpul procesării. Noile
platforme tehnologice discutate în capitolele anterioare oferă
acum capacitatea de a încărca şi analiza toate datele din astfel
de surse.
Date nestructurate – aplicaţiile sau platformele de
management al conţinutului care constituie generaţia de
aplicaţii Web 2.0 sunt uzual orientate fie către producerea şi
stocarea de conţinut, fie doar către stocarea de conţinut. Cea
mai mare parte a acestui conţinut nu este analizată şi la acest
moment, deşi există unele tehnologii de analiză disponibile
comercial (Cloudera Enterprise, Amazon Webservices, HP
Vertica Analytics Platform, HortonWorks Data Platform etc.),
nu există nicio tehnologie larg răspândită care să permită
analizarea acestui conţinut indiferent de sursa sa (Henschen,
2014). Conţinutul de orice natură este specific contextului în
care a fost creat şi entităţii care este originea sau proprietara
206
conţinutului respectiv. În opinia autorului, una dintre facilităţile

pe care ar trebui să le ofere soluţiile mixte de prelucrare a
volumelor mari de date ar fi navigarea prin acest conţinut pe
baza unor reguli de prelucrare definite de utilizator. Odată
stabilit un set optim de reguli de prelucrare, rezultatul
prelucrărilor efectuate va putea fi mai departe utilizat pentru
proiectarea unui sistem de analiză a conţinutului respectiv.
Respectivul rezultat al navigării / prelucrării poate fi integrat
prin tehnologii de prelucrare semantică şi poate fi utilizat
pentru vizualizări şi data mining vizual (Bucur & Tudorică, A
Research on Retrieving and Parsing of Multiple Web Pages for
Storing Them in Large Databases, 2012).
Conţinut video - acest tip de conţinut provine din foarte
multe surse (camere de supraveghere, aplicaţii Web 2.0,
aplicaţii ştiinţifice etc.) şi are de obicei trei componente
principale separate şi anume conţinutul propriu-zis, conţinutul
audio şi metadatele asociate. Tehnicile de procesare / analizare
pentru acest tip de conţinut sunt în acest moment într-un stadiu
incipient, nefiind încă disponibile aplicaţii comerciale capabile
de acest tip de prelucrări (Fang, 2013). Ţinând cont de
cantităţile foarte importante de date stocate în diverse formate
video, autorul consideră că integrarea unei facilităţi de
prelucrare a datelor video într-o soluţie de prelucrare a datelor
mixte este esenţială; opinii similare sunt exprimate şi de alţi
autori (Derrick, 2014) (Venter & Stein, 2012). Rezultatele unor
astfel de prelucrări au multiple aplicaţii previzibile, precum
adoptarea unor strategii de gamificare (eng. gamification –
utilizarea mecanicilor de joc în afara jocurilor, în probleme
economice sau de alte tipuri) în capturarea şi retenţia clienţilor,
207
implementarea unor noi măsuri de protecţie şi securitate de

către agenţiile guvernamentale, noi metode de analiză şi
previziune a climei sau clasificarea şi caracterizarea automată a
conţinutului video cu aplicaţii educaţionale şi de alte tipuri.
Date audio – acest tip de date provine uzual din
aplicaţii Web 2.0 şi din call center-e. În cel de-al doilea caz,
secvenţele audio respective conţin informaţii referitoare la
clienţi, competiţie şi alte subiecte extrem de importante pentru
organizaţii (Lane, 2014). Depozitele de date clasice nu conţin
de obieci acest tip de date, tehnologii capabile de stocare şi
prelucrare a unor volume corespunzătoare de date de acest tip
devenind disponibile doar în ultimii 5 ani (Bertolucci, 2014).
Într-o soluţie mixtă de prelucrare a volumelor mari de date,
secvenţele audio pot fi procesate şi stocate ca date contextuale
cu metadate asociate.
Imagini – imaginile statice sunt şi ele purtătoare ale
unui volum mare de date. Prelucrarea şi analiza datelor de acest
tip are aplicaţii diverse precum integrarea geospaţială sau
serviciile medicale. Ca şi prelucrarea datelor video, prelucrarea
imaginilor (în sensul analizei conţinutului lor) poate fi o sursă
de beneficii pentru intreprinderile mari prin dezvăluirea unor
perspective necunoscute până atunci şi prin crearea de noi
oportunităţi de afacere.
Date numerice, modele, grafuri, date de geolocalizare –
includ date seismice, date provenite de la senzori meteo şi de
alte tipuri, date climatice, date de bursă, date ştiinţifice, date
provenite de la sisteme RFID (Radio Frequency Identification),
date provenite de la sistemele de telecomunicaţii celulare, date
produse de calculatoarele de bord ale diverselor vehicule şi
208
orice alte date care reprezintă modele, date numerice,

manifestări ciclice sau grafuri. Prelucrarea unor astfel de date
în cadrul sistemului mixt de prelucrare a volumelor mari de
date va furniza posibilitatea de a face analize de corelare,
analize cluster sau analize Bayesiene, permiţând identificarea
unor tendinţe în evoluţia veniturilor, comportamentul clienţilor
sau dezvăluirea unor factori de risc ascunşi, permiţând astfel
optimizarea deciziilor managementului.
Date provenite din aplicaţiile de socializare – provin în
mod tipic din surse precum Facebook, LinkedIn sau Twitter dar
pot fi de asemenea şi achiziţionate de la agregatori de date de
terţă parte precum Datasift, Gnip, NTT Data sau Nielsen
(Wagner, 2014). Procesarea acestor date poate fi realizată cu
ajutorul motoarelor de inferenţă şi a tehnologiilor semantice,
iar rezultatele sunt uşor integrabile chiar şi în spaţiul
dimensional al unui depozit de date clasic.
Din cele de mai sus se observă că doar o mică parte
(aproximativ 20% sau mai puţin) dintre aceste date sunt date
care ar fi fost prelucrabile şi cu ajutorul tehnologiilor
caracteristice pentru un depozit de date. Pentru celelalte date
trebuie integraţi algoritmi noi în structura soluţiei de
prelucrare a volumelor mari de date mixte.
Algoritmi
Pentru prelucrarea datelor denumite generic Big Data

(ultimele şase categorii din cele enunţate mai sus, dar şi alte
tipuri de date mai puţin importante) poate fi aplicată schema
generică de prelucrare din Figura 34.
209
Descoperi Preproce- Integra- Vizualiza-

Achiziţia Analiza
-rea sarea rea rea
datelor datelor
datelor datelor datelor datelor
Figura 34 – Succesiunea etapelor de prelucrare a datelor de tip Big

Data
După achiziţia datelor din diversele surse precizate mai

sus, prima prelucrare necesară este descoperirea datelor în
sensul reducerii complexităţii datelor până la obţinerea unui
nivel acceptabil de semnificaţie – primele două prelucrări din
Figura 34 aparţin logic de nivelul datelor iar prelucrările
următoare pot fi caracterizate ca aparţinând nivelulului
tehnologic şi respectiv nivelului de analiză din Figura 33.
Pentru acest gen de prelucrări de descoperire a datelor există
diverse categorii de metode / algoritmi utili descrişi în
continuare:
Text mining – metodele de text mining sunt disponibile
în diverse forme, atât comerciale cât şi open source, care
permit integrarea lor cu uşurinţă în arhitectura soluţiei de
prelucrare a datelor mixte (Predictive Analytics Today, 2014).
Metodele de acest tip sunt centrate pe prelucrarea datelor de tip
text pentru extragerea din acestea a unor date ce pot fi utilizate
în continuare pentru clasificarea textelor sursă în scopul
explorării datelor iniţiale. Tehnologiile care stau la baza acestor
metode sunt tehnologii semantice.
Data mining – reprezintă o categorie de metode studiate
şi utilizate de suficient de mult timp pentru a atinge maturitatea
tehnologică. Sunt disponibile implementări comerciale precum
cele de la SAS şi IBM, dar şi soluţii open source precum
Mahout (Nettleton, 2014) (VagueWare, 2014). Metodele de
210
acest tip au ca scop extragerea unora dintre datele sursă pe baza

unor modele statistice de grupare a populaţiilor sau a datelor în
clustere sau a unor modele de segmentare bazate pe dimensiuni
spaţiale sau temporale (numite tehnici de microsegmentare).
Rezultatul este perfect adaptat pentru operaţii de explorare a
datelor, fiind folosit în acest scop în soluţiile OLAP clasice.
Procesarea modelelor (pattern processing) – algoritmii
de acest tip sunt dezvoltaţi pentru evidenţierea modelelor din
diverse date precum datele privind utilizarea cardurilor
bancare, creditele bancare, plăţile la POS, utilizarea ATM-
urilor, datele de bursă, datele provenite de la senzorii din
clădiri, sisteme de utilităţi şi vehicule de diverse tipuri, datele
de urmărire prin satelit, imagini şi date audio, date
criptografice şi limbaje simbolice. Atunci când este identificat
un model, datele sunt procesate tranzacţional pentru fiecare
instanţă în care este identificat modelul respectiv. Deşi
algoritmii de procesare a modelelor necesită capacităţi de
stocare şi de calcul suplimentare, noile platforme tehnologice
discutate în subcapitolul 2.1 oferă performanţe suficiente
pentru acest lucru. Avantajul integrării acestor metode în
soluţia de prelucrare a datelor mixte este abilitatea de a folosi şi
datele care nu urmează o evoluţie ciclică sau nu se
conformează unui model statistic, crescând nivelul de detaliu şi
acoperirea modelelor predictive generate (Krishnan, 2013).
Modele statistice – metodele de acest tip sunt utilizate
intens în serviciile financiare şi medicale pentru administrarea
segmentelor de populaţie ţintă. Fiecare organizaţie foloseşte
variaţiuni adaptate pentru uz propriu a unor metode statistice
clasice, iar datele rezultate nu sunt de obicei reintegrate în alte
211
aplicaţii din motive legate de dimensiunea datelor şi de

complexitatea prelucrărilor necesare. Ţinând cont de creşterea
performanţelor oferite de infrastructura disponibilă, datele
statistice produse prin analizarea datelor structurate,
semistructurate sau nestructurate pot fi incluse în arhitectura
soluţiei de prelucrare a datelor mixte. Pentru astfel de integrări
se recomandă mai degrabă utilizarea unor soluţii open source
precum cele disponibile în pachetele R, PSPP, GNU Octave
etc. (Predictive Analytics Today, 2014) decât a unor soluţii
comerciale, din motive de adaptabilitate la cerinţele
organizaţiei.
Modele matematice – modelele de acest tip sunt
utilizate uzual în aplicaţii precum simularea şi predicţia
evoluţiei epidemiilor, predicţia vremii, analiza fraudelor şi
analiza altor tipuri de date care nu se pretează la analiză
statistică. Tehnologiile disponibile în acest moment sunt încă
insuficiente pentru integrarea tuturor metodelor de acest tip în
structura unei soluţii de prelucrarea a datelor mixte, dar este
totuşi posibilă integrarea unora dintre aceste modele. Autorul
consideră că apariţia unor noi tipuri de echipamente, precum
calculatoare cuantice, va duce la posibilitatea integrării unui
număr mai mare de prelucrări de tip model matematic fără a se
ajunge totuşi la o integrare completă. Această consideraţie este
sprijinită de studiile recente făcute în domeniul calculatoarelor
cuantice, studii care limitează aplicabilitatea acestui tip de
sisteme de calcul chiar în cazul în care ele vor înregistra
performanţe superioare calculatoarelor clasice într-un orizont
previzibil de timp (Brandom, 2014).
212
Precum s-a arătat mai sus, este necesară integrarea în

soluţiile de prelucrare a datelor mixte a unor metode şi
tehnologii neutilizate de către soluţiile clasice de depozite de
date. Necesitatea este dată de prezenţa unor tipuri de date fie
noi, fie neintegrate până acum în depozitele de date din motive
de performanţă şi scalabilitate.
Strategii de integrare
Conceptul de integrare a datelor se referă la combinarea

datelor din diferite surse pentru utilizarea, de către o entitate, în
scopul studierii comportamentului organizaţiilor şi clienţilor
lor.
La soluţiile clasice de depozite de date, conceptul de
integrare a datelor se referea în cele mai multe cazuri doar la
datele provenite din surse tranzacţionale şi din aplicaţiile
asociate. Potrivit cu natura acestor date, tehnicile tradiţionale
de integrare erau ţintite pe deservirea unor arhitecturi de tip
ETL, ELT, CDC sau EAI (Enterprise Application Integration)
şi a modelelor asociate de programare (a se vedea şi
subcapitolul 2.2).
Odată cu adăugarea surselor de date de tip Big Data,
aceste tehnici de integrare trebuie adaptate pentru a se potrivi
cu volumele crescute de date, creşterea complexităţii
prelucrărilor şi introducerea de noi formate de date. O metodă
de adaptare este fragmentarea procesului de integrare în doi
paşi autonomi şi anume integrarea orientată pe date şi respectiv
integrarea componentelor fizice.
213
Integrarea orientată pe date
În acest pas toate datele din întreprindere sunt

categorizate după tipul de date şi în funcţie de natura acestor
date, li se asociază cerinţele de procesare corespunzătoare,
urmând ca procesarea datelor să fie dusă la bun sfârşit prin
utilizarea regulilor de afacere încapsulate în logica de procesare
şi integrate într-o serie de secvenţe de prelucrare care se vor
baza de asemenea pe metadatele de întreprindere, MDM
(Master Data Management – managementul centralizat al
datelor) şi diverse tehnologii semantice precum taxonomiile
sau ontologiile.
Figura 35 prezintă modul în care sunt prelucrate diferite
categorii de date. Acest model separă fiecare tip de date pe
baza formatului şi structurii datelor, urmând ca diverse nivele
de reguli de procesare din tehnicile de procesare ETL, ELT,
CDC sau de text să fie aplicate selectiv, corespunzător tipului
de date respectiv.
Figura 35 – Procesarea datelor de intrare

214
Clasificarea datelor
Precum se poate vedea în Figura 35 pot fi deosebite

şase categorii de date:
 Date tranzacţionale – datele aparţinând de aplicaţiile
OLTP;
 Date din aplicaţiile web – categoria conţine datele
aparţinând de aplicaţiile web ale organizaţiei (date
de trafic, data provenite din comerţul electronic,
date legate de relaţiile cu clienţii şi date generate de
centrul de suport);
 Date din depozitul de date – datele cuprinse în
depozitul / depozitele de date ale organizaţiei,
precum şi în orice aglomerări de date pe care
organizaţia le foloseşte;
 Date analitice – sunt datele cuprinse / generate de
sistemele analitice implementate în organizaţie;
 Date nestructurate – date de tip text, imagine, video,
media socială, audio, date generate de senzori, date
despre stare vremii, date ştiinţifice, date de bursă
etc.;
 Date semi-structurate – mesagerie electronică,
prezentări, modele şi diagrame matematice, precum
şi date geospaţiale.
Arhitectura
Odată identificate şi separate tipurile de date, anumite

caracteristici ale datelor, incluzând tipuri de date, metadate
215
asociate, elemente cheie ale datelor, pot fi identificate ca

elemente primare ale datelor. După identificarea elementelor
primare se poate evalua complexitatea datelor şi pot fi
identificaţi clar proprietarii şi administratorii datelor (utilizatori
sau compartimente din organizaţie). Toate aceste elemente vor
constitui arhitectura datelor (din punct de vedere al integrării
orientate pe obiecte).
Sarcinile de lucru
Unul dintre cele mai importante aspecte la prelucrarea

volumelor mari de date este managementul sarcinilor de lucru.
Clasificarea datelor şi stabilirea arhitecturii lor (prezentate mai
sus) permit stabilirea unei infrastructuri corespunzătoare pentru
cerinţele prelucrărilor diferitelor categorii de date.
Din acest punct de vedere, sarcinile de lucru pot fi
clasificate în patru categorii în funcţiile de volumele de date
implicate şi latenţele de prelucrare acceptabile. Cele patru
categorii sunt reprezentate în Figura 36. Fiecare dintre cele
patru tipuri de sarcini de lucru va avea asociată o anumită
infrastructură fizică pentru prelucrarea datelor. Acest mod de
lucru oferă baza pentru obţinerea scalabilităţii aplicaţiei de
prelucrare a volumelor mari de date. Pentru a nu duce totuşi la
obţinerea unei aplicaţii rigide, neadaptabile, trebuie avut în
vedere ca implementarea logicii de procesare să fie suficient de
flexibilă pentru a putea fi utilizată în diverse puncte ale
infrastructurii fizice (aceleaşi date ar putea fi clasificate, din
punct de vedere al prelucrării, la momente diferite, în categorii
diferite de sarcini de lucru, în funcţie de latenţa acceptabilă –
urgenţa procesării).
216
Figura 36 – Categorii de sarcini de lucru
Ulterior, arhitectura aplicaţiei de prelucrare a volumelor

mari de date proiectate pe baza categoriilor de sarcini de lucru
va permite prelucrări mixte de date (date pentru o anumită
categorie de sarcini de lucru vor putea fi prelucrate simultan cu
date pentru o altă categorie). Spre exemplu, este posibilă
execuţia simultană a unor sarcini de lucru de volum mare de
date şi latenţă redusă cu sarcini de lucru cu volum de date redus
şi latenţă ridicată, optimizând astfel utilizarea sistemului.
Ca dezavantaj, complexitatea unui sistem capabil să
execute simultan mai multe sarcini de lucru, care vor prelucra
probabil tipuri diferite de date, este destul de mare.
Spre deosebire de depozitele de date tradiţionale
caracterizate de faptul că majoritatea datelor sunt încărcate în
sistem la început, înainte ca sistemul să fie propriu-zis
exploatat, sistemele bazate pe volume mari de date
semistructurate sunt caracterizate de admisia continuă de date
în sistem. Această caracteristică măreşte complexitatea
amintită mai devreme - este posibil ca interogările cerute de
217
utilizator să apară chiar în timpul încărcării datelor sau la

intervale scurte de timp după ce s-a făcut încărcarea datelor.
La acest nivel de complexitate, este posibil ca
performanţa sistemului să fie mult redusă în diverse cazuri
particulare de utilizare. Scopul clasificării sarcinilor de lucru în
categoriile prezentate mai sus este evaluarea complexităţii
prelucrării datelor şi găsirea unor metode de a proiecta
infrastructura fizică de aşa natură încât performanţa sistemului
să fie cât mai mare.
Integrarea componentelor fizice

Aplicaţiile bazate pe volume mari de date
semistructurate sunt construite uzual pe baza unor infrastructuri
eterogene şi a unor arhitecturi de date care includ atât date
structurate, cât şi date semistructurate sau nestructurate, de aşa
natură încât să se obţină sisteme scalabile şi performante.
Partea de arhitectură de date şi modul de integrare a diferitelor
tipuri de date a fost discutată în subcapitolul anterior. În ceea
ce priveşte infrastructura fizică, sunt posibile mai multe
modalităţi de implementare, fiecare cu avantaje şi dezavantaje,
modalităţi care vor fi discutate în acest subcapitol.
Principalele probleme care trebuie rezolvate pentru a
obţine arhitectura fizică a unei aplicaţii de prelucrare a
volumelor mari de date organizate semistructurat sunt
încărcarea datelor, disponibilitatea, volumele mari de date,
performanţa soluţiilor de stocare, scalabilitatea, variabilitatea şi
fluiditatea cererilor de interogare precum şi costurile
operaţionale de întreţinere. Înainte de a discuta modalităţile
propriu-zise de implementare a arhitecturii fizice vor fi
218
prezentate câteva dintre aceste probleme, urmând ca la

detalierea modalităţilor de implementare să fie discutate
detaliile specifice ale implementării legate de aceste probleme.
Probleme de rezolvat
Încărcarea datelor
Dat fiind că nu există un format stabil, sau metadate

consistente peste toate datele sau o schemă, procesul de
încărcare a datelor pentru datele organizate semistructurat
constă doar în achiziţia datelor şi stocarea lor ca fişiere. Chiar
şi această sarcină aparent simplă poate depăşi capacitatea unui
sistem de a achiziţiona datele în timp real simultan cu
procesarea lor, fie în totalitate, fie în sarcini de mici dimensiuni
de procesare pe loturi. O soluţie la cheie (soluţiile la cheie au
fost descrise în subcapitolul 2.2.3) poate fi configurată şi
optimizată pentru a acoperi aceste cerinţe mai uşor decât
implementarea unui sistem de la zero. La nevoie se poate
recurge la utilizarea unei arhitecturi customizate.
Procesarea continuă a datelor poate duce la blocarea
resurselor platformei pe o perioadă mare de timp. Acest lucru
se poate petrece în special în cazul documentelor, imaginilor
sau secvenţelor video de mari dimensiuni. Dacă respectivele
tipuri de date sunt importante pentru aplicaţie, se poate recurge
de asemenea la o soluţie la cheie, un astfel de sistem permiţând
optimizarea pentru anumite tipuri de date în cadrul configurării
iniţiale.
Configurarea şi optimizarea operaţiilor de tip
MapReduce poate fi o operaţie foarte dificilă pentru sisteme de
219
mari dimensiuni şi acest factor favorizează de asemenea

utilizarea soluţiilor la cheie în defavoarea implementărilor de la
zero (soluţiile la cheie oferă configuraţii de referinţă care evită
unele dintre probleme care pot apărea la configurare).
Disponibilitatea datelor
Disponibilitatea datelor este o problemă pentru orice fel

de sistem care realizează prelucrări sau / şi transformări ale
datelor. Beneficiul nativ al sistemelor de tip NoSQL este faptul
că disponibilitatea este garantată chiar de către arhitectură, iar
datele sunt disponibile imediat după achiziţie. Singura
provocare rămâne încărcarea suficient de rapidă a datelor, de
aşa natură încât ele să devină disponibile. Mai precis, realizarea
disponibilităţii datelor va depinde de specificul metadatelor.
Dacă datele pot fi clasificate imediat după achiziţie, ele vor
deveni rapid disponibile pentru analiză şi descoperire.
Este important de remarcat şi faptul că reachiziţia şi
reprocesarea unor date deja achiziţionate după ce acestea au
suferit modificări nu va afecta datele deja achiziţionate, astfel
fiind posibil să rezulte date duplicate, iar acest lucru trebuie
adresat pentru a minimiza impactul asupra disponibilităţii.
Volume mari de date
Lucrul cu volume mari de date este problematic prin

însăşi natura acestor date. Pentru a preîntâmpina apariţia de
situaţii limită, la fiecare ciclu de achiziţie creşterea datelor va
trebui supravegheată.
220
Cerinţele de retenţie pentru date sunt dependente de

natura datelor, vechimea lor şi importanţa lor pentru
organizaţie, aşa cum este descris în continuare:
Cerinţele regulatorii: cerinţele standardelor SAFE
Harbor, SOX, HIPAA, GLBA şi PCI afectează modul în care
sunt stocate şi securizate datele. Dacă organizaţia trebuie să
adere la aceste standarde, aplicaţiile trebuie implementate în
consecinţă.
Cerinţe legale: există şi date tranzacţionale care nu au
fost stocate online în aplicaţiile tradiţionale, dar pot fi solicitate
în cadrul unor dispute legale comerciale sau penale (cum au
fost spre exemplu datele solicitate în Legea nr. 82/2012 privind
reținerea datelor de trafic). Infrastructurile care lucrează cu
volume mari de date pot fi utilizate şi în acest scop, cu
respectarea anumitor cerinţe regulatorii şi de securitate. Aceste
volume suplimentare de date pot avea impact asupra
performanţei globale şi dacă asemenea date sunt prelucrate în
aplicaţia de prelucrare a volumelor mari de date
semistructurate, configuraţia aplicaţiei ar trebui să furnizeze
administratorilor unelte şi metode de zonare a infrastructurii în
scopul izolării acestor date, minimizând astfel riscurile de
securitate şi impactul asupra performanţei.
Explorarea datelor şi data mining-ul sunt activităţi care
se bazează pe volume mari de date şi de asemenea generează
volume mari de date. Acest lucru impulsionează achiziţia de
volume mari de date din interiorul şi din exteriorul
organizaţiilor. Datele rezultate trebuie întreţinute în sistem prin
analizarea şi ştergerea periodică a seturilor de date
intermediare. Chiar şi în condiţiile unei bune întreţineri, se vor
221
acumula şi vor persista în sistem volume de date care sunt de

obicei ignorate în estimările efectuate la proiectarea unui
sistem de prelucrare a volumelor mari de date, iar aceste
volume de date ignorate vor reduce performanţa globală a
sistemului.
Performanţa soluţiilor de stocare
Performanţa soluţiilor de stocare este o consideraţie

importantă la construcţia sistemelor de prelucrare a volumelor
mari de date. Soluţiile la cheie prezintă un avantaj şi din acest
punct de vedere, permiţând o focalizare mai bună asupra logicii
de stocare a compartimentării pe nivele a arhitecturii, stocarea
fizică propriu-zisă fiind deja asigurată. De asemenea, soluţiile
la cheie permit planificarea pe termen lung şi managementul
creşterii infrastructurii de stocare.
Daca sistemul de prelucrare este bazat pe o combinaţie
de tehnologii de stocare tradiţionale, SSD şi în memoria RAM,
transferul datelor între componentele de stocare de diferite
tehnologii şi respectiv asigurarea persistenţei datelor vor
consuma suplimentar resurse de calcul. Din nou soluţiile la
cheie uşurează implementarea, furnizând soluţii de referinţă
pentru cerinţe complexe de stocare.
Costuri operaţionale
Calcularea costurilor operaţionale pentru o aplicaţie de

prelucrare a volumelor mari de date organizate semistructurat
este o sarcină complexă. Trebuie luate în considerare costurile
iniţiale de achiziţie a infrastructurii, costurile manoperei pentru
222
implementare, costurile utilităţilor, costurile întreţinerii şi

manoperei pentru întreţinere, costurile modificărilor aduse
ulterior şi ale manoperei pentru acestea, costurile consultanţei
şi expertizei externe, plus costurile de instruire a personalului
propriu.
Modalităţi propriu-zise de implementare

Integrarea externă a datelor
Figura 37 reprezintă modalitatea de integrare a

componentelor fizice, denumită Integrare externă a datelor. La
această modalitate, capacitățile existente de prelucrare a datelor
şi respectiv depozitele de date existente sunt menţinute (nivelul
de sus din figură) iar noua platformă pentru prelucrarea
volumelor mari de date semistructurate este creată pe o
arhitectură tehnologică nouă (nivelul de jos din figură). O
magistrală de date (BUS) este dezvoltată utilizând metadate şi
tehnologii semantice (a se vedea şi subcapitolul 4.1.2), iar
această magistrală va crea mediul de integrare a datelor necesar
pentru explorarea şi prelucrarea datelor.
Execuţia sarcinilor de lucru este clar divizată în această
arhitectură (datele semistructurate sunt prelucrate în noua
structură de prelucrare, iar datele relaţionale tradiţionale în
vechile structuri pre-existente). Această diviziune ajută la
menţinerea performanţei şi a calităţii datelor, dar în schimb
creşte complexitatea la nivelul magistralei de date. Această
modalitate de integrare necesită soluţii de integrare separate
pentru fiecare sistem care va fi integrat şi necesită cunoştinţe
arhitecturale şi de întreținere avansate.
223
Figura 37 – Integrarea datelor externe
Prelucrarea datelor semistructurate se va face în afara

soluţiilor relaţionale existente, iar acest lucru creează
oportunităţi pentru crearea unei scalabilităţi teoretic nelimitate,
în condiţiile unor costuri mai scăzute.
Avantajele oferite de această modalitate de integrare
sunt:
 scalabilitate atât pentru componenta relaţională, cât
şi pentru cea NoSQL;
 consum redus de resurse de calcul pentru prelucrare;
 complexitatea prelucrării poate fi fragmentată peste
achiziția datelor, curăţarea datelor, descoperirea
datelor şi integrarea datelor;
 arhitectura de integrare este modulară;
 implementare eterogenă a arhitecturii fizice,
permiţând obţinerea unei performanţe ridicate a
integrării elementelor de prelucrare.
Dezavantajele generate de această modalitate de
integrare sunt:
224
 arhitectura magistralei de date poate deveni din ce

în ce mai complexă;
 o slabă arhitectură a metadatelor poate deveni
inconsistentă datorită existenţei mai multor nivele
de procesare a datelor;
 elementul de integrare a datelor poate deveni un
punct îngust pe măsură ce volumele de date cresc.
Cazurile tipice de utilizare pentru această modalitate de
integrare se regăsesc în organizaţiile în care natura datelor este
relativ stabilă în timpul ciclului de viaţă al sistemului de
prelucrare a volumelor mari de date. Exemple tipice sunt
sistemele de media social sau sistemele de prelucrare a datelor
de la senzori.
Pentru această modalitate de implementare, principalele
probleme de rezolvat sunt tratate după cum urmează:
 Încărcarea datelor este izolată în punctele
corespunzătoare din nivelele relaţional şi respectiv
din cele NoSQL. Acest lucru pune bazele pentru
crearea unei strategii de management robuste.
 Disponibilitatea datelor este controlată în fiecare
dintre nivele şi pot fi implementate reguli de
securitate în fiecare nivel, după necesităţi, evitând
supraîncărcarea altor nivele.
 Volumele mari de date sunt administrate în fiecare
dintre nivele, tratarea depinzând de tipul de date,
cerinţele de ciclu de viaţă al datelor şi de costul
stocării.
 Performanţa soluţiilor de stocare – în funcţie de
categoriile de date şi de cerinţele de performanţă,
225
pot fi utilizate în diverse puncte sisteme de stocare

de diverse performanţe (se pot chiar utiliza ierarhii
de sisteme de stocare de performanţe crescătoare).
 Costuri operaţionale vor consta din costuri fixe
(costuri de întreţinere şi costuri legate de date) şi
costuri variabile (costuri de prelucrare şi de
infrastructură de prelucrare şi manopera de diverse
tipuri).
Posibile erori de implementare care trebuie evitate:
 Complexitate prea mare a datelor la oricare dintre
nivelele de prelucrare;
 Metadate slab proiectate;
 Analiză incorectă a datelor în nivelele NoSQL;
 Nivele incorecte de integrare / granularitate
incorectă a datelor în nivelele NoSQL;
 Realizarea incorectă a integrării la nivelul
magistralei de date.
NoSQL & SGBD relaţionale integrate
Figura 38 înfăţişează modalitatea de construcţie a unei

soluţii de prelucrarea a volumelor mari de date organizate
semistructurat bazată pe integrarea bazelor de date NoSQL cu
cele relaţionale. Integrarea se face prin implementarea unui
conector între cele două soluţii pre-existente. Acest conector va
deveni mediul prin care se face interschimbarea datelor.
Construcţia conectorului în sine este sprijinită de faptul că toate
soluţiile relaţionale şi multe dintre soluţiile nerelaţionale
prezintă din concepţie multiple modalităţi de conectare cu
exteriorul (conectori ODBC, JDBC, conectori proprietari etc.).
226
Figura 38 – Abordare bazată pe integrarea bazelor de date NoSQL şi a

celor relaţionale
Execuţia sarcinilor de lucru în această arhitectură

îmbină operaţiile de procesare a datelor din cele două
arhitecturi încorporate, furnizând scalabilitate şi reducând
complexitatea. Ulterior, descoperirea datelor poate fi făcută pe
oricare dintre cele două platforme, sau pe ansamblul alcătuit
din ele. Complexitatea acestei arhitecturi este dependentă de
performanța conectorului. Conectorul în sine se comportă
asemănător cu un conector JDBC, iar lățimea de bandă oferită
de infrastructura fizică va fi un punct îngust sever, luând în
considerare complexitatea interogărilor care constituie
operaţiile obişnuite de descoperire a datelor.
sunt:
 scalabilitate atât pentru componenta relaţională cât
şi pentru cea NoSQL;
 arhitectura de integrare este modulară;
227

integrării elementelor de prelucrare;
 metadatele şi soluţiile MDM pot fi construite relativ
simplu peste această soluţie.
integrare sunt:
 performanţa conectorului este cel mai important
punct slab al soluţiei;
 integrarea datelor şi scalabilitate interogărilor sunt
complex de realizat şi pot deveni greu de obținut.
Cazuri tipice de utilizare pentru această modalitate de
integrare pot fi întâlnite în organizaţiile în care se face intensiv
analiză a datelor şi raportare. Exemple obişnuite includ analiza
datelor din media social, date de tip text şi date semistructurate
precum poşta electronică.
 Încărcarea datelor este izolată în nivelele
corespunzătoare. Acest lucru pune bazele pentru
nivel, iar regulile de securitate pot fi implementate
în fiecare nivel după necesităţi, evitând încărcarea
inutilă a altor nivele.
 Volumele mari de date pot fi administrate în fiecare
din nivele, depinzând de tipul de date, cerinţele de
ciclu de viaţă al datelor şi de costul stocării.
228
 Performanţa soluţiilor de stocare este asigurată

separat (soluţiile NoSQL oferă o performanţă de
stocare bună chiar pe sisteme de calcul obişnuite).
Performanţa stocării pentru fiecare nivel în parte
poate fi configurată după necesităţile utilizatorilor.
 Costurile operaţionale constau în costuri fixe şi
costuri variabile. Costurile fixe sunt date de
întreţinerea infrastructurii relaţionale şi de alte
costuri asociate acesteia. Costurile variabile sunt
date de costurile de prelucrare şi infrastructură de
prelucrare, precum şi de costurile de manoperă.
 Complexitate prea mare în oricare dintre nivele;
 Interschimbarea unor volume de date prea mari între
oricare două nivele;
 Nivel incorect de integrare sau granularitate
incorectă a datelor;
 Utilizarea conectorului pentru execuţia unui volum
prea mare de transformări de complexitate.
Soluţii hibride la cheie
Soluţiile la cheie pentru depozite de date (descrise în

subcapitolul 2.2.3) s-au impus pe piaţă ca şi arhitecturi
puternice şi relativ uşor de utilizat pentru execuţia unor sarcini
de lucru de mari dimensiuni. O extensie recentă a acestor
arhitecturi este apariţia la toţi marii producători a unor soluţii la
cheie pentru prelucrarea volumelor mari de date
semistructurate. Aceste soluţii sunt proiectate, realizate şi
configurate de aşa natură încât să facă faţă atât rigorilor
229
prelucrării datelor structurate relaţional, cât şi complexităţii şi

volumelor mari care caracterizează datele semistructurate sau
nestructurate.
Figura 39 descrie arhitectura conceptuală a unei soluţii
la cheie pentru prelucrarea volumelor mari de date organizate
semistructurat. Este adevărat că producătorii acestor soluţii
(precum Teradata, Oracle, IBM şi Microsoft) nu furnizează
produse absolut similare, dar conceptele arhitecturale folosite
sunt aceleaşi – tehnologiile NoSQL sunt utilizate pentru
achiziţia, preprocesarea şi stocarea volumelor mari de date, iar
nivelele relaţionale sunt utilizate pentru prelucrarea ieşirilor de
date din nivelele NoSQL. Mecanisme precum MapReduce, R şi
convertori specifici mediilor relaţionale vor fi utilizate în
arhitectura integrată pentru administrarea transportului şi
transformării datelor în soluţia la cheie.
Figura 39 – Schema conceptuală a unei soluţii hibride la cheie
Soluţiile hibride la cheie sunt ţintite tocmai pe

rezolvarea acelor probleme de rezolvat descrise în subcapitolul
anterior (încărcarea datelor, disponibilitatea lor, performanţa
soluţiilor de stocare, scalabilitatea, diversitatea şi fluiditatea în
230
timp a cererilor de interogări, precum şi costurile operaţionale).

Aceste probleme afectează atât datele organizate structurat cât
şi pe cele organizate semistructurat sau nestructurat, fiind
generate nu atât de natura sau formatul datelor respective, cât
de volumul şi complexitatea lor.
în fiecare nivel după necesităţi, evitând încărcare
 Performanţa soluţiilor de stocare – cerinţele sunt
date de categoria datelor şi prioritatea lor. Pot fi
definite ierarhii de stocare cu performanţe
crescătoare.
 Costurile operaţionale sunt în special uşor de
calculat la această modalitate de integrare – se
cunosc de la bun început nivelele de cerinţe /
performanţe care pot fi acoperite de o unitate de
acest tip (sunt documentate în specificaţiile
soluţiilor la cheie) precum şi costul unei astfel de
unităţi.
231
Execuţia tuturor tipurilor de sarcini de lucru în această

arhitectură este configurată în conformitate cu cerinţele
utilizatorilor, incluzând aici achiziţia datelor, utilizarea datelor,
retenţia datelor şi prelucrarea lor. Elementul de complexitate
maximă al utilizării unei astfel de arhitecturi este operaţia
iniţială de configurare. În cazul în care specificaţiile iniţiale nu
au fost clare sau tind să se schimbe în timp, cantităţi
semnificative de timp şi manoperă vor trebuie consumate
pentru reconfigurarea soluţiei la cheie.
sunt:
 scalabilitate oferită din proiectare şi arhitectură
modulară de integrare a datelor;
integrării elementelor de prelucrare;
 soluţia poate fi configurată în conformitate cu
cerinţele fiecărei organizaţii.
integrare sunt:
 cel mai important punct slab este relativa rigiditate a
configurării;
 integrarea datelor şi scalabilitatea interogărilor pot
deveni dificil de asigurat dacă se schimbă
configuraţia datorită schimbării în timp a
specificaţiilor.
Soluţiile hibride la cheie pot fi utilizate pentru toate
tipurile de aplicaţii de prelucrare a volumelor mari de date
organizate semistructurat şi constituie probabil arhitectura cu
232
cele mai mari şanse de a se impune în viitorul apropiat pentru

astfel de aplicaţii.
 Configuraţiile prea diferite de configuraţiile de
referinţă ale produsului pot necesita întreţinere
extensivă.
 Transferarea unor volume mari de date între
diferitele nivele ale arhitecturii poate afecta negativ
performanţa.
 O dependenţă prea mare de oricare dintre nivelele
de transformare poate crea puncte înguste din punct
de vedere al scalabilităţii.
 Securitatea datelor nu ar trebui implementată cu
LDAP (Lightweight Directory Access Protocol)
pentru nivelele nestructurate.
Virtualizarea datelor
Tehnologiile de virtualizare a datelor (a se vedea

subcapitolul 2.1.2) pot fi utilizate pentru a implementa o
arhitectură integrată de prelucrare a volumelor mari de date
organizate semistructurat sau nestructurat. Precum se poate
vedea în Figura 40, cel mai mare avantaj al acestei modalităţi
de integrare este reutilizarea integrală a infrastructurii
relaţionale existente. Un alt avantaj este oportunitatea de a
distribui sarcinile de lucru peste platformă, permiţând o bună
optimizare a utilizării diverselor arhitecturi. Virtualizarea
datelor, îmbinată cu o arhitectură semantică puternică poate
crea o soluţie scalabilă.
233

sunt:
 arhitectura este extrem de scalabilă şi flexibilă;
 sarcinile de lucru sunt optimizate;
 întreţinerea este facilă;
 costuri iniţiale scăzute ale implementării.
integrare sunt:
 un nivel scăzut de guvernanţă poate duce la apariţia
unui număr mare de conglomerate locale de date,
simultan cu degradarea performanţei;
 execuţia constantă a unor interogări complexe poate
duce la degradarea în timp a performanţei;
 menţinerea performanţei la nivelul de integrare
poate necesita întreţinere periodică.
Figura 40 – Integrarea datelor hibride bazată pe virtualizarea

datelor

234

în fiecare nivel după necesităţi, evitând încărcare
 Performanţa soluţiilor de stocare – cerinţele sunt
date de categoria datelor şi de prioritatea lor. Pot fi
definite ierarhii de stocare cu performanţe
crescătoare.
 Costurile operaţionale pentru această arhitectură
sunt alcătuite din costuri fixe şi costuri variabile.
Costurile fixe sunt date de întreţinerea platformei de
vizualizare a datelor (fie că este o platformă
construită intern sau o soluţie externalizată la care
accesul este achiziţionat ca şi serviciu) şi alte costuri
asociate. Costurile variabile sunt date de
infrastructura de calcul şi prelucrare şi mentenanţa
sa.
 O slabă integrare a datelor.
 Granularitate incorectă a datelor în diferitele nivele.
 Metadate slabe.
 Lipsa de guvernanţă.
235
 Integrare completă a datelor care să implice prea

multe prelucrări în nivelul de integrare.
 Arhitectură semantică incorect proiectată.
În concluzie, există multiple modalităţi de integrare a

componentelor necesare pentru prelucrarea unor volume mari
de date semistructurate (adăugând la acestea datele structurate
şi nestructurate). Subcapitolul de faţă a trecut în revistă aceste
modele, avantajele şi dezavantajele lor, precum şi modul în
care sunt rezolvate unele probleme mai importante în aceste
arhitecturi.
4.1.2 Nivelul de analiză
Identificarea şi clasificarea cerinţelor de prelucrare

analitică pentru un întreg set de date, chiar la momentul
achiziţiei sau parcurgerii acestuia, este o cerinţă critică în
proiectarea unei soluţii de prelucrare a volumelor mari de date
semistructurate. Importanţa acestei cerinţe se naşte din faptul
că efectuarea prelucrărilor analitice imediat după achiziţia
datelor, până să fie filtrate şi deformate de utilizarea lor în
întreprindere, poate da rezultate mai obiective decât efectuarea
prelucrărilor analitice la nivelul de descoperire de date (metoda
obişnuită pentru aplicaţiile OLAP clasice) care este focalizat pe
anumite aspecte ale activităţii organizaţiei.
Figura 41 arată modul în care prelucrările analitice sunt
incorporate într-o soluţie de prelucrare a volumelor mari de
date organizate semistructurat. Nivelul cheie al arhitecturii este
nivelul de integrare a datelor, care este o combinaţie de
tehnologii semantice, analitice şi de raportare, combinaţie
236
bazată pe un cadru de cunoştinţe semantic (element cheie în

aplicaţiile moderne de prelucrări analitice şi inteligenţa
afacerii). Acest cadru de lucru este discutat imediat în
subcapitolul curent.
Figura 41 – Integrarea stratului semantic pentru vizualizarea datelor
Cadrul de lucru semantic
Construcţia unei soluţii de prelucrare a volumelor mari

de date organizate semistructurat necesită o arhitectură
puternică de metadate pentru integrarea datelor, dar aceasta nu
rezolvă cerinţele de explorare a datelor (date proaspăt
achiziţionate sau proaspăt integrate care nu au încă metadate
asociate, sau nu au un set complet de metadate asociate).
Atunci când datele din multiple surse şi sisteme sunt integrate,
coexistă multiple ierarhii, incluzând ierarhii inconsistente sau
deformate, apar valori diferite ale granularităţii datelor la
237
diverse nivele şi probleme de calitate a datelor (în special în

cazul datelor nestructurate). Prelucrarea şi prezentarea pentru
vizualizare a datelor necesită o arhitectură mai robustă care
poate fi creată printr-un cadru de lucru semantic.
Figura 42 prezintă arhitectura unui cadru de lucru
semantic. Cadrul de lucru constă în nivele multiple de
prelucrare şi tehnologii de integrare a datelor care vor deveni
părţi ale viitoarei soluţii de prelucrare a volumelor mari de
date. Alături de fiecare nivel, sunt precizate în figură şi
funcţiile sale:
Figura 42 – Cadrul de lucru semantic
Fiecare dintre cele cinci nivele este prezentat pe scurt în

paragrafele următoare.
238
Procesarea lexicală
Tehnologiile care compun acest strat pot fi aplicate atât

imediat după achiziţia / integrarea datelor, cât şi în interogările
de la nivelul de explorare a datelor. Procesarea lexicală implică
procesarea unor fragmente sau fluxuri de text. Procesarea
lexicală are trei componente majore:
 Extracţia entităţilor – este procesul identificării
fragmentelor de text cheie care includ anumite
cuvinte, concepte sau elemente principale
considerate a fi semnificative. Un exemplu este
identificarea denumirilor de produse dintr-un feed
Twitter.
 Taxonomia – este procesul de navigare peste un
domeniu semantic dintr-un flux de text pentru
identificarea contextelor din text şi descoperirea
atributelor relaţiilor dintre contexte, pentru a
permite mai departe explorarea datelor.
 Modelele relaţiilor – este procesul de derivare a
relaţiilor dintre diverse elemente sau nivele
existente în date, produsul rezultat fiind o hartă de
explorare. Acest proces se bazează pe rezultatele
obţinute de componentele anterioare.
Analiza cluster (clusterizarea)
Odată făcută procesarea lexicală, datele rezultate din

aceasta vor fi supuse unei operaţii de analiză cluster pentru a
crea grupările logice ale datelor prelucrate sau explorate în
239
diversele nivele ale soluţiei de prelucrare a volumelor mari de

date. Componentele tehnologice ale acest nivel sunt:
 Afinitatea / proximitatea este alcătuită din două
subcomponente. Afinitatea constă în determinarea
afinităţii între date stocate în diverse formate. Spre
exemplu, această componentă ar trebui să descopere
afinitatea între secvenţe video, imagini, texte şi
elemente de media social care tratează un subiect
comun. Proximitatea desemnează apariţia unor date
considerate a fi corelate în zone învecinate ale unui
text nestructurat.
 Clasificarea desemnează un proces în care datele
sunt clasificate în multiple grupuri de subiecte sau
asociate logic cu subiecte deja existente în datele
structurate existente în soluţie. Procesul este mai
curând orientat către pregătirea datelor pentru
prelucrare decât către prelucrarea propriu-zisă.
 Înlănţuirea / ierarhia constă în interconectarea
ieşirilor din procesul de clasificare într-o hartă
lexicală care include informaţiile ierarhice asociate.
Prelucrarea semantică a cunoştinţelor

Prelucrarea semantică a cunoştinţelor constă în
integrarea ieşirilor de date din nivelele de procesare lexicală şi
analiză cluster pentru a crea o arhitectură puternică pentru
vizualizarea datelor. Procesul de prelucrare semantică a
cunoştinţelor constă în următoarele componente:
 Asimilarea domeniului – constă în împerecherea şi
integrarea datelor din diverse domenii cu tehnologii
240
semantice corespunzătoare. La acest moment datele

sunt deja complexe integrate de date structurate şi
semistructurate.
 Programarea este o etapă care constă în crearea şi
aplicarea programelor necesare pentru completarea
procesului de integrare semantică. Această etapă
conţine de asemenea şi prelucrări adiţionale ale
datelor necesare pentru completarea integrării
(efectuarea unor procesări lexicale secundare sau
locale sau aplicarea unor tehnologii de machine
learning).
 Înlănţuirea metadatelor este ultimul pas din
prelucrarea semantică. La acest pas datele sunt
integrate cu legături către metadate care vor fi
utilizate în procesele de explorare vizuală şi data
mining.
Extragerea informaţiei
În acest proces, uneltele de vizualizare extrag datele
obţinute din nivelele anterioare de prelucrare şi le încarcă
pentru explorare vizuală sau analiză. Datele de la acest nivel
pot fi de asemenea furnizate ca intrări pentru alte tehnologii
pentru analize mai avansate.
Vizualizarea
La acest nivel datele pot fi vizualizate folosind diverse
tehnologii precum produsele tradiţionale Microstrategy,
Business Objects şi Cognos sau produse ceva mai noi cum sunt
241
Tableau, Spotfire, R sau SAS. Aceste produse sunt capabile să

utilizeze direct arhitectura semantică din nivelele lor de
integrare pentru a crea o interfaţă flexibilă.
Prezentarea tehnologiilor care compun nivelul de

analiză a completat arhitectura unei soluţii de prelucrare a
volumelor mari de date semistructurate prezentate în Figura 33
la începutul acestui subcapitol. Cele trei nivele componente
(nivelul datelor, nivelul de gestiune şi nivelul de analiză)
completează arhitectura unei soluţii de prelucrare având toate
calităţile necesare pentru a fi viabilă (scalabilitate,
disponibilitate, flexibilitate).
4.2 Implementarea unei soluții de măsurare a

performanței în prelucrarea volumelor mari de
date organizate semistructurat
Ţinând cont că unul dintre argumentele aduse pentru

utilizarea bazelor de date NoSQL este performanţa pe care o
oferă acestea, autorul a considerat că este imperios necesară
implementarea practică a unei facilităţi de măsurare a
performanţei transferurilor de date efectuate cu ajutorul
aplicaţii de administrare descrise în capitolul următor. O
asemenea facilitate este una dintre uneltele obişnuite ale muncii
de administrare a bazelor de date. În sfârşit, este de remarcat şi
faptul că o asemenea facilitate constituie un element de
noutate, întrucât în domeniul bazelor de date NoSQL,
exceptând YCSB (a se vedea subcapitolul 2.3.4) nu există alte
unelte similare.
242
Facilitatea respectivă se regăseşte în aplicaţie sub forma

celor trei opţiuni din submeniul Benchmark al aplicaţiei
ASMDB (aplicaţia de administrare a serverelor MongoDB
realizată de autor, ce va prezentată în capitolul 5).
4.2.1 Metodologie de lucru
Pentru măsurarea performanţei s-au proiectat

următoarele trei scenarii posibile pentru utilizarea SGBD-ului
MongoDB:
Bazele de date testate sunt utilizate pentru aplicaţii

OLTP.
Acest caz presupune următoarele condiţii:
 numărul de operaţii de citire este de aceeaşi
magnitudine cu numărul de operaţii de scriere;
 datele din fiecare tranzacţie atomică / operaţie la nivel
de „înregistrare” (document) sunt de dimensiuni de
ordinul zecilor de kiloocteţi;
Pentru a fi mai detaliat, în aplicaţia propusă autorul a
stabilit următoarele condiţii:
 Numărul de citiri = numărul de scrieri;
 Fiecare operaţie de citire sau de scriere operează cu un
document standard având următorul conţinut: trei
câmpuri întregi de 32 de biţi (ca substitute pentru un
câmp de tip id şi două câmpuri întregi generice), trei
câmpuri de tip float, trei câmpuri text de câte 100 de
caractere fiecare şi un câmp small blob (corespunzând
unui document sau unei imagini de dimensiuni reduse
243
stocate în baza de date). S-a ales dimensiunea câmpului

blob de 32.438 octeţi. Această dimensiune a fost aleasă
de aşa natură încât dimensiunea totală a documentului
să fie de 32.768 octeţi, permiţând calcularea uşoară a
dimensiunii totale a tranzacţiei pentru un număr variabil
de operaţii. În consecinţă, 32 de documente totalizează
1 MB de date, 160 de documente totalizează 5 MB de
date, 320 de documente totalizează 10 MB de date,
1600 de documente totalizează 50 MB de date, 3200 de
documente totalizează 100 MB de date, 16000 de
documente totalizează 500 MB de date ş.a.m.d.

Web 2.0.
 numărul de operaţii de citire este cu două-trei ordine de
mărime mai mare decât numărul de operaţii de scriere
(ex. pentru YouTube, conform unor statistici recente,
raportul dintre numărul de citiri şi cel de scrieri este de
aproximativ 1389:1);
ordinul megaocteţilor (ex. pentru YouTube
dimensiunea este destul de mare, dimensiunea unei
tranzacţii atomice este, în funcţie şi de rezoluţie şi de
calitate, de 20-150 megaocteţi, dar nu toate serviciile
Web 2.0 vehiculează date de dimensiuni atât de mari);
Pentru aplicaţia propusă, autorul a ales următoarele
condiţii:
244
 numărul de citiri = 500 * numărul de scrieri;

 fiecare operaţie de citire sau de scriere operează cu un
document standard având următorul conţinut: un câmp
întreg pe 32 de biţi (pe post de identificator), cinci
câmpuri text de 500 de caractere fiecare (corespunzând
unor descrieri şi comentarii) şi un câmp large blob
(corespunzând conţinutului media stocat în baza de
date). Pentru câmpul blob s-a ales dimensiunea de
5.241.346 octeţi. Din nou dimensiunea câmpului blob a
fost aleasă pentru a obţine o dimensiune “rotundă” a
documentului (5.242.880 octeţi = 5 MB), permiţând
calcularea uşoară a cantităţii totale de date
tranzacţionate pentru un număr oarecare de operaţii.

OLAP.
 numărul de operaţii de citire este cu unul sau două
ordine de magnitudine mai mare decât numărul de
operaţii de citire;
ordinul fracţiilor de kiloocteţi;
Pentru aplicaţia propusă, autorul a ales următoarele
condiţii:
 numărul de citiri = 100 * numărul de scrieri;
 fiecare operaţie de citire sau de scriere operează cu un
document standard având următorul conţinut: zece
câmpuri întregi de 32 de biţi, zece câmpuri float şi şapte
245
câmpuri de tip text de 132 de caractere fiecare (această

dimensiune a fost aleasă pentru a duce la o dimensiune
“rotundă” pentru document – 1024 octeţi = 1 kilooctet,
permiţând calcularea uşoară a cantităţii totale de date
tranzacţionate pentru un număr oarecare de operaţii.
4.2.2 Pregătirile efectuate înaintea testării
Ținând cont că sistemele de operare pentru care a fost

concepută aplicaţia propusă de autor sunt din familia Windows,
trebuie luate măsuri pentru a compensa pentru caracterul multi-
core, multi-tasking, multi-threading şi time-sharing al acestor
sisteme de operare.
Pentru început autorul a avut grijă să asigure o cantitate
maximă de resurse de calcul pentru aplicaţie prevenind în
acelaşi timp (pe cât de mult s-a putut) ca alte aplicaţii să
interfereze cu măsurătoarea:
using System.Diagnostics;
using System.Threading;
…
//Creare conditii de testare
Process.GetCurrentProcess().ProcessorAffinity = new IntPtr(2);
//Utilizeaza al doilea nucleu sau procesor pentru test
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
//Creste prioritatea procesului
Thread.CurrentThread.Priority = ThreadPriority.Highest;
//Creste prioritatea firului de executie
Ulterior, înainte de a începe măsurătoarea, s-a stabilizat

cache-ul şi pipeline-urile CPU (efectuarea intensivă a unei
246
singure operaţii vreme de 1000-1200 de milisecunde duce la

curăţarea memoriei tampon şi a pipeline-urilor de resturi de
date de la alte operaţii; autorul a ales un interval de 1500 de
milisecunde pentru siguranţă):
stopwatch.Reset();
stopwatch.Start();
while (stopwatch.ElapsedMilliseconds < 1500)
//O pauza de 1500 ms pentru stabilizarea cache-ului si pipeline-ului CPU.
{
i = (i + 1) % 10;
}
stopwatch.Stop();
După aceste măsuri pregătitoare se poate trece la

măsurarea performanţei propriu-zise atinse la operaţiile de
citire şi scriere.
4.2.3 Generarea datelor
În etapa de proiectare, autorul a formulat o ipoteză de

lucru conform căreia conţinutul tranzacţiilor de date ar putea
avea o oarecare influenţă asupra timpului necesar tranzacţiei
(din motive legate de existenţa unor mecanisme de compresie
în memorie şi / sau de protocoale de comunicaţii de date) aşa
încât s-a deciss să nu se utilizeze date pregenerate, ci să se
genereze date printr-un mecanism oarecare la fiecare rulare a
benchmark-ului, în cantităţile şi tipurile necesare conform cu
scenariul vizat (a se vedea metodologia de lucru propusă la
4.2.1).
247
Două generatoare distincte de numere aleatore au fost

utilizate pentru generarea numerelor şi respectiv a string-urilor.
Pentru variate tipuri de numere a fost utilizată clasa
Random. Pentru asigurarea că nicio secvenţă de date nu se
repetă la două rulări succesive, s-a utilizat ca seed pentru
generatorul de numere aleatoare o valoare diferită la fiecare
rulare (furnizată de un mic truc – s-a utilizat clasa Guid ca
generator de seed):
//Initializare generator de numere aleatoare cu seed variabil bazat pe GUID

Random rndNum = new
Random(int.Parse(Guid.NewGuid().ToString().Substring(0, 8),
System.Globalization.NumberStyles.HexNumber));
Pentru câmpurile de tip întreg s-a utilizat direct

generatorul de numere aleatoare, precum în exemplul de cod
următor:
val1 = rndNum.Next(-2000000, 2000000);
Pentru câmpurile de tip float s-au utilizat rapoarte de

numere aleatoare, precum în secvenţa de cod următoare:
val3 = (float)rndNum.Next(-2000000, 2000000) / (float)rndNum.Next(0,

4000000);
Pentru câmpuri de tip blob s-au generat aleator coduri

ASCII care au fost convertite mai târziu în caractere / octeţi. A
fost luată de asemenea şi precauţia de a genera caractere numai
dintr-o porţiune restrânsă a codului ASCII pentru a evita
248
posibilitatea ca interogările conţinând aceste date să fie

invalidate mai târziu din cauza apariţiei unui caracter special:
for (j = 0; j < 32438; j++)

blob[j] = char.ConvertFromUtf32(rndNum.Next(97, 122))[0];
Pe de altă parte, pentru stringuri s-a folosit o abordare

diferită (bazată pe un alt truc de programare) care este mai
rapidă decât generarea directă caracter cu caracter:
txt1 = "";
for (j = 0; j < 10; j++)
{
string bucata = Path.GetRandomFileName();
bucata = bucata.Substring(0, 10);
txt1 = txt1 + bucata;
}
Trebuie de asemenea menţionat şi faptul că generarea

datelor este un mare consumator de timp (precum se va vedea
în subcapitolul următor) şi din acest motiv s-a luat precauţia de
a o cronometra separat de restul măsurătorii.
4.2.4 Măsurătoarea propriu-zisă
Măsurătoarea consistă din cicluri de scriere a

documentelor urmate de cicluri de citire a documentelor
(conceptul de înregistrare nu are niciun sens în lumea NoSQL;
cele mai apropiate concepte sunt cele de document sau de
pereche cheie-valoare). Numărul de cicluri precum şi
conţinutul documentelor depinde de tipul de benchmark
249
intenţionat (a se vedea 4.2.1). Conexiunile la bazele de date

sunt făcute prin metodele obişnuite.
Notă: La acest moment facilitatea de benchmark este capabilă
să lucreze numai cu MongoDB şi MySQL dar autorul
intenționează, pentru dezvoltări ulterioare ale aplicaţiei, să
adauge şi Oracle database şi MS SQL la lista SGBD-urilor
relaţionale, iar pe partea de SGBD-uri NoSQL să fie adăugate
Redis şi CouchDB.
Operaţiile de bază de scriere repetate în ciclurile care fac parte
din măsurătoare sunt:
 Pentru MongoDB (exemplu de cod pentru scenariul de
utilizare OLTP):
var element = BsonElement.Create("id", BsonString.Create(id.ToString()));

document.Add(element);
element = BsonElement.Create("val1",
BsonString.Create(val1.ToString()));
element = BsonElement.Create("txt1", BsonString.Create(txt1));
250
element = BsonElement.Create("blob", BsonString.Create(blob_s));
colectie.Insert(document);
 Pentru MySQL (o singură tranzacţie pentru întreaga

înregistrare; exemplu de cod pentru scenariul de utilizare
OLTP):
string mysql_query = "INSERT INTO oltpbenchmark_table (id, val1, val2,

val3, val4, val5, val6, den1, den2, den3) VALUES(" + id.ToString() + ", " +
val1.ToString() + ", " + val2.ToString() + ", " + val3.ToString() + ", " +
val4.ToString() + ", " + val5.ToString() + ", \"" + blob_s + "\", \"" + txt1 +
"\", \"" + txt2 + "\", \"" + txt3 + "\")";
MySqlCommand mysql_cmd = new MySqlCommand(mysql_query,
mysql_connection);
mysql_cmd.ExecuteNonQuery();
Operaţiile de bază de citire repetate în ciclurile care fac parte

din măsurătoare sunt:
 Pentru MongoDB (exemplu de cod pentru scenariul de
utilizare OLTP):
foreach (var document in cursor)

{
id = document.GetElement(1).Value.ToInt32();
val1 = document.GetElement(2).Value.ToInt32();
val2 = document.GetElement(3).Value.ToInt32();
val3 = (float)document.GetElement(4).Value.ToDouble();
251
txt1 = document.GetElement(7).Value.ToString();
blob_s = document.GetElement(10).Value.ToString();
…
}
 Pentru MySQL (exemplu de cod pentru scenariul de

utilizare OLTP):
while (mysql_dataReader.Read())
{
id = mysql_dataReader.GetInt32(0);
val1 = mysql_dataReader.GetInt32(1);
val2 = mysql_dataReader.GetInt32(2);
val3 = mysql_dataReader.GetFloat(3);
blob_s = mysql_dataReader.GetString(6);
txt1 = mysql_dataReader.GetString(7);
…
}
La momentele corespunzătoare din timpul măsurătorii
câteva obiecte de clasă Stopwatch sunt startate, stopate şi
resetate corespunzător scopurilor pentru care sunt folosite
(respectiv cronometrarea generării de date, a operaţiilor de
scriere pentru MongoDB, a operaţiilor de scriere pentru
MySQL, a operaţiilor de citire pentru MongoDB şi a operaţiilor
de citire pentru MySQL). Autorul a ales să utilizeze clasa
Stopwatch pentru operaţiile de cronometrare pentru că
furnizează o măsurătoare destul de precisă a timpului.
252
La final, rezultatele (date în milisecunde) sunt stocate

într-un control de tip dataGridView şi reprezentate grafic pe un
control de tip Chart pentru uşurinţă la citire şi interpretare.
Aplicaţia este în acest moment capabilă să facă
măsurători pentru cantități de date prestabilite de 1 MO, 5 MO,
10 MO, 50 MO, 100 MO, 500 MO, 1 GO, 5 GO, 10 GO, 50
GO (prima valoare nu este disponibilă pentru scenariul Web
2.0, iar ultimele cinci valori sunt disponibile doar pe sistemele
de operare pe 64 de biţi, pe sistemele de operare pe 32 de biţi
MongoDB neavând loc suficient pe spaţiul de adrese de 232
adrese pentru alocarea memoriei necesare pentru baze de date
mai mari).
Un rezultat tipic al rulării măsurătorii este ilustrat în
Figura 43.
Figura 43 - Rezultatul măsurătorii pentru scenariul OLTP bazat pe o

cantitate de date de 100 MO, cu măsurători efectuate la 1 MB, 5 MB,
10 MB, 50 MB şi 100 MB
253
4.2.5 Constatări
În Figura 43 timpii daţi corespund generării datelor

(prima linie de valori), timpilor pentru operaţiile de scriere în
MongoDB (a doua linie), timpilor pentru operaţiile de scriere
în MySQL (a treia linie), timpilor pentru operaţiile de citire din
MongoDB (a patra linie) şi timpilor pentru operaţiile de citire
din MySQL (a cincea linie).
Concluziile rulării testelor sunt următoarele:
 operaţiile de scriere în MySQL necesită în mod
consistent timpi mult mai mari decât toate celelalte
tipuri de operaţii (ajungând până la de 20 de ori mai
mari) pentru că aceste operaţii sunt singurele care
necesită scriere directă pe disc. Toate celelalte tipuri de
operaţii sunt într-o măsură mai mare sau mai mică
efectuate în memoria RAM (generarea datelor, scrierile
şi citirile MongoDB precum şi citirile MySQL care
folosesc un cache RAM). Acest lucru afectează în mod
masiv “scorurile” la scenariul OLTP şi într-o măsură
mai redusă pe cele de la scenariile Web 2.0 şi OLAP;
 chiar atunci când se iau în considerare doar operaţiile
de citire, performanţa MongoDB este constant mai bună
decât cea a MySQL (rezultat care este de aşteptat,
luând în considerare faptul că toate soluţiile majore
NoSQL sunt mai puţin complexe şi mai puţin masive şi
în consecinţă se poate presupune că sunt şi mai rapide
decât corespondentele lor relaţionale);
 generarea datelor consumă timpi destul de ridicaţi (de 2
până la 5 ori mai mari decât timpii de citire sau scriere,
254
excepţie făcând timpii de scriere în MySQL comentaţi

mai sus. La momentul curent, în opinia autorului acest
lucru constituie o problemă (sesizabilă în special la
execuţiile efectuate pe cantităţi mari de date), autorul
intenţionând să găsească o soluţie alternativă pentru o
viitoare versiune a aplicaţiei;
 Timpii pentru operaţiile de citire sunt în mod consistent
mai reduşi decât cei de scriere pentru ambele SGBD-
uri, rezultat de asemenea previzibil ţinând cont că
citirile se efectuează din memorii cache şi nici nu
presupun operaţii atât de multe precum scrierile (nu
sunt modificate structuri, indecşi, fişiere sau alte
obiecte).
Pentru a verifica adecvarea metodei de măsurare
propuse (din punct de vedere al consistenţei şi
reprezentativităţii rezultatelor) datele rezultate dintr-un număr
suficient de mare de măsurători (320 de valori măsurate) a
celor patru variabile luate în considerare (timpul de scriere
pentru MongoDB, timpul de scriere pentru MySQL, timpul de
citire pentru MongoDB, timpul de citire pentru MySQL) au
fost analizate prin metode statistice (statistici descriptive,
corelaţie, regresie liniară, reprezentări grafice). Pentru analiza
statistică a acestor date a fost utilizat pachetul software IBM
SPSS, versiunea 21.
Ideea urmărită în analiză a fost determinarea modului în
care timpul necesar pentru operaţiile respective este
proporţional cu numărul de operaţii de diverse tipuri efectuate
(cantitatea de date transferată). În măsura în care poate fi
determinată o bună relaţie între cele două mărimi, se poate
255
spune că facilitatea de benchmark propusă funcţionează bine,

fiind capabilă să măsoare corect performanţa proceselor
urmărite. Fiecare analiză din cele de mai jos a fost aplicaţă pe
patru cazuri distincte în care variabilele independente sunt:
timpul necesar pentru operaţiile de scriere în MongoDB
(variabila MongoDB_scr), timpul necesar pentru operaţiile de
scriere în MySQL (variabila MySQL_scr), timpul necesar
pentru operaţiile de citire în MongoDB (variabila
MongoDB_cit), timpul necesar pentru operaţiile de citire în
MySQL (variabila MySQL_cit), iar variabila independentă este
dimensiunea setului de date utilizat / numărul de operaţii de
citire sau de scriere necesare (variabila Dim_set).
Ţinând cont de natura activităţii de benchmarking,
corelaţia urmărită este una liniară, drept pentru care metoda de
analiză utilizată a fost regresia liniară.
Primul indicator statistic luat în considerare a fost
coeficientul de corelaţie între cele două mărimi din fiecare
dintre cele patru seturi. Se poate observa în Tabelul 10 faptul
că în fiecare dintre cele patru cazuri coeficientul de corelaţie a
fost 1.0 iar covarianţa a fost foarte redusă. Acest lucru indică o
foarte bună corelaţie între mărimile din cele patru perechi, dar
şi faptul că perechile de variabile sunt bine alese.
Tabelul 10 - Coeficientul de corelaţie

MongoDB MySQL
Scriere
256
Citire
Următorul indicator statistic analizat a fost coeficientul

de determinare pentru a vedea în ce măsură intervalul de timp
măsurat este determinat de dimensiunea setului de date.
Valorile obţinute indică o determinare completă (R2 0.998 sau
mai mare) în condiţiile unei erori standard a estimării relativ
reduse). Tabelul 11 conţine datele obţinute în cursul acestei
analize.
Tabelul 11 - Coeficientul de determinare

MongoDB MySQL
Scriere
Citire
A treia analiză efectuată examinează reziduurile

standardizate rezultate din regresia liniară. Graficele din
Tabelul 12 permit comparaţia vizuală a reziduurilor
standardizate corespunzătoare diverselor măsurători cu panta
de tangentă 1 (corespunzătoare unei dependeţe liniare între
variabilele dependente şi variabila independentă). Reziduurile
indică influenţa unor factori externi (ex. alte procese active în
sistemul de operare gazdă) asupra timpilor măsuraţi şi se poate
257
observa în grafice că această influenţă este redusă şi nu se

schimbă semnificativ la creşterea dimensiunii setului de date pe
care se face măsurarea. Acest lucru confirmă de asemenea
corectitudinea metodologiei de măsurare propuse.
Tabelul 12 - Reziduuri standardizate

MongoDB MySQL
Scriere
Citire
În sfârşit, modelele de regresie (coeficienţi şi grade de

semnificaţie) obţinute în cele patru cazuri sunt cuprinse în
Tabelul 13. Se poate observa în fiecare caz valoarea foarte
scăzută a erorii standardizate pentru coeficientul variabilei
independente (stabilitatea dependeţei între variabila dependentă
şi variabila independentă) precum şi valoarea foarte ridicată
(0.999 sau mai mare) a indicatorului Beta (variaţia variabilei
258
dependente este complet determinată de variaţia variabilei

independente).
Tabelul 13 - Coeficienţii şi nivelul de semnificaţie al modelului

MongoDB
Scriere
Citire
MySQL
Scriere
Citire
Coeficienţii variabilei independente din cele patru

modele sunt de asemenea şi buni indicatori comparativi ai
performanţei obţinute în fiecare dintre cele tipuri de operaţii
259
(operaţiile de citire din MySQL sunt cele mai rapide, cu un

coeficient de 6.650, adică pentru fiecare Mo de date citite sunt
necesare 6,650 milisecunde, pe locul doi ca viteză sunt
operaţiile de scriere în MongoDB, cu un coeficient de 17,791,
pe locul trei operaţiile de citire din MongoDB, cu un coeficient
de 18,279 iar pe ultimul loc, la distanţă semnificativă,
operaţiile de scriere în MySQL, cu un coeficient de 64,961).
Subcapitolul 4.1 a conţinut o descriere extensivă a

modului în care ar trebui organizată o aplicaţie modernă de
prelucrare a volumelor mari date. Se poate trage concluzia că
generaţia următoare de astfel de soluţii va fi atât continuatoarea
depozitelor de date actuale, cât şi a soluţiilor strict non-
relaţionale disponibile în acest moment şi că la o astfel de
soluţie îşi vor aduce aportul şi alte tehnologii de ultimă oră
precum soluţiile de virtualizare a prelucrării datelor, algoritmii
de prelucrare semantică, procesare lexicală sau diverse metode
de extragere, explorare şi vizualizare a informaţiei.
Cel de-al doilea subcapitol din capitolul patru a descris
modul în care se poate face măsurarea performanţelor de care
este capabilă infrastructura unui sistem de prelucrare a
volumelor mari de date.
260
Partea a treia - Abordarea programatică a

Big Data
5 Proiectarea și implementarea unei aplicații de
interfață pentru organizarea și prelucrarea
volumelor mari de date semistructurate
Aplicaţia implementată de către autor şi prezentată în

acest capitol intenţionează să acopere unul dintre golurile
sesizate ceva mai devreme în această lucrare şi anume lipsa
relativă de instrumentar de lucru şi administrare pentru noile
sisteme de stocare a volumelor mari de date (bazele de date
NoSQL). Aplicaţia va fi numită în continuare ASMDB
(Administrarea Serverelor MongoDB).
În urma analizei comparative a soluţiilor NoSQL
existente pe piaţă, pentru acest pas din dezvoltarea aplicaţiei a
fost ales ca ţintă sistemul MongoDB, din motive legate în
principal de performanţă dovedită, flexibilitate, prezenţa pe
piaţă deja realizată şi uşurinţa în utilizare (Tudorică, A new
application for the management of the MongoDB servers,
2013).
MongoDB prezintă caracteristicile descrise mai jos
(informaţiile prezentate sunt preluate din (Bucur & Tudorică, A
Research on Retrieving and Parsing of Multiple Web Pages for
Storing Them in Large Databases, 2012).
MongoDB este un sistem de baze de date performante,
scalabile. Datele sunt stocate ca documente, care permit
reprezentarea relaţiilor complexe, într-un singur obiect.
Documentele pot fi compuse din câmpuri individuale cu tipuri
261
fundamentale de date, „documente incluse” sau vectori de

documente. Această flexibilitate permite unui dezvoltator să
modeleze o gamă largă de probleme într-un mod flexibil fără să
apeleze la împărţirea datelor în tabele. Pentru cazurile în care
datele nu pot fi modelate ca un singur document, MongoDB
introduce conceptul de DBRef, care este un pointer de la un
câmp dintr-un document la un alt document.
Extragerea şi interogarea datelor în MongoDB este
flexibilă – documentele pot fi interogate dinamic pe baza
documentului principal, a oricărui câmp din document, a
oricărui document inclus, sau a oricărui document inclus într-
un vector.
Scris în C++, MongoDB are următoarele caracteristici:
 stocare orientată pe documente (foloseşte puterea şi
flexibilitatea schemelor de date de tip JSON);
 obiecte incluse, vectori încorporaţi, informaţii
geospaţiale;
 interogări dinamice;
 suport pentru indecşi, inclusiv indici secundari;
 actualizări rapide ale datelor;
 stocare eficientă a obiectelor binare de mari
dimensiuni (poze, video);
 suport de replicare şi cădere a sistemului;
 Auto-sharding (auto-partiţionare) pentru
scalabilitate (Liu, Wang, & Jin, 2012);
 MapReduce pentru agregări complexe;
 suport comercial, consultanţă şi instruire.
MongoDB este publicat sub licenţa GNU şi codul sursă
poate fi compilat pe orice sistem de operare. Sistemul poate fi
262
instalat ca executabil binar în Linux, MacOS X, Windows şi

Solaris. Sistemul rulează ca proces daemon mongod – nucleul
serverului BD care poate fi accesat prin drivere.
Partiţionarea şi rutarea sunt realizate prin serviciul
mongos. Drivere pentru accesul la server sunt disponibile
pentru o multitudine de limbaje de programare curent folosite:
C, C++, C# & .NET, ColdFusion, Erlang, Factor, Java,
Javascript, PHP, Python, Ruby, Perl.
MongoDB poate fi rulat în două moduri, în funcţie de
necesităţile aplicaţiei. Primul mod este „single master” unde
există un singur server master pentru toate operaţiunile de
scriere. Operaţiile de citire pot fi executate de pe serverul
master sau de pe orice număr de servere client (slave).
Pentru aplicaţii în care volumul de date este mare sau
frecvenţa operaţiilor de scriere este ridicată se foloseşte modul
de auto-partiţionare (auto-sharding). În acest mod, operaţiile de
scriere sunt distribuite automat între partiţii (shard – un server
sau un grup de servere BD), fiecare executând operaţii de
scriere /citire pe o porţiune din date.
Accesibilitatea este obţinută prin replicarea datelor în
multiple noduri MongoDB, oricare putând lua rolul de master
la un moment dat.
MongoDB prevede, de asemenea, caracteristici care
merg dincolo de operaţiunile elementare pentru baze de date.
De exemplu, acesta oferă o soluţie bună pentru a stoca fişiere
de mici şi mari dimensiuni în baza de date. Fişierele sunt în
mod automat împărţite în bucăţi. Dacă MongoDB rulează într-
un mediu auto-sharded, bucăţi de fişiere sunt, de asemenea,
replicate pe mai multe servere.
263
Stocarea fişierelor este o problemă foarte dificilă de

rezolvat în mod eficient, în special atunci când se gestionează
un număr mare de fişiere. Salvarea de fişiere într-un sistem
local nu este de cele mai multe ori o soluţie bună. MongoDB
rezolvă această problemă prin crearea a două colecţii interne:
colecţia de imagini care păstrează informaţiile despre
metadatele fişierelor şi colecţia de partiții care păstrează
informaţii despre partiţiile de fișiere.
MongoDB permite operaţii de MapReduce. MapReduce
sunt operaţii pentru manipularea de seturi mari de informaţii.
Operaţiile „map” aplică o funcţie tuturor documentelor şi
obţine un nou set de perechi cheie-valoare. Operaţiile „reduce”
preiau rezultatul operaţiunilor map şi aplică alte funcţii pentru
a returna un singur rezultat pe cheie. La terminarea procesului
„map” rezultatul este sortat şi grupat după valorile cheilor.
Pentru fiecare cheie rezultată, funcția „reduce” este apelată cu
doi parametri: o cheie şi un vector cu toate valorile.
5.1 Proiectarea aplicației. Facilități urmărite
Pentru a proiecta în bune condiţii aplicaţia propusă,

autorul a utilizat unealta CASE CodeComplete, unealtă care
permite parcurgerea întregului proces proiectare software,
urmărind etapele obişnuite. Dintre facilităţile oferite de această
unealtă CASE, autorul a recurs la utilizarea diagramelor de
context, a diagramelor de cazuri de utilizare, a tabelelor de
cazuri de test şi la generarea tabelului cu actorii şi cazurile de
utilizare corespunzătoare. Capitolul de faţă preia din rezultatele
264
activităţii de proiectare informaţiile considerate de către autor a

fi necesare pentru o bună descriere a aplicaţiei.
5.1.1 Stabilirea facilităţilor oferite de aplicaţie
Diagrama de context
Pentru stabilirea facilităţilor ce ar trebui oferite de

aplicaţie, autorul a utilizat o diagramă de context pentru
aplicaţie şi respectiv diagrame de cazuri de utilizare pentru
fiecare dintre grupurile de facilităţi oferite de aplicaţie.
Contextul aplicaţiei este reprezentat în Figura 44. Sunt
reprezentate schematic aplicaţia, actorii participanţi la aplicaţie
şi interacţiunile dintre aceştia.
Figura 44 – Diagrama de context a aplicaţiei ASMDB
265
Utilizatorul tipic al aplicaţiei ASMDB, denumit în

continuare administrator (facilităţile oferite de aplicaţie sunt
îndeosebi utile administratorilor de baze de date) este instanţiat
separat în diagrama de context pentru fiecare dintre grupurile
de facilităţi pe care le-ar putea folosi (aceste fiind autonome
între ele). Rezultă astfel doisprezece actori din care nouă sunt
instanţe ale administratorului implicat în diverse tipuri de
activităţi, două reprezintă cele două servere de baze de date la
care se poate conecta aplicaţia, iar unul este sistemul de calcul
pe care rulează aplicaţia.
Diagramele cazurilor de utilizare
Pentru aplicaţia ASMDB au fost identificate

următoarele grupuri de cazuri de utilizare:
 iniţializarea aplicaţiei, pornirea şi oprirea serverului
MongoDB şi operaţiile auxiliare;
 obţinerea de informaţii despre sistemul pe care
rulează ASMDB;
 gestiunea bazelor de date;
 gestiunea conturilor de utilizator;
 gestiunea colecţiilor;
 gestiunea documentelor;
 operaţiile de benchmark şi de validare;
 solicitarea de informaţii despre aplicaţie.
Fiecare grup de cazuri de utilizare în parte este ilustrat
separat prin diagrama cazurilor de utilizare şi descrierea
actorilor şi a acţiunilor întreprinse de aceştia.
266
Cazurile de utilizare 1-5 (iniţializarea aplicaţiei,

pornirea şi oprirea serverului MongoDB şi operaţiile auxiliare)
sunt reprezentate în diagrama din Figura 45.
Figura 45 – Diagrama cazurilor de utilizare pentru iniţializarea

aplicaţiei, pornirea şi oprirea serverului MongoDB şi operaţiile
auxiliare
Actori implicaţi:
 Administrator (start, stop) (A-1):
Administratorul iniţializează aplicaţia. Aceasta va
încerca să se conecteze la un server MongoDB aflat pe sistemul
local. În cazul în care serverul nu este disponibil, se inhibă
afişarea informaţiilor despre server. Ulterior administratorul
poate opta să pornească manual un server sau să oprească
serverul la care aplicaţia este conectată. De asemenea, poate fi
267
activată sau dezactivată manual afişarea informaţiilor despre

serverul la care aplicaţia este curent conectată.
Cazuri de utilizare: UC-1 iniţializare aplicaţie, UC-2
pornire Server MongoDB, UC-3 oprire Server MongoDB, UC-
4 activare afişare informaţii despre server, UC-5 dezactivare
afişare informaţii despre server
 Server MongoDB (A-10):
Cazuri de utilizare: UC-2 pornire Server MongoDB,
UC-3 oprire Server MongoDB
 Sistem de calcul pt. ASMDB (A-12):
Cazuri de utilizare: UC-1 iniţializare aplicaţie
Cazurile de utilizare 6-7 (obţinerea de informaţii despre

sistemul pe care rulează ASMDB) sunt reprezentate în
diagrama din Figura 46.
Figura 46 – Diagrama cazurilor de utilizare pentru obţinerea de

informaţii despre sistemul pe care rulează ASMDB
268
Actori implicaţi:
 Administrator (info despre sistem) (A-2)
Administratorul solicită informaţii despre sistemul de
calcul pe care rulează aplicaţia sau despre echipamentele de
reţea instalate pe sistemul respectiv şi despre modul în care
acestea sunt configurate.
Cazuri de utilizare: UC-6 solicitare informaţii despre
sistemul pe care rulează ASMDB, UC-7 solicitare informaţii
despre adaptoarele de reţea de pe sistemul pe care rulează
ASMDB şi configurarea acestora.
 Sistem de calcul pt. ASMDB (A-12)
Cazuri de utilizare: UC-6 solicitare informaţii despre
sistemul pe care rulează ASMDB, UC-7 solicitare informaţii
despre adaptoarele de reţea de pe sistemul pe care rulează
ASMDB şi configurarea acestora.
Cazurile de utilizare 8-10 sunt reprezentate în diagrama

din Figura 47.
269
Figura 47 – Diagrama cazurilor de utilizare pentru operaţiile de

gestiune a bazelor de date
Actori implicaţi:
 Administrator (gestiunea BD) (A-3)
Administratorul vizualizează lista bazelor de date
existente, creează baze de date noi sau şterge baze de date
existente.
Cazuri de utilizare: UC-8 vizualizare listă baze de date
existente, UC-9 adăugare bază de date nouă, UC-10 ştergere
bază de date existentă.
 Server MongoDB (A-10)
Cazuri de utilizare: UC-8 vizualizare listă baze de date
existente, UC-9 adăugare bază de date nouă, UC-10 ştergere
bază de date existentă.
270
Cazurile de utilizare 11-16 (gestiunea conturilor de

utilizator) sunt reprezentate în diagrama din Figura 48.

gestiune a conturilor de utilizator
Actori implicaţi:
 Administrator (gestiune useri) (A-4)
Administratorul vizualizează lista utilizatorilor, creează
utilizatori noi, şterge utilizatori existenţi, schimba parola sau
drepturile de acces ale utilizatorilor existenţi.
Cazuri de utilizare: UC-11 vizualizare listă utilizatori
existenţi, UC-12 creare utilizator nou, UC-13 ştergere utilizator
existent, UC-14 schimbare parola utilizator existent, UC-15
271
vizualizare drepturi de acces utilizator existent, UC-16

schimbare drepturi de acces utilizator existent.
Cazuri de utilizare: UC-11 vizualizare listă utilizatori
existenţi, UC-12 creare utilizator nou, UC-13 ştergere utilizator
existent, UC-14 schimbare parola utilizator existent, UC-15
vizualizare drepturi de acces utilizator existent, UC-16
schimbare drepturi de acces utilizator existent.
Cazurile de utilizare 17-20 (gestiunea colecţiilor) sunt

reprezentate în diagrama din Figura 49.
Figura 49 – Diagrama cazurilor de utilizare pentru gestiunea colecţiilor
Actori implicaţi:
 Administrator (gestiune colecţii) (A-5)
Administratorul vizualizează lista colecţiilor,
vizualizează conţinutul unei colecţii, adaugă o colecţie nouă
sau şterge o colecţie existentă.
272
Cazuri de utilizare: UC-17 vizualizare listă colecţii

existente, UC-18 vizualizare conţinut colecţie existentă, UC-19
creare colecţie nouă, UC-20 ştergere colecţie existentă.
Cazuri de utilizare: UC-17 vizualizare listă colecţii
existente, UC-18 vizualizare conţinut colecţie existentă, UC-19
creare colecţie nouă, UC-20 ştergere colecţie existentă.
Cazurile de utilizare 21-22 (gestiunea documentelor)

sunt reprezentate în diagrama din Figura 50.
Figura 50 – Diagrama cazurilor de utilizare pentru gestiunea

documentelor
Actori implicaţi:
 Administrator (gest. documente) (A-6)
Administratorul adaugă un document nou într-o colecţie
existentă sau şterge un document existent dintr-o colecţie
existentă.
273
Cazuri de utilizare: UC-21 adăugare document nou în

colecţie existentă, UC-22 ştergere document existent dintr-o
colecţie existentă.
Cazuri de utilizare: UC-21 adăugare document nou în
colecţie existentă, UC-22 ştergere document existent dintr-o
colecţie existentă.
Cazurile de utilizare 23-24 (operaţiile de benchmark şi

de validare) sunt reprezentate în diagrama din Figura 51.

benchmark şi de validare
Actori implicaţi:
 Administrator (benchmark) (A-7)
Administratorul execută o măsurătoare comparativă a
performanţelor obţinute de Server MongoDB şi server MySQL.
Cazuri de utilizare: UC-23 execuţie benchmark
 Administrator (validare) (A-8)
274
Administratorul validează operaţiile de citire şi scriere

efectuate pe Server MongoDB prin compararea citirilor şi
scrierilor în cadrul unui ciclu de teste de validare.
Cazuri de utilizare: UC-24 validare operaţii de citire şi
scriere
Cazuri de utilizare: UC-23 execuţie benchmark, UC-24
validare operaţii de citire şi scriere
 Server MySQL (A-11)
Cazuri de utilizare: UC-23 execuţie benchmark
Cazul de utilizare 25 (solicitarea de informaţii despre

aplicaţie) este reprezentat în diagrama din Figura 52.
Figura 52 – Diagrama cazurilor de utilizare pentru solicitarea de

informaţii despre aplicaţie
Actori implicaţi:
 Administrator (help) (A-9)
Administratorul obţine informaţii despre ASMDB
Cazuri de utilizare: UC-25 obţinere informaţii de ajutor
5.1.2 Stabilirea cerinţelor
Cerinţele de facilităţi au fost încorporate în cazurile de

utilizare expuse în subcapitolul precedent.
275
În ceea ce priveşte cerinţele tehnice stabilite pentru

aplicaţie, acestea sunt descrise în cele ce urmează.
Aplicaţia propusă trebuie să ruleze pe orice calculator
personal de generaţie actuală care are resurse suficiente pentru
rularea simultană a unui server MongoDB şi a unui server
MySQL în cazul în care s-ar dori execuţia celor trei
componente pe o singură maşină de calcul. De asemenea,
trebuie să fie posibilă execuţia şi în cazul în care cele trei
componente sunt pe maşini de calcul distincte sau în cazuri
combinate.
MongoDB necesită pentru execuţie sisteme de calcul
little-endian (mai precis procesoare de clasă x86 / x86_64).
Cantitatea de memorie RAM şi de spaţiu de stocare nu sunt
limitate explicit, din acest punct de vedere cerinţele de resurse
fiind modeste.
MySQL are ca necesităţi hardware minime un procesor
dual-core (recomandat quad-core), 2 GB memorie RAM
(recomandat 8 GB) şi un spaţiu de disc de cel puţin 1300 MB
(din care 800 de MB pentru Service Manager şi 500 MB pentru
Monitoring Agent). Este posibilă şi utilizarea unei versiuni
limitate de MySQL care necesită un spaţiu de stocare mult mai
redus (aproximativ 50 MB), dar are aceleaşi necesităţi de
procesor şi RAM ca şi versiunea completă.
Maşina / maşinile de calcul pe care se află instalate
serverele mai trebuie să dispună suplimentar de spaţiul de disc
necesar pentru bazele de date intenţionate şi de un supliment de
spaţiu de disc de aproximativ 2 GB pentru rularea benchmark-
urilor.
276
În ceea ce priveşte cerinţele de sistem de operare, atât

MongoDB cât şi MySQL pot rula pe multiple sisteme de
operare. Pentru aplicaţia propriu-zisă, pentru a evita
complicaţiile de implementare, autorul a optat pentru realizarea
aplicaţiei strict pentru sistemele de operare de clasă Windows
de generaţie recentă (XP, Vista, 7, 8, 2008, 2012) care sunt de
asemenea utilizabile şi pentru serverul MongoDB şi pentru cel
MySQL.
Pentru benchmark-uri de 500MB sau mai mari, sistemul
de operare trebuie să fie pe 64 de biţi (colecţiile MongoDB
sunt limitate ca dimensiune de cantitatea de memorie
accesabilă).
Din punct de vedere software, sunt necesare librăriile
.Net Framework versiunea 3.5 (pentru aplicaţie, dacă este
compilată folosind Visual Studio 2008), .Net Framework
versiunea 4 (pentru MySQL şi pentru aplicaţie, dacă aceasta
este compilată folosind Visual Studio 2010), Microsoft Visual
C++ 2010 Redistributable Package (x86) (pentru MySQL) şi
librăria GNU C (glibc), cel puţin versiunea glibc-2.12-1.2.el6
(pentru MongoDB).
Subcapitolul curent a conţinut ideile de care s-a ţinut
cont în proiectarea aplicaţiei. În subcapitolul următor este
descrisă implementarea propriu-zisă a aplicaţiei şi rezultatele
obţinute.
5.2 Implementarea aplicației ASMDB. Rezultate
obținute
Limbajul de programare folosit în realizarea aplicaţiei

ASMDB este C Sharp, un limbaj relativ nou, flexibil, oferit ca
277
şi componentă a mediului vizual de dezvoltare de aplicaţii

Microsoft Visual Studio. Aplicaţia a fost dezvoltată în
versiunea 2008 a mediului C Sharp.
Pentru conexiunea efectivă la serverul de baze de date a
fost folosit un driver dezvoltat în sistem open source de o terţă
parte (MongoDB Inc., 2013).
Interfaţa aplicaţiei este una multifereastră, relativ
simplă din punct de vedere grafic, care intenţionează să ofere
un maxim de intuitivitate şi respectiv de uşurinţă în utilizare.
Grupul ţintă de utilizatori avuţi în vedere pentru proiectarea
interfeţei cu utilizatorul este alcătuit din administratori de baze
de date şi respectiv dezvoltatori de aplicaţii. De la începutul
dezvoltării, interfaţa a suferit o iteraţie majoră ce a constat în
regruparea funcţiilor oferite pe meniuri pentru creşterea
nivelului de intuitivitate. În acest moment nu se mai prevăd
îmbunătăţiri majore ale interfeţei.
Funcţiile oferite de aplicaţie încearcă să acopere cel
puţin operaţiile de bază de administrare a unei baze de date:
 Facilităţi legate de conectivitate:
o facilităţi implicite: citirea şi afişarea stării
serverului de câte ori este nevoie – după
evenimentele considerate a fi semnificative
(ex. revenirea dintr-o operaţie de
administrare sau revenirea dintr-o altă
aplicaţie);
o facilităţi explicite: pornirea şi respectiv
oprirea unui server MongoDB local;
 Facilităţi de gestiunea bazelor de date:
o crearea unei baze de date;
278
o ştergerea unei baze de date;

 Facilităţi legate de gestiunea utilizatorilor bazelor de
date:
o crearea unui utilizator;
o ştergerea unui utilizator;
o schimbarea parolei unui utilizator;
o vizualizarea şi schimbarea drepturilor de
acces ale unui utilizator;
 Facilităţi legate de gestiunea colecţiilor din bazele
de date:
o crearea unei colecţii;
o vizualizarea conţinutului unei colecţii;
o ştergerea unei colecţii;
 Facilităţi legate de gestiunea documentelor din
colecţii:
o crearea unui document;
o ştergerea unui document.
Modul de implementare al fiecăreia dintre facilităţile
listate va fi comentat pe scurt ceva mai jos, la momentul
prezentării facilităţii respective.
Implementarea aplicaţiei ASMDB a fost făcută în
metodologia bottom-up (intrările de meniu din interfaţa grafică,
structurile de date necesare şi respectiv formele
corespunzătoare au fost introduse pe măsura introducerii de noi
facilităţi).
Ordinea în care au fost introduse facilităţile a fost una
oarecum determinată de logica de utilizare (baze de date →
utilizatori → colecţii → documente), excepţie făcând
facilităţile legate de conectivitate care au fost dezvoltate parţial
279
la început (o parte din citirea stării serverului + realizarea

efectivă a conexiunii la acesta bazată pe premiza că serverul
este deja pornit manual de către utilizator) şi suplimentate în
patru iteraţii la diverse momente în timp (mecanismul de
reîmprospătare a stării serverului a fost îmbunătățit de două ori,
odată prin adăugarea de informaţii suplimentare în afişaj, odată
prin adăugarea unei duble forme de control asupra momentului
de declanşare a citirii stării serverului; a fost adăugat un
mecanism de oprire din aplicaţie a serverului; a fost adăugat un
mecanism de pornire din aplicaţie a unui server local)
(Tudorică, Tools for data conversion/Migration and problems
solved by such tools - Taxonomy and small case studies ,
2010).
Pe parcursul subcapitolelor următoare va fi ilustrată
implementarea aplicaţiei, cu secvenţe de cod de foarte mici
dimensiuni reprezentative pentru facilitatea descrisă.
5.2.1 Conectarea la server şi iniţializarea
Conectarea la server se face prin intermediul driverului

C# şi presupune un mecanism foarte simplu de lucru.
Conectarea şi deconectarea propriu-zise sunt realizate de driver
care administrează automat un pool de conexiuni (Schindler,
2012). Sunt chiar contraindicate de către furnizorul driverului
conectarea şi deconectarea explicite (deşi acestea sunt
posibile)9.
9
***, Getting Started with the CSharp Driver, MongoDB Wiki
280
O formă foarte simplificată a mecanismului de

conectare (fără tratarea erorilor şi fără acces propriu-zis la date)
este asigurată de secvenţa de cod următoare:
var connectionString = "mongodb://localhost/?safe=true";
try
{
var server = MongoServer.Create(connectionString);
...
(sunt precizate locaţia serverului printr-un şir de conectare, este
forţată obţinerea unui anumit nivel de consistenţă prin
parametrul safe=true şi se face conexiunea propriu-zisă).
Cu opţiunea safe=true (ceea ce serializează cererile),
MongoDB oferă consistenţă puternică pentru un server atomic,
dar şi pentru un cluster cu auto-sharding şi replicare, respectiv
consistenţă monotonică la citire în caz contrar şi respectiv
consistenţă în cele din urmă de tip „read-your-writes” dacă sunt
luate măsuri programatice suplimentare.
Filosofia de iniţializare a aplicaţiei porneşte de la
premisa că un server local MongoDB este deja activ, drept
pentru care, la iniţializare aplicaţia încearcă să se conecteze la
acesta. În cazul în care conectarea a eşuat, un mesaj de eroare
este afişat utilizatorului şi aplicaţia trece într-o stare pasivă în
care informaţiile despre server nu mai sunt automat citite.
Această stare suprascrie setarea “Actualizarea automată a
informaţiilor despre server” din meniul “Operaţii generale”
pentru a evita intrarea într-un ciclu infinit de încercare de
conectare – revenire în aplicaţie. Mecanismul de control este
realizat prin două variabile booleene (una declarată explicit:
“bool reincarca;” şi una implicită, reprezentată de atributul
“Checked” al componentei de meniu
281
“actualizareaAutomatăAInformaţiilorDespreServerToolStripM
enuItem”). Revenirea din această stare se realizează manual
prin apelarea opţiunii “Actualizarea forţată a informaţiilor
despre server” din meniul “Operaţii generale”.
În cazul în care, în cadrul procesului de iniţializare,
aplicaţia nu a găsit niciun server activ şi a intrat în starea
descrisă mai sus, ea nu afişează niciun fel de informaţii de
stare. Chiar şi în acest caz, toate funcţiile din meniuri sunt
active – cea previzibilă, de pornire a unui server, dar şi toate
celelalte, pentru cazul în care un server MongoDB a fost pornit
manual de către utilizator. Fiecare dintre funcţionalităţi este
autonomă, în sensul că pentru fiecare operaţie în parte
conectarea la server şi tratarea erorilor la conectare sunt
realizate separat de funcţionalitatea de citire a stării serverului.
Pentru pornirea unui server local este disponibilă
opţiunea omonimă din meniul “Servere”. Apelarea opţiunii
respective va duce la activarea componentei Form13 care este
o fereastră de dialog pentru stabilirea căii către serverul local şi
posibila pornire a acestuia.
Pornirea unei aplicaţii externe (serverul MongoDB) este
realizată utilizând clasa “Process” din biblioteca
“System.Diagnostics” precum în secvenţa de cod de mai jos:
Process p = new Process();
p.StartInfo.WorkingDirectory =
Path.GetDirectoryName(textBox1.Text);
p.StartInfo.FileName = textBox1.Text;
p.StartInfo.WindowStyle = ProcessWindowStyle.Minimized;
//p.StartInfo.Arguments = "";
p.Start();
Notă: atribuirea p.StartInfo.Arguments = ""; este
introdusă în vederea adăugării pe viitor de opţiuni de control al
282
modului în care este iniţializat serverul şi al implementării

facilităţii de lucru cu servere cluster.
Pentru selectarea serverului local utilizat şi a căii către
acesta este utilizată componenta pre-existentă
“OpenFileDialog”. Pentru segregarea şirului de caractere
returnat de aceasta în cele două componente utile (cale şi nume
fişier), este utilizată metoda “Path.GetDirectoryName” din
biblioteca “System.IO”.
Ca extindere pentru o versiune ulterioară a aplicaţiei se
intenţionează:
 adăugarea abilităţii de a porni servere remote;
 adăugarea unui mecanism de modificare globală
a şirului de conectare folosit de componentele
aplicaţiei de aşa natură încât să permită
modificarea parametrilor de conectare şi să ţină
cont de poziţia (locală sau remote – în acest
moment aplicaţia lucrează doar cu servere
locale) a serverului.
În cazul în care este pornit de aplicaţie, procesul
serverului ocupă o fereastră minimizată (pentru a nu deranja
operarea aplicaţiei).
Odată pornit, un server MongoDB îşi desfăşoară
execuţia într-o fereatră text proprie, lucru care permite
urmărirea în paralel a efectelor execuţiei diverselor comenzi
date de aplicaţie.
În sfârşit, admiţând că procesul de conectare s-a
desfăşurat cu succes (şi aplicaţia a fost scoasă din starea pasivă
descrisă la începutul acestui subcapitol, dacă a fost cazul),
283
fereastra principală a aplicaţiei va afişa date despre starea

serverului (Figura 53).
Informaţiile furnizate constau în următoarele:
 tipul şi versiunea sistemului de operare gazdă;
 versiunea şi subversiunea serverului;
 numărul de baze de date existente pe server şi lista
acestora;
 modul de conexiune la server;
 durata maximă de inactivitate şi durata maximă a
unei conexiuni;
 număr minin şi număr maxim de conexiuni în pool-
ul de conexiuni asigurat de driver;
 modul de lucru (safe sau nu);
 adresa serverului;
 portul utilizat pentru conectare;
 starea serverului;
 tipul de server utilizat (pe 32 sau pe 64 de biţi).
Figura 53 – Aspectul aplicaţiei ASMDB în cazul în care aceasta este

conectată la un server
284
La orice moment, aplicaţia poate opri serverul

MongoDB printr-un mecanism oferit de driverul utilizat.
Opţiunea corespunzătoare se numeşte “Oprirea serverului activ
în acest moment” şi se găseşte în meniul “Servere”.
Este de menţionat faptul că oprirea serverului prin
intermediul aplicaţiei decuplează actualizarea automată a
informaţiilor despre server (unul dintre mecanismele de control
menţionate anterior). Secvenţa de cod utilizată, într-o formă
simplificată, este cea de mai jos:
var connectionString = "mongodb://localhost/?safe=true";
try
{
server.Shutdown();
afisare_stare_nula();
reincarca = false;
actualizareaAutomatăAInformaţiilorDespreServerToolStripMenuIt
em.Checked = false;
...
5.2.2 Obţinerea de alte informaţii necesare pentru

activitatea de administrare
În scopul facilitării activităţii de administrare, aplicaţia

propusă conţine şi două utilitare care au ca scop obţinerea de
informaţii despre sistemul de calcul pe care rulează. Comenzile
pentru cele două utilitare (“Informaţii despre sistem” şi
respectiv “Informaţii despre conexiunile de reţea”) sunt
localizate în meniul “Operaţii generale”.
Ambele utilitare sunt bazate pe utilizarea unor obiecte
din clasele ManagementScope, ObjectQuery,
285
ManagementObjectQuery, ManagementObject, şi respectiv

ManagementObjectCollection (disponibile în biblioteca .Net
numită System.Management). Diferenţa între utilitare este dată
de utilizarea claselor WMI (Windows Management
Instrumentation) Win32_OperatingSystem, Win32_Processor,
Win32_BaseBoard, Win32_PhysicalMemory şi
Win32_DiskDrive în primul caz şi respectiv, în cel de-al doilea
caz, a claselor WMI Win32_NetworkAdapterConfiguration şi
Win32_NetworkAdapter.
Notă: Pentru o posibilă versiune comercială a aplicaţiei
propuse, pot fi furnizate şi alte informaţii utile despre sistem
prin utilizarea altor clase WMI (precum, spre exemplu,
Win32_Account sau Win32_VolumeQuota).
Elementul de bază al implementării pentru cele două
utilitare este relativ simplu, aşa cum se poate vedea în
exemplul următor:
textBox1.Text = textBox1.Text + "CONFIGURAŢII DE REŢEA" +

Environment.NewLine;
textBox1.Text = textBox1.Text + "********************" +
query = new ObjectQuery("SELECT * FROM
Win32_NetworkAdapterConfiguration");
searcher = new ManagementObjectSearcher(scope, query);
queryCollection = searcher.Get();
foreach (ManagementObject m in queryCollection)
{
try
{
string[] str = (string[])m["DefaultIPGateway"];
for (i = 0; i < str.Count(); i++)
{
286
textBox1.Text = textBox1.Text + "Gateway: " + str[i] +

}
}
catch(ArgumentNullException eroare)
{
textBox1.Text = textBox1.Text + "Gateway: N/A - "
+eroare.Message +Environment.NewLine;
}
Elementul de dificultate a constat în selectarea acelor

obiecte ManagementObject disponibile nu numai în cazuri
particulare (selectare bazată pe încercări succesive desfăşurate
pe diverse sisteme de calcul) şi respectiv în interpretarea
detaliată a codurilor de eroare posibile, precum în exemplul de
cod următor:
switch (Convert.ToUInt32(m["ConfigManagerErrorCode"]))
{
case 0:
aux = "Device is working properly.";
break;
case 1:
aux = "Device is not configured correctly.";
break;
case 2:
aux = "Windows cannot load the driver for this device.";
break;
…
Rezultatul a fost obţinerea de informaţii foarte detaliate

despre sistemul de calcul folosit pentru administrare, precum se
poate vedea în Figura 54.
287
Figura 54 – Utilitarul Informaţii despre sistem
5.2.3 Gestiunea bazelor de date
În MongoDB, conceptul de bază de date desemnează o

formă de grupare a colecţiilor de documente, cu un set
centralizat de utilizatori şi de drepturi de acces ale acestora.
Este de semnalat şi conceptul oarecum neobişnuit de
acces la o bază de date, în sensul că nu există o operaţie
specializată de creare a unei baze de date, orice bază de date
putând fi “deschisă” indiferent că ea există sau nu, urmând ca
prima operaţie efectuată asupra bazei de date (ex. crearea unei
288
colecţii sau a unui utilizator) să ducă şi la apariţia structurilor

fizice ce alcătuiesc baza de date. De asemenea, total contrar cu
ceea ce se întâmplă la majoritatea bazelor de date relaţionale
obişnuite (Oracle Database, IBM DB2, Microsoft SQL Server;
face excepţie Oracle MySQL), amprenta bazelor de date
MongoDB (dar şi a altor baze de date NoSQL) este extrem de
redusă (o bază de date “proaspătă”, fără conţinut, are o
amprentă de 32 Mo alcătuită din 2 fişiere; prin contrast o
schemă Oracle, în aceleaşi condiţii, are aproximativ 1Go).
Acesta este un alt motiv pentru care sistemul MongoDB a fost
considerat ca fiind potrivit ca ţintă pentru aplicaţia descrisă
aici.
Aplicaţia ASMDB conţine două opţiuni pentru
gestiunea bazelor de date şi anume crearea unei baze de date şi
respectiv ştergerea unei baze de date.
Crearea unei baze de date se realizează prin apelarea
opţiunii omonime din meniul “Baze de date”.
Esenţa operaţiei de creare a unei baze de date (care,
conform celor spuse mai sus, este realizată printr-un artificiu
tehnic) constă în faptul că noua bază de date este “deschisă”, se
execută în ea o operaţie oarecare – în cazul de faţă crearea unei
colecţii “fantoma”, operaţia respectivă este anulată – colecţia
“fantoma” este ştearsă, iar rezultatul este că bazei de date
dorite îi este creată structura fizică de fişiere corespunzătoare.
În ciuda faptului că aplicarea acestui mod de “creare” a bazei
de date nu ar avea efecte negative asupra unei baze de date deja
existente, se face totuşi o verificare a existenţei bazei de date
cu denumirea dorită, de aşa natură încât colecţia “fantomă” să
nu suprascrie o colecţie existentă cu aceeaşi denumire (caz
289
foarte puţin probabil, dar este mai bine să fie evitată

posibilitatea):
if (server.DatabaseExists(textBox1.Text))
{
MessageBox.Show("Baza de date cu numele \"" + textBox1.Text +
"\" deja există. Ea nu va fi suprascrisă", "Informare ...",
MessageBoxButtons.OK, MessageBoxIcon.Information);
textBox1.Text = "";
}
else
{
var database = server.GetDatabase(textBox1.Text);
database.CreateCollection("initializare db");
var colectie = database.GetCollection("initializare db");
colectie.Drop();
incarca_lista_db();
De asemenea, pentru o mai bună interactivitate cu
utilizatorul (de aşa natură încât acesta să fie informat ce
denumiri de baze de date sunt deja utilizate) în fereastra de
dialog este afişată o listă a bazelor de date deja existente care
este actualizată automat după fiecare operaţie de creare.
Componenta principală a acestei operaţii de afişare este
realizată de următoarea secvenţă de cod:
var database_list = server.GetDatabaseNames();
var database_list_enumerator = database_list.GetEnumerator();
database_list_enumerator.Reset();
while (database_list_enumerator.MoveNext())
{
listBox1.Items.Add(database_list_enumerator.Current);
}
Cazul în care denumirea sugerată pentru baza de date ar
fi una necorespunzătoare este tratat ca o excepţie de tip
“ArgumentOutOfRangeException”:
290
catch (ArgumentOutOfRangeException error4)

{
MessageBox.Show("Numele furnizat pentru baza de date nu este
utilizabil. Baza de date nu a fost creată.\r\nDescrierea erorii: " +
error4.Message, "Eroare ...", MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
Ştergerea unei baze de date se realizează prin apelarea
opţiunii omonime din meniul “Baze de date”.
Operaţia în sine este de data aceasta realizată de o
funcţie din MongDB API prin driver. Ca şi în cazul precedent,
se are în vedere ca utilizatorul să fie corect informat asupra
listei de baze de date care încă mai există după fiecare operaţie
de ştergere:
var database = server.GetDatabase(comboBox1.Text);
database.Drop();
incarca_combo();
Ca şi în cazul altor operaţii considerate ca având
potenţial dăunător, la ştergerea unei baze de date se verifică
opţiunea utilizatorului printr-un dialog suplimentar:
if (MessageBox.Show("Sunteţi sigur(ă) că doriţi să ştergeţi baza de
date?", "Verificare ...", MessageBoxButtons.YesNo,
MessageBoxIcon.Question) == DialogResult.Yes)
{
...
Este de menţionat şi faptul că, în vederea limitării
oricăror erori umane intervenite în utilizarea aplicaţiei,
conţinutul combo-boxurilor utilizate ca elemente de interfaţă
(atât aici cât şi la celelalte facilităţi similare din aplicaţie) este
limitat la conţinutul furnizat programatic
(comboBox1.DropDownStyle = ComboBoxStyle.
DropDownList şi similar pentru celelalte componente folosite).
291
5.2.4 Gestiunea utilizatorilor
O altă trăsătură a MongoDB neobişnuită în lumea

bazelor de date clasice este modul în care se face gestiunea
utilizatorilor (sau mai bine spus a autorizării accesului). Există
două moduri de lucru ale serverului: unul (implicit) în care nu
se face autentificare şi care este destinat mediilor de lucru
sigure şi un al doilea, care trebuie specificat explicit (fie cu
parametrul --auth pentru servere atomice, fie cu parametrul --
keyFile pentru servere cluster) în care se face autentificare la
nivel de bază de date. În acest al doilea caz, o bază de date
suplimentară cu denumirea admin este creată şi utilizatorii care
au drepturi de acces la această bază de date devin
administratori în sensul că au drepturi de acces prin extensie
asupra tuturor celorlalte baze de date. De asemenea, fiecare
dintre celelalte baze de date va avea propriul set de utilizatori.
Drepturile de acces sunt implementate relativ grosier în sensul
că singurele drepturi disponibile sunt de Read / Write şi
respectiv Read Only la nivelul unei întregi baze de date (dar
acest lucru nu trebuie să păcălească în sensul că bazele de date
din MongoDB nu reprezintă exact acelaşi lucru cu bazele de
date sau schemele din sistemele relaţionale).
Din motive legate de acest mod de organizare, existenţa
utilizatorilor nu este necesară atât timp cât serverul este pornit
în modul implicit de lucru.
Crearea unui utilizator al unei baze de date se realizează
prin apelarea opţiunii omonime din meniul “Utilizatori”.
292
Operaţia propriu-zisă de creare a unui utilizator este

realizată de o funcţie a MongoDB API, precum se vede în
următoarea secvenţă de cod:
MongoCredentials utilizator = new
MongoCredentials(textBox1.Text, textBox2.Text);
if (database.FindUser(textBox1.Text) == null)
{
database.AddUser(utilizator,radioButton1.Checked);
incarca_combo_user();
}
else
{
MessageBox.Show("Utilizatorul \""+textBox1.Text+"\" există
deja. Nu se poate adăuga utilizator la baza de date.", "Eroare ...",
MessageBoxButtons.OK, MessageBoxIcon.Error);
}
Se observă că la nivelul MongoDB API există o clasă
dedicată pentru credenţiale de acces, folosită în implementarea
aplicaţiei.
Ca şi în cazul celorlalte facilităţi ale aplicaţiei ASMDB
prezentate până acum, se încearcă uşurarea utilizării prin
prezentarea către utilizator a conturilor deja existente
(prevenind astfel crearea unui cont duplicat).
Aceeaşi funcţie de evitare a recreării nedorite a unui
cont (fapt care este posibil datorită modului de lucru din
MongoDB API şi care are ca efect suprascrierea parolei şi
respectiv a drepturilor de acces ale vechiului cont de utilizator)
este asigurată şi programatic (a se vedea secvenţa de cod de
mai sus).
293
Dialogul utilizat pentru crearea unui utilizator conţine

elementele obişnuite pentru un astfel de dialog (secretizarea
parolei prin ascundere cu un caracter neutru, dubla tastare a
acesteia pentru a preveni tastarea eronată). În sfârşit, se face şi
o verificare de validitate a parolei introduse, în cazul unei
probleme utilizatorul fiind înştiinţat şi operaţia de creare a
contului reluată.
Ştergerea unui utilizator al unei baze de date se
realizează prin apelarea opţiunii cu acelaşi nume din meniul
“Utilizatori”.
În fereastra de dialog corespunzătoare sunt furnizate
listele de utilizatori pentru fiecare bază de date în parte. O
posibilă viitoare extensie a aplicaţiei este adăugarea abilităţii de
ştergere batch a utilizatorilor.
Implementarea ştergerii utilizatorilor este mult
simplificată de existenţa metodelor corespunzătoare în
MongoDB API, în esenţă ea arătând precum în secvenţa de cod
următoare:
database.RemoveUser(comboBox2.Text);
Desigur, ca şi la majoritatea celorlalte operaţii executate
de aplicaţie, se face o verificare a intenţiei utilizatorului înainte
de execuţia propriu-zisă a ştergerii.
Schimbarea parolei unui utilizator al unei baze de date
se realizează prin apelarea opţiunii cu acelaşi nume din meniul
“Utilizatori”.
Potrivit modului ceva mai deosebit de lucru din
MongoDB API, care a mai fost comentat până acum în
paragrafele anterioare, schimbarea parolei unui utilizator nu se
294
face printr-o funcţie explicită, ci prin recrearea contului

respectiv. Din acest motiv, la schimbarea parolei trebuie avut
grijă şi să se restaureze programatic vechile drepturi de acces:
MongoCredentials utilizator = new
MongoCredentials(comboBox2.Text, textBox2.Text);
MongoUser control = database.FindUser(comboBox2.Text);
if (control != null)
{
bool drepturi_vechi = control.IsReadOnly;
database.AddUser(utilizator);
var restaurare = database.FindUser(comboBox2.Text);
restaurare.IsReadOnly = drepturi_vechi;
database.AddUser(restaurare);
}
else
{
MessageBox.Show("Utilizatorul " + comboBox2.Text + "nu există.
Nu se poate schimba parola sa.", "Eroare ...", MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
Dialogul utilizat pentru schimbarea parolei unui
utilizator conţine elementele obişnuite pentru un astfel de
dialog (secretizarea parolei prin ascundere cu un caracter
neutru, dubla tastare a acesteia pentru a preveni tastarea
eronată). În sfârşit, se face şi o verificare de validitate a parolei
introduse, în cazul unei probleme utilizatorul fiind înştiinţat şi
operaţia de schimbare a parolei reluată.
Vizualizarea şi schimbarea drepturilor de acces ale unui
utilizator al unei baze de date se realizează prin apelarea
opţiunii denumite corespunzător din meniul “Utilizatori”.
295
Implementarea se bazează pe un artificiu asemănător cu

cel de la schimbarea parolei unui utilizator, exceptând faptul că
nu mai există necesitatea de restaurare a unor atribute
anterioare (parola este salvată ca şi valoare hash în obiectele de
clasa MongoUser, spre deosebire de cazul anterior în care
obiectele de clasă MongoCredentials nu reţineau drepturile de
acces ale utilizatorului):
var utilizator=database.FindUser(comboBox2.Text);
utilizator.IsReadOnly = radioButton1.Checked;
database.AddUser(utilizator);
radioButton1.Checked = false;
radioButton2.Checked = false;
incarca_drepturi_user();
În fereastra de dialog de vizualizare şi schimbare a
drepturilor de acces sunt selectabile baza de date în care se
lucrează şi lista utilizatorilor pentru baza de date respectivă. La
selectarea unui anume utilizator, drepturile de acces ale
acestuia la baza de date respectivă sunt afişate automat.
5.2.5 Gestiunea colecţiilor
Conceptul de colecţie din MongoDB este vag

asemănător cu cel de tabel dintr-o bază de date relaţională
clasică. Probabil cele mai importante deosebiri sunt date de
faptul că nu se stabilesc legături între colecţii, de faptul că
analoagele înregistrărilor din bazele de date relaţionale clasice
şi anume documentele, pot avea structură diferită de la o
“înregistrare” la alta şi mai ales de faptul că un document poate
fi inclus în alt document şi acest lucru e posibil pe multiple
296
nivele (putem spune că avem de-a face cu documente

“imbricate” pe mai multe nivele).
Crearea unei colecţii în cadrul unei baze de date se
realizează prin apelarea opţiunii omonime din meniul
“Colecţii”.
Orice bază de date MongoDB, odată creată, conţine
implicit o colecţie de sistem denumită “system.indexes”. În
cazul în care în cadrul bazei de date respective sunt definiţi şi
utilizatori, apare o a doua colecţie de sistem denumită
“system.users”. În afară de aceste două colecţii, în fiecare bază
de date se vor mai regăsi şi colecţiile create de utilizator.
Operaţia propriu-zisă de creare a unei colecţii este
asigurată de metoda CreateCollection din clasa
MongoDatabase declarată în MongoDB API. Ca şi în cazul
altor operaţii din aplicaţie, se va evita recrearea colecţiei (chiar
dacă acest lucru este posibil în API):
if (database.CollectionExists(textBox1.Text))
{
MessageBox.Show("Colecţia \"" + textBox1.Text + "\" există deja.
Nu se poate adăuga colecţia la baza de date.", "Eroare ...",
}
else
{
database.CreateCollection(textBox1.Text);
incarca_combo_colectie();
textBox1.Text = "";
}
Facilitatea de vizualizare a conţinutului unei colecţii a
fost elementul cu al doilea grad de complexitate tehnică din
aplicaţia prezentată. Gradul ridicat de dificultate este dat de
297
faptul că spre deosebire de bazele de date relaţionale clasice,

“înregistrările” (documentele) din bazele de date MongoDB au
două caracteristici speciale: pot avea un număr variabil de
câmpuri de la o “înregistrare” la alta şi datele nu sunt stocate în
obişnuitele tipuri de date (int, string etc.), ci în variante ale
tipului BsonField, astfel încât pentru afişare în controalele
obişnuite din mediile de programare vizuale (textBox,
dataGridView etc.) sunt necesare suplimentar şi conversii de
tip (implicite de la BsonField către tipurile obişnuite, dar
explicite în sens invers). Suplimentar s-a optat şi pentru
asigurarea unei duble modalităţi de afişare: în stil “text”
(pentru conformitate cu conceptul de document) sau în stil
“tabel” (pentru creşterea uşurinţei în utilizare de către
utilizatorii obişnuiţi cu instrumentele de administrare de la
bazele de date relaţionale; această filosofie de lucru a fost
aplicată şi la operaţia de creare a unui document nou).
Pentru navigarea prin colecţie s-a optat pentru listarea
documentelor ca şi listă de identificatori (în arhitectura de baze
de date MongoDB orice document din orice colecţie conţine
cel puţin câmpul “_id” care reprezintă o valoare numerică de
tip ObjectId pe 24 de biţi şi care identifică unic fiecare
document, fără a se ţine cont de colecţia din care face parte –
practic fiecare document are o etichetă unică la nivelul întregii
baze de date).
Cele două moduri de vizualizare pot fi văzute în Figura
55, respectiv Figura 56.
298
Figura 55 – Form10 – vizualizarea unui document ca un aglomerat de

text
Figura 56 – Form10 – vizualizarea unui document în formă tabelară
299
Partea cea mai semnificativă a prelucrării implicate este

dată în următoarea secvenţă de cod:
var document =
colectie.FindOneById(ObjectId.Parse(listBox1.Text));
if (document != null)
{
dataGridView1.RowCount = 0;
for (int i = 1; i < document.Count(); i++)
{
textBox1.Text = textBox1.Text + document.GetElement(i).Name +
":\r\n" + document.GetElement(i).Value + "\r\n";
dataGridView1.RowCount++;
dataGridView1.Rows[i - 1].HeaderCell.Value =
document.GetElement(i).Name;
dataGridView1.Rows[i - 1].Cells[0].Value =
document.GetElement(i).Value;
}
dataGridView1.RowHeadersWidth = 80;
dataGridView1.Columns[0].Width = 350;
}
else
{
textBox1.Text = "Nu a fost găsit nici un document cu acest Id.";
}
O excepţie care a trebuit tratată a fost faptul că în cadrul
colecţiilor de sistem cîmpul “_id” nu are aceeaşi structură şi
lungime cu cel din colecţiile obişnuite. Din acest motiv
(precum şi din motive de securitate) vizualizarea conţinutului
unei colecţii este blocată pentru colecţiile de sistem:
if (listBox1.Text.Length == 24)
{
...
}
300
else
{
textBox1.Text = "Document de sistem. Conţinutul este ascuns";
}
Ştergerea unei colecţii din cadrul unei baze de date se
realizează prin apelarea opţiunii omonime din meniul
“Colecţii”.
Pentru această operaţie, implementarea este simplificată
de existenţa unei metode dedicate la nivelul MongoDB API:
if((comboBox2.Text!="system.indexes")&&(comboBox2.Text!="sy
stem.users"))
{
colectie.Drop();
}
else
{
MessageBox.Show("Colecţia pe care încercaţi să o ştergeţi este o
colecţie de sistem. Ea nu va fi ştearsă.", "Eroare ...",
}
Într-o versiune ulterioară a aplicaţiei se preconizează
adăugarea opţiunii de ştergere batch a colecţiilor, acum
colecţiile putând fi şterse numai una câte una.
Notă: Ca şi în alte cazuri, pentru evitarea ştergerii
accidentale, nu se permite utilizatorului ştergerea colecţiilor de
sistem.
5.2.6 Gestiunea documentelor
Documentele (“înregistrările”) din bazele de date

MongoDB sunt structurate sub formă de documente BSON.
301
BSON (Binary JSON) este o formă derivată a

documentelor JSON (JavaScript Object Notation) care sunt la
rândul lor specificate de un subset din Standard ECMA-262,
3rd Edition - December 199910.
Adăugarea unui document într-o colecţie din cadrul
unei baze de date se realizează prin apelarea opţiunii omonime
din meniul “Documente”.
Ca şi în cazul vizualizării documentelor din cadrul unei
colecţii, dificultăţile de implementare au provenit din două
surse: necesitatea de a proiecta o interfaţă care, conţinând
controale clasice, să fie capabilă să se adapteze la filosofia de
structură cu număr variabil de câmpuri a documentelor BSON
şi respectiv conversiile de tip necesare între tipurile “clasice”
(int, string etc.) şi tipurile definite de specificaţia BSON.
Controlul central al implementării a fost un
dataGridView cu două coloane (una pentru numele câmpului şi
una pentru conţinutul câmpului) şi cu număr dinamic de linii
(Figura 57). Conversia datelor s-a făcut în două etape, de la
string la BsonString şi apoi de la BsonString la BsonElement.
Au fost utilizate pentru implementare clase şi metode
deja existente în MongoDB API şi s-au făcut obişnuitele
verificări de securitate:
if((comboBox2.Text!="system.indexes")&&(comboBox2.Text!="s
ystem.users"))
{
BsonDocument document = new BsonDocument();
for(int i=0;i<dataGridView1.RowCount-1;i++)
{
10
***, Introducing JSON, JSON Org
302
var valoare =
BsonString.Create(dataGridView1.Rows[i].Cells[1].Value.ToString());
var element =
BsonElement.Create(dataGridView1.Rows[i].Cells[0].Value.ToString(),
valoare);
}
}
else
{
MessageBox.Show("Colecţia la care încercaţi să adăugaţi este o
colecţie de sistem. Documentul nu va fi inserat în colecţie.", "Eroare ...",
}
Figura 57 – Form11 – dialogul de adăugare a unui document cu o

structură simplă într-o colecţie
Ştergerea unui document dintr-o colecţie se realizează

prin apelarea opţiunii cu acelaşi nume din meniul
“Documente”.
303
Implementarea opţiunii de ştergere a unui document s-a

bazat pe metoda Remove din clasa MongoCollection, precum
se vede în următoarea secvenţă de cod:
if((comboBox2.Text!="system.indexes")&&(comboBox2.Text!="s
ystem.users"))
{
colectie.Remove(Query.EQ("_id",ObjectId.Parse(comboBox3.Text
)));
}
else
{
MessageBox.Show("Colecţia din care încercaţi să ştergeţi este o
colecţie de sistem. Ştergerea nu va fi efectuată.", "Eroare ...",
}
incarca_combo_documente();
Se poate remarca în secvenţa de cod de mai sus modul
în care se execută interogările pe baze de date MongoDB (clasa
Query cu metoda EQ fiind similară oarecum cu o interogare
SQL de forma SELECT … FROM … WHERE
camp=valoare).
Fereastra de dialog în care se realizează ştergerea
propriu-zisă permite selecţia documentului pe baza
identificatorului acestuia, lucru care se poate dovedi a fi
incomod în anumite situaţii. Din acest motiv, autorul îşi
propune ca, în viitoarea versiune a implementării, în această
fereastră de dialog să apară şi o componentă de previzualizare.
Alte îmbunătăţiri preconizate se referă la ştergerea batch a
documentelor (acum ştergerea putându-se face doar document
cu document).
304
5.2.7 Validarea soluţiei propuse
Aplicaţia de administrare ASMDB propusă presupune o

interacţiune complexă între SGBD-ul MongoDB, driver-ul
pentru C Sharp utilizat şi aplicaţia în sine. Ţinând cont de
faptul că fiecare dintre componentele enunţate ar fi putut duce
la apariţia de inconsistenţe sau erori de alte tipuri în tranzacţiile
de date, autorul a considerat că este necesară şi introducere
unei facilităţi de testare a validităţii operaţiilor. Această
facilitate se regăseşte în aplicaţie sub forma unei opţiuni în
submeniul “Validare”.
Această facilitate de validare are în vedere trei aspecte
principale: consistenţa datelor – se verifică faptul că sistemul
furnizează cel puţin consistenţă de nivel read-your-writes,
corectitudinea operaţiilor de scriere şi corectitudinea operaţiilor
de citire.
Implementarea testării constă în generarea aleatoare de
date cu stocarea acestora în memorie, scrierea lor sub formă de
chei în documente (câte un document separat pentru fiecare
cheie pentru a duce la obţinerea câte unei tranzacţii separate
pentru fiecare cheie) urmate de citirea cheilor din documente şi
compararea lor cu datele martor stocate în memorie. Numărul
de cicluri de scriere – citire – comparare este selectabil.
Eventualele erori sau inconsistenţe apărute sunt contorizate, iar
diferenţele sunt afişate într-un control de tip text.
Secvenţa semnificativă din codul sursă utilizat este
următoarea:
for (contor = 1; contor <= nr_op; contor++)
{
sir1 = "";
305
for (int j = 0; j < 10; j++)

{
string bucata = Path.GetRandomFileName();
bucata = bucata.Substring(0, 10);
sir1 = sir1 + bucata;
}
BsonDocument document = new BsonDocument();
var element = BsonElement.Create("sir",
BsonString.Create(sir1));
var cursor = colectie.FindAll();
document = cursor.Last();
sir2 = document.GetElement(1).Value.ToString();
if (sir1 != sir2)
{
nr_err++;
textBox3.Text = textBox3.Text + sir1 + " <> " + sir2 + "\r\n";
textBox2.Text = nr_err.ToString();
}
textBox1.Text = contor.ToString();
textBox2.Text = nr_err.ToString();
}
Pe parcursul testelor extensive efectuate nu au apărut
erori sau inconsistenţe indiferent de numărul de cicluri
efectuate, astfel încât se poate trage concluzia că ansamblul
alcătuit din SGBD-ul MongoDB şi aplicaţia de administrare
ASMDB propusă oferă cel puţin consistenţă de nivel “read-
your-writes”.
306
5.2.8 Ajutor şi informaţii de copyright
Aplicaţia ASMDB conţine şi facilităţi de ajutor şi alte

informaţii despre aplicaţie, dar acestea sunt implementate într-o
formă incipientă. În măsura în care această aplicaţie va trece la
stadiul de aplicaţie comercială, facilităţi dedicate de help vor fi
adăugate. Pentru moment, autorul consideră că interfaţa cu
utilizatorul este suficient de intuitivă încât să nu pună probleme
de asimilare (aceste consideraţii sunt de altfel confirmate de
testele efectuate de către un grup ţintă restrâns format din cadre
didactice cu preocupări în domeniu).
Singurul element concret de informare care a fost
implementat este un dialog de informare asupra autorului şi
versiunii aplicaţiei.
5.3 Analiza stadiului la care a ajuns aplicaţia

ASMDB (concluzii parţiale)
După cele expuse în capitolul cinci, se poate observa că

în acest moment aplicaţia implementată este completă în sensul
că ea conţine toate facilităţile dintr-un set minimal cerut pentru
administrarea unei baze de date. Au fost de asemenea efectuate
asupra ei testări intensive de către mai multe persoane având
experienţă în domeniul administrării bazelor de date şi
rezultatele au fost mai mult decât mulţumitoare (trei bug-uri
descoperite şi depanate, apreciere unanim pozitivă asupra
aspectului şi funcţionalităţii aplicaţiei).
Se poate concluziona că, în forma actuală, aplicaţia
îndeplineşte cu succes cerinţele pentru o utilizare în situaţii
307
concrete de administrare a unor volume mari de date stocate

prin intermediul unui server NoSQL (MongoDB).
Pentru versiunile viitoare ale acestei aplicaţii autorul are
în vedere implementarea următoarelor îmbunătăţiri şi adăugări:
 Implementarea unor facilităţi de import / export al
datelor (într-o primă etapă din formate mai facile,
precum xml, csv, txt, xls, mdb, acdb, iar într-o etapă
ulterioară din baze de date comerciale prin
intermediul unor conectori ODBC sau prin alte
mecanisme);
 Implementarea unor facilităţi de întreţinere a
bazelor de date (refacerea indecşilor, reconstituirea /
repararea / redimensionarea spaţiilor de nume);
 Parametrizarea operaţiilor de lucru cu servere
(pornire / oprire a unui server) de aşa natură încât să
se poată efectua operaţii din gama:
o pornirea unui server remote;
o oprirea unui server remote;
o pornirea unei componente a unui sistem
cluster;
o configurarea şi iniţializarea unui sistem
cluster, incluzând parametrizarea acestuia
(mod de replicare şi de sharding);
o control detaliat asupra modului în care un
server este iniţializat (cu / fără autentificare,
cu / fără jurnalizare, cu / fără sincronizare
forţată în cluster, control asupra dimensiunii
pool-ului de conexiuni, control asupra
timpului de viaţă al conexiunii etc.);
308
 Implementarea abilităţii de a efectua back-up-uri şi

restaurări asupra unei baze de date sau asupra unor
colecţii din aceasta;
 Localizarea aplicaţiei în limba engleză şi
introducerea abilităţii de localizare într-o terţă
limbă;
 Adăugarea următoarelor elemente la
funcţionalităţile existente:
o ştergere batch a bazelor de date;
o ştergere batch a colecţiilor;
o modificare batch a drepturilor de acces ale
utilizatorilor;
o ştergere batch a documentelor;
o dezvoltarea componentei de vizualizare de
componente cu noi facilităţi;
o dezvoltarea componentei de adăugare de
documente cu noi facilităţi;
 Implementarea unor facilităţi de monitorizare
dincolo de simpla observare a stării serverului (aşa
cum este implementată acum).
309
Concluzii
Pentru fiecare epocă din istoria ştiinţei calculatoarelor a
existat un nivel de cantitate de date dincolo de care prelucrarea,
stocarea sau transferul acestora devenea dificil pentru
tehnologia epocii respective, iar datele care depăşeau această
limită erau numite volume mari de date (pentru majoritatea
epocilor precedente, regula fiind că aceste volume mari de date
erau produse fie de aplicaţii militare, fie de aplicaţii ştiinţifice).
Epoca actuală diferă fundamental de această situaţie
recurent întâlnită în istoria informaticii, pentru că este prima
epocă în care există un număr mare de surse capabile să
genereze cu uşurinţă volume mari de date. Este de asemenea
epoca în care generarea de volume mari de date nu mai este
apanajul aplicaţiilor militare sau ştiinţifice.
Dată fiind abundenţa de surse de volume mari de date,
este evident faptul că studiul modului în care aceste date pot fi
prelucrate şi stocate reprezintă un domeniu de mari interes şi
actualitate.
Lucrarea cu titlul „Călătorie prin lumea Big Data” a
realizat o analiză a punctelor din studiul acestui domeniu care
reprezintă la momentul actual probleme nerezolvate sau în care
pot fi aduse îmbunătăţiri. În câteva din aceste puncte autorul a
prezentat unele propuneri de soluţii, de îmbunătăţiri sau numai
de aspecte care ar putea fi studiate.
În primul capitol al lucrării au fost abordate două
aspecte referitoare la modalităţile de structurare a volumelor
mari de date şi anume organizarea structurată (bazele de date
relaţionale) şi organizarea semistructurată (bazele de date
NoSQL).
În ceea ce priveşte organizarea structurată a volumelor
mari de date, au fost prezentate în subcapitolul 1.1, soluţiile
311
oferite de cei mai mari competitori din domeniul bazelor de

date relaţionale (Oracle, IBM, Microsoft).
Subcapitolul 1.2 a fost dedicat bazelor de date NoSQL,
fiind descrise conceptul de bază de date NoSQL şi câteva
aplicaţii considerate de către autor a fi semnificative în acest
domeniu: Facebook Cassandra, Amazon Dynamo şi Amazon
S3, Apache CouchDB şi Apache Hadoop.
O parte importantă a capitolului 1 a fost reprezentată de
realizarea de către autor a unei clasificări a produselor NoSQL,
astfel încât să se poată determina care dintre ele îndeplinesc
scopuri similare sau au calităţi sau facilităţi similare.
Analiza efectuată în capitolul 1 asupra modalităţilor de
structurare a volumelor mari de date a condus la alegerea de
către autor a soluţiei oferite de bazele de date NoSQL. Pentru
acest tip de date semistructurate, autorul a proiectat şi
implementat o aplicaţie de interfaţă pentru organizarea şi
prelucrarea datelor, prezentată în capitolul 0.
În capitolul 1 al cărții au fost abordate soluţiile de
prelucrare a volumelor mari de date organizate structurat
(depozite de date). În ceea ce priveşte suportul fizic pentru
prelucrarea datelor, au fost prezentate două aspecte: prelucrarea
utilizând sisteme de calcul de înaltă performanţă şi prelucrarea
distribuită (sisteme cluster, sisteme grid şi sisteme cloud).
De asemenea, au fost abordate mijloace alternative de
creştere a perfomanţei de prelucrare, şi anume metodele
cunoscute sub numele generic de Prelucrări de Tip General
utilizând Unităţi de Procesare Grafică (General-Purpose
computing on Graphics Processing Units – GPGPU, GPGP sau
GP²U).
312
Performanţa de prelucrare a datelor a fost analizată

având în vedere cele două modalităţi de structurare: date
structurate şi date semistructurate.
Deşi bazele de date relaţionale şi NoSQL au unele
trăsături şi funcţionalităţi comune, comportamentul lor nu este
similar în diverse cazuri de utilizare. Acest lucru sugerează că
ele nu pot fi interschimbate pentru rezolvarea oricărei probleme
şi că, pentru fiecare tip de problemă în parte, ar trebui ales acel
tip de bază de date care se potriveşte mai bine situaţiei.
Capitolul 3 duce la concluzia ca, la adoptarea în
intreprinderi a bazelor de date NoSQL, cea mai mare provocare
este schimbarea cadrului mental al persoanelor de decizie –
convingerea lor că nu toate datele / obiectele se potrivesc cu
modelarea relaţională. Cea mai bună metodă pentru a realiza
acest lucru este testarea unei soluţii NoSQL pentru tipul
potrivit de cazuri de utilizare, demonstrând modul în care
aplicaţiile bazate pe NoSQL pot fi soluţii mai eficiente decât
cele relaţionale, dacă sunt utilizate în contextul potrivit. Ajută
de asemenea identificarea câtorva proiecte (nu neapărat critice
pentru intreprindere, dar care au mai ales o bună vizibilitate)
pentru care implementări ne-relaţionale s-ar potrivi. Succesul
(sau chiar eşecul) unui astfel de proiect ajută la schimbarea
cadrului mental. Un astfel de proiect ar ajuta de asemenea la
învăţarea a ceea ce este necesar să fie făcut diferit pentru a
implementa mai bine soluţii NoSQL. Această politică a paşilor
mărunţi este vitală dacă intreprinderea vrea să îşi remodeleze
mecanismele de managementul informaţiei în viitorul apropiat
pentru adoptarea de soluţii ne-relaţionale.
313
Pe lângă regulile de bună practică formulate şi

informaţiile obţinute prin analize comparative, pe parcursul
capitolului 3 s-a făcut şi selectarea produsului ţintă pentru
aplicația software prezentată în capitolul 5. Se poate observa
prin parcurgerea capitolului 3 că produsul MongoDB, pe lângă
faptul că a fost selectat între cele patru produse ce îndeplinesc
condiţiile minimale pentru utilizarea într-o intreprindere,
îndeplineşte şi câteva condiţii suplimentare. Din acest motiv,
aplicaţia care este descrisă în capitolul 0, dar şi cercetările care
vor fi continuate ulterior au ca ţintă produsul MongoDB, un
produs open source realizat şi suportat de 10gen.
Subcapitolul 4.1 a conţinut o descriere extensivă a
modului în care ar trebui organizată o aplicaţie modernă de
prelucrare a volumelor mari date. Se poate trage concluzia ca
generaţia următoare de astfel de soluţii va fi atât continuatoarea
depozitelor de date actuale cât şi a soluţiilor strict non-
relaţionale disponibile în acest moment şi ca la o astfel de
soluţie îşi vor aduce aportul şi alte tehnologii de ultimă oră
precum soluţiile de virtualizare a prelucrării datelor, algoritmii
de prelucrare semantică, procesare lexicală sau diverse metode
de extragere, explorare şi vizualizare a informaţiei.
Cel de-al doilea subcapitol din capitolul 1 a descris
modul în care se poate face măsurarea performanţelor de care
este capabilă infrastructura unui sistem de prelucrare a
volumelor mari de date.
Capitolul 0 a descris modul în care autorul a proiectat şi
realizat o aplicaţie de interfaţă cu ajutorul căreia se poate face
organizarea datelor semistructurate utilizând un sistem de
gestiune a bazelor de date NoSQL.
314
Referințe bibliografice
Abouzeid, A., Bajda-Pawlikowski, K., Abadi, D. J., Rasin, A.,

& Silberschatz, A. (2009). HadoopDB: An
Architectural Hybrid of MapReduce and DBMS
Technologies for Analytical Workloads. The
proceedings of VLDB.
Abramson, I. (2004). Large Database Features In Oracle. In I.
Abramson, Oracle Database 10g A Beginner's Guide.
McGraw-Hill/Osborne.
Advanced Micro Devices. (2013). AMD FirePro™ 3D
Professional Graphics. AMD.com.
Akella, J., Kubach, T., Löffler, M., & Schmid, U. (2011). Data-
driven management: Bringing more science into
management. McKinsey Technology Initiative white
paper.
Amin, R., & Arefin, T. (2010). The Empirical Study on the
Factors Affecting Data . International Journal of Latest
Trends in Computing.
Anthes, G. (2010). Security in the cloud. Communications of
the ACM.
Asanovic, K., Bodik, R., Demmel, J., Keaveny, T., Keutzer, K.,
Kubiatowicz, J., . . . Yelick, K. (2009). A view of the
parallel computing landscape. Commun. ACM.
AWS. (2008). The Emerging Cloud Service Architecture.
Aws.typepad.com.
Barroso, L. A., & Holzle, U. (2009). The Datacenter As A
Computer: An Introduction To The Design Of
Warehouse-Scale Machines. Morgan & Claypool
Publishers.
315
Baru, C., Bhandarkar, M., Nambiar, R., Poess, M., & Rabl, T.
(2013). Benchmarking Big Data Systems and the
BigData Top100 List. Big Data.
Benson, T., Akella, A., & Maltz, D. A. (2010). Network Traffic
Characteristics Of Data Centers In The Wild. The
proceedings of IMC.
Bertolucci, J. (2014). Real-Time Acoustic Processing Has Big
Data Potential. InformationWeek.
Bhatewara, A., & Waghmare, K. (2012). Improving Network
Scalability Using NoSql Database. Journal of Advanced
Computer Research.
Bhatotia, P., Wieder, A., Rodrigues, R., Acar, U. A., &
Pasquin, R. (2011). Incoop: MapReduce For
Incremental Computations. The Proceedings of SOCC.
Bizer, C., Boncz, P., Brodie, M. L., & Erling, O. (2011). The
meaningful use of big data: four perspectives - four
challenges. ACM SIGMOD Record.
Bollier, D. (2010). The Promise and Peril of Big Data. The
Aspen Institute.
Bonnet, L., Laurent, A., Sala, M., Laurent, B., & Sicard, N.
(2011). Reduce, You Say: What NoSQL Can Do for
Data Aggregation and BI in Large Repositories. The
Proceedings of the 22nd International Workshop on
Database and Expert Systems Applications (DEXA),.
Toulouse.
Borthakur, D., Gray, J., Sarma, J. S., Muthukkaruppan, K.,
Spiegelberg, N., Kuang, H., . . . Aiyer, A. (2011).
Apache Hadoop Goes Realtime At Facebook. The
proceedings of SIGMOD.
Boyd, D., & Crawford, K. (2011). Six Provocations for Big
Data. A Decade in Internet Time: Symposium on the
Dynamics of the Internet and Society.
Boyd, D., & Crawford, K. (2012). Critical Questions For Big
Data. Information, Communication & Society - Special
316
Issue: A decade in Internet time: the dynamics of the

Internet and society.
Brandom, R. (2014). Google’s quantum computer just flunked
its first big test. The Verge.
Browne, J. (2010). Brewer's CAP Theorem. Julian Browne
personal blog.
Bucur, C., & Tudorică, B. (2011). Solutions for working with
large data volumes in web applications. The
Proceedings of the IE 2011 "Education, Research &
Business Technologies" International Conference.
Bucur, C., & Tudorică, B. (2012). A Research on Retrieving
and Parsing of Multiple Web Pages for Storing Them in
Large Databases. The Proceedings of the 19th
International Economic Conference - IECS 2012, The
Persistence of the Economic Crises: Causes,
Implications, Solutions.
Burtica, R., Mocanu, E. M., Andreica, M. I., & Tapus, N.
(2012). Practical application and evaluation of NoSQL
databases in Cloud Computing. The Proceedings of
International Systems Conference (SysCon). IEEE.
Buyya, R., Yeo, C. S., & Venugopal, S. (2008). Market-
Oriented Cloud Computing: Vision, Hype, and Reality
for Delivering IT Services as Computing Utilities.
Department of Computer Science and Software
Engineering, University of Melbourne, Australia.
Campbell, C. (2014). Data Warehouse Appliances...They're not
for Cooking Breakfast! Blue Granite.
Chang, F. (2008). Bigtable: A Distributed Storage System for
Structured Data. Google.com.
Chaudhuri, S. (2012). What next?: a half-dozen data
management research goals for big data and the cloud.
PODS '12 Proceedings of the 31st symposium on
Principles of Database Systems. ACM.
317
Cooper, B. F., Silberstein, A., Tam, E., Ramakrishnan, R., &

Sears, R. (2010). Yahoo! cloud serving benchmark.
ACM Symposium on Cloud Computing. ACM.
Cuvelier, M. I. (2013). Why data warehousing projects fail.
Search Oracle: Tech Target.
Cuzzocrea, A., Song, I.-Y., & Davis, K. C. (2011). Analytics
over large-scale multidimensional data: the big data
revolution! DOLAP '11 Proceedings of the ACM 14th
international workshop on Data Warehousing and
OLAP. New York: ACM.
De Sterck, H., & Zhang, C. (2010). Supporting multi-row
distributed transactions with global snapshot isolation
using bare-bones Hbase. The 11th ACM/IEEE
International Conference on Grid Computing (Grid
2010). Brussels.
Dell Corporation. (2013). Toad for Cloud Databases. Dell
Software.
Derrick, H. (2014). Why video is the next big thing in big data.
GigaOm.
Dine, S. (2011). Why BI Projects Fail. B-Eye Network.
Duffy, J. (2009). Cisco unveils cloud computing platform for
service providers. Infoworld.
Edlich, S. (2013). NoSQL, your ultimate guide to the non -
relational universe! NoSQL.org.
Eric Kraemer, M. B. (2014). Fast Track Data Warehouse
Reference Guide for SQL Server 2012. Micorsoft.com.
Fang, C. (. (2013). Large-Scale Video Analytics on Hadoop.
Pivotal.
Farber, D. (2008). The new geek chic: Data centers. CNET
News.
Ferguson, M. (2012). Architecting A Big Data Platform for .
IBM.com.
Fox, A., & Brewer, E. A. (1999). Harvest, Yield, and Scalable
Tolerant Systems. CiteSeerX.
318
Fox, A., Gribble, S. D., Chawathe, Y., Brewer, E. A., &

Gauthier, P. (1997). Cluster-Based Scalable Network
Services. CiteSeerX.
Gens, F. (2008). Defining "Cloud Services" and "Cloud
Computing". IDC.
Gilbert, S., & Nancy, L. (2002). Brewer's Conjecture and the
Feasibility of Consistent, Available, Partition-Tolerant
Web Services. CiteSeerX.
Goddeke, D., Strzodka, R., & Turek, S. (2005). Accelerating
Double Precision (FEM) Simulations with (GPUs).
Proceedings of ASIM 2005 – 18th Symposium on
Simulation Technique.
Goodin, D. (2011). Network hack launched from Amazon EC2.
The Register.
Graefe, G. (1993). Query evaluation techniques for large
databases . ACM Computing Surveys (CSUR).
Grinev, M. (2010). A Quick Introduction to the Cassandra
Data Model. Maxim Grinev personal blog.
Hamilton, J. (2009). One size does not fit all.
Perspectives.Mvdirona.com.
Harris, M. (2005). Mapping computational concepts to GPUs.
ACM SIGGRAPH 2005 Courses. ACM.
Harris, M., & Buck, I. (2010). GPU Gems 2, Chapter 34.
Nvidia.com.
Helbing, T. (2010). How the New EU Rules on Data Export
Affect Companies in and Outside the EU. Dr. Thomas
Helbing – Kanzlei für Datenschutz-, Online- und IT-
Recht.
Henschen, D. (2014). 16 Top Big Data Analytics Platforms.
InformationWeek.
Hope, M. (2006). Lessons Learned from Large Databases.
Network World Inc.
Howard, A. B. (2009). FISMA compliance for federal cloud
computing on the horizon in 2010. SearchCompliance.
319
IBM. (2009). IBM DB2 UDB Administration Guide: Planning.

IBM.com.
IBM. (2012). DB2 Version 9.7 for Linux, UNIX, and Windows,
Distributed Relational Database Architecture.
IBM.com.
Imhoff, C., & White, C. (2008). Full Circle: Decision
Intelligence (DSS 2.0). B-eye Network.
Inmon, W. H. (2002). Building the Data Warehouse. Wiley.
Inmon, W. H. (2006). DW 2.0 - Architecture for the Next
Generation of Data Warehousing. Information
Management.
Inmon, W. H., Strauss, D., & Neushloss, G. (2010). DW 2.0:
The Architecture for the Next Generation of Data
Warehousing. Morgan Kaufmann.
Ivan, I., & Ciurea, C. (2009). Using Very Large Volume Data
Sets for Collaborative Systems Study. Informatică
Economică.
Jacobs, A. (2009). The pathologies of big data.
Communications of the ACM - A Blind Person's
Interaction with Technology.
Karger, D. L., Leighton, T., Panigrahy, R., Levine, M., &
Lewin, D. (1997). Consistent hashing and random trees:
distributed caching protocols for relieving hot spots on
the World Wide Web. Proceedings of the Twenty-Ninth
Annual ACM Symposium on theory of Computing . New
York: ACM Press.
Kellerman, J. (2009). HBase: structured storage of sparse data
for Hadoop. RapLeaf.com.
Kimball, R., & Ross, M. (2002). The Data Warehouse Toolkit:
The Complete Guide to Dimensional Modeling. Wiley.
King, R. (2008). Cloud Computing: Small Companies Take
Flight. Businessweek.
Kobielus, J. (2008). Teradata Goes Appliance, Officially.
Forrester.com.
320
Krishnan, K. (2013). Data Warehousing in the Age of Big

Data. Waltham: Morgan Kaufmann.
Labrinidis, A., & Jagadish, H. V. (2012). and opportunities
with big data. the Proceedings of the VLDB
Endowment.
Lakshman, A., & Malik, P. (2009). Cassandra, Structured
storage system over a P2P network. LADIS.
Lakshman, A., & Malik, P. (2010). Cassandra, a decentralized
structured storage system. Cornell University.
Lamport, L. (1978). Time, clocks, and the ordering of events in
a distributed system. ACM Communications.
Lane, J. (2014). Big Data Is Smart Data For Online Audio.
Audio4Cast.
Liu, Y., Wang, Y., & Jin, Y. (2012). Research on the
improvement of MongoDB Auto-Sharding in cloud
environment. The Proceedings of the 7th International
Conference on Computer Science & Education
(ICCSE).
Lungu, I., Velicanu, M., & Botha, I. (2009). Database Systems
– Present and Future. Informatică Economică.
Madsen, M. (2005). A 50% Data Warehouse Failure Rate is
Nothing New. IT Toolbox.
Malinowski, E., & Zimányi, E. (2008). Advanced Data
Warehouse Design. Berlin, Heidelberg: Springer.
Mazumder, S. (2010). NoSQL in the Enterprise. InfoQ.com.
Mell, P., & Grance, T. (2009). The NIST definition of cloud
computing, version 15. NIST.
Messmer, E. (2009). Are security issues delaying adoption of
cloud computing? Network World.
Microsoft. (2013). Windows Azure, Unlimited Possibilities.
Microsoft.com.
Microsoft. (2014). Microsoft Analytics Platform.
Microsoft.com.
321
Mircea, M., & Andreescu, A. (2011). Using Cloud Computing

in Higher Education: A Strategy to Improve Agility in
the Current Financial Crisis. Communications of the
IBIMA, (p. 14).
Monash Research. (2008). Database machines and data
warehouse appliances – the early days. Software
Memories.
MongoDB Inc. (2013). CSharp Driver LINQ Tutorial.
MongoDB wiki.
MongoDB Inc. (2013). CSharp Language Center. MongoDB
Wiki.
MongoDB Inc. (2013). Replication. MongoDB wiki.
Myerson, J. (2009). Cloud computing versus grid computing.
IBM.com.
Myslewski, R. (2009). Intel puts cloud on single megachip. The
Register.
National Institute of Standards and Technology. (2013).
Computer Security Division – Computer Security
Resource Center. NIST.gov.
Nettleton, D. (2014). Commercial Data Mining - Processing,
Analysis and Modeling for Predictive Analytics
Projects. Morgan Kaufmann, Elsevier.
Nicholson, I. (2013). Data Warehousing: Lessons We Have
Failed to Learn. Smart Data Collective.
O'Grady, S. (2009). AGPL: Open Source Licensing in a
Networked Age. Redmonk.com.
Okman, L., Gal-Oz, N., Gonen, Y., Gudes, E., & Abramov, J.
(2011). Security Issues in NoSQL Databases. 10th
International Conference on Trust, Security and
Privacy in Computing and Communications
(TrustCom). IEEE.
Open Cloud Consortium. (1999). Open Cloud Consortium.
Open Cloud Consortium.
322
Owens, J. D., Luebke, D., Govindaraju, N., Harris, M., Krüger,

J., Lefohn, A. E., & Purcell, T. (2007). A Survey of
General-Purpose Computation on Graphics Hardware.
Computer Graphics Forum.
Owens, J., Davis, U. C., & Luebke, D. (2013). 5, Learn more
… / Intro to Parallel Programming. NVIDIA.com.
Parhami, B. (1999). Introduction To Parallel Processing:
Algorithms And Architectures. Kluwer Academic
Publishers.
Pariseau, B. (2008). EMC buys Pi and forms a cloud
computing group. Searchstorage.techtarget.com.
Peters, M. (2010). How to install Cassandra + Thrift (and why
you should care). SoftwareProjects.com.
Poulovassilis, A. (2013). Database Research Challenges and
Opportunities of Big Graph Data. Notes in Computer
Science .
Predictive Analytics Today. (2014). Top 11 free software for
text analysis, text mining, text analytics. Predictive
Analytics Today.
Predictive Analytics Today. (2014). Top 30 free statistical
software. Predictive Analytics Today.
Predictive Analytics Today. (2014). Top 30 software for text
analysis, text mining, text analytics. Predictive
Analytics Today.
Qureshi, A., Weber, R., Balakrishnan, H., Guttag, J. V., &
Maggs, B. V. (2009). Cutting the Electric Bill for
Internet-scale Systems. The proceedings of SIGCOMM.
Raab, F., Kohler, W., & Shah, A. (2013). Overview of the TPC
Benchmark C: The Order-Entry Benchmark.
Transaction Processing Performance Council.
Rackspace. (2009). Cloud Hosting is Secure for Take-off:
Mosso Enables The Spreadsheet Store, an Online
Merchant, to become PCI Compliant. Rackspace.
323
Schindler, J. (2012). I/O characteristics of NoSQL databases.

Proceedings of the VLDB Endowment.
Storage Networking Industry Association. (n.d.). Managing
Private and Hybrid Clouds for Data Storage. 2010:
Storage Networking Industry Association report.
Suleman, A. (2011). Tutorial on removing branches.
FutureChips.org.
Tauro, A. (2013). ETL vs. ELT: What’s the Difference?
Performance Architects.
Tauro, C. J., Aravindh, S., & Shreeharsha, A. B. (2012).
Comparative Study of the New Generation, Agile,
Scalable, High Performance NOSQL Databases.
International Journal of Computer Applications.
Technology Bussiness Research. (2014). Data Warehouse
Appliances: The next wave of IT Delivery. EMC.com.
The Economist. (2009). Cloud Computing: Clash of the clouds.
The Economist.
The Economist. (2010). Data, data everywhere. The Economist.
ThePicky. (2009). Difference : Cloud Computing vs Grid
Computing. ThePicky.com.
Transaction Processing Performance Council. (2013). TPC
Benchmarktm H, (Decision Support), Standard
Specification, Revision 2.14.2.
Transaction Processing Performance Council. (2013). TPC-C -
All Results - Sorted by Performance Version 5 Results.
Transaction Processing Performance Council. (2013). TPC-H -
Top Ten Performance Results Version 2 Results.
Tudorică, B. (2010). Tools for data conversion/Migration and
problems solved by such tools - Taxonomy and small
case studies . The Proceedings of The 2nd International
Conference on Operational Research ICOR 2010.
Tudorică, B. (2013). A new application for the management of
the MongoDB servers. The International Journal of
Sustainable Economies Management (IJSEM).
324
Tudorică, B. (2013). Challenges for the NoSQL systems:

Directions for Further Research and Development. The
International Journal of Sustainable Economies
Management (IJSEM).
Tudorică, B., & Bucur, C. (2011). A comparison between
several NoSQL databases with comments and notes.
The proceedings of „2011 - Networking in Education
and Research”. IEEE.
Urquhart, J. (2010). Cloud computing's green paradox. CNET
News.
VagueWare. (2014). Data Mining Software: 10 Best Tools To
Optimize Your Business Profits. VagueWare.
Venter, F., & Stein, A. (2012). Sizing up the potential impact
of prescriptive analytics driven by proliferation of
images and video. Analytics Magazine.
Wagner, J. (2014). Two great social data platforms: how
Ddatasift and Ggnip stack up. Programmable Web.
Wei, Z., Pierre, G., & Chi, C.-H. (2011). CloudTPS: scalable
transactions for web applications in the cloud.
Technical report IR-CS-53, Transactions on Services
Computing, IEEE.
Wheeland, M. (2010). Swiss Carbon-Neutral Servers Hit the
Cloud. GreenBiz.
Woodie, A. (2013). Hadoop and NoSQL Now Data
Warehouse-Worthy: Gartner. Datanami.com.
Wrembel, R., & Koncilia, C. (2007). Data Warehouses and
OLAP: Concepts, Architectures and Solutions. London:
IRM Press.
Xu, J. Y. (2010). The open standard for parallel programming
of heterogeneous systems. Khronos Group.
Zissis, D., & Lekkas. (2012). Addressing cloud computing
security issues. Future Generation Computer Systems.
325
Lista figurilor și a tabelelor

Lista figurilor
Figura 1 – Arhitectura Oracle Real Application Clusters ....... 26

Figura 2 – Vedere de ansamblu asupra Oracle Clusterware ... 28
Figura 3 – Comunicaţia de date între staţia de lucru DB2
Connect şi serverul IBM ......................................................... 35
Figura 4 – Utilizarea unei singure baze de date într-o
tranzacţie. ................................................................................ 37
Figura 5 – O configuraţie minimală a MySQL Cluster .......... 43
Figura 6 – O configuraţie extinsă MySQL Cluster ................. 44
Figura 7 – Structura familiei de coloane Tweets .................... 51
Figura 8 - Un model abstract al arhitecturii platformei Amazon
................................................................................................. 54
Figura 9 – Creşterea de performanţă dată de creşterea
numărului de CPU, depinzând de procentul din prelucrare care
este paralelizabil ...................................................................... 66
Figura 10 – Graficul distribuţiei familiilor de sisteme de
operare instalate pe supercalculatoarele din Top500 .............. 70
Figura 11 – Arhitecturile utilizate la diverse momente de timp
pentru obţinerea de performanţe computaţionale crescute la
sistemele din Top500 .............................................................. 84
Figura 12 – Model generic al unui sistem cloud ................... 103
Figura 13 – Prezenţa pe piaţă a diverselor soluţii comerciale de
tip depozit de date (februarie 2016) ...................................... 120
Figura 14 – Infrastructura unui depozit de date .................... 125
Figura 15 – Arhitectura „fabrică de informaţie” ................... 131
Figura 16 – Arhitectura BUS ................................................ 133
Figura 17 – Arhitectura DW 2.0 (partea a doua) .................. 139
Figura 18 – Arhitectura DSS 2.0 ........................................... 141
Figura 19 – Nivelul preferinţelor clienţilor pentru diversele
categorii de soluţii la cheie.................................................... 147
327
Figura 20 – Avantajele utilizării soluţiilor la cheie pentru

depozite de date ..................................................................... 147
Figura 21 – Latenţa la citire într-un mediu OLTP (Cooper,
Silberstein, Tam, Ramakrishnan, & Sears, 2010) ................. 166
Figura 22 – Latenţa la scriere într-un mediu OLTP (Cooper,
Figura 23 – Latenţa la citire într-un mediu OLAP (Cooper,
Figura 24 – Latenţa la scriere într-un mediu OLAP (Cooper,
Figura 25 – Interfeţe disponibile ........................................... 174
Figura 26 – Modele logice ale datelor .................................. 174
Figura 27 – Modele de distribuţie a datelor .......................... 175
Figura 28 – Tipuri de persistenţă a datelor ........................... 175
Figura 29 – Modele nou apărute în Managementul informaţiei
............................................................................................... 177
Figura 30 – Beneficii cheie derivate din caracteristicile de bază
ale sistemelor NoSQL ........................................................... 181
Figura 31 – Provocări la adresa intreprinderilor care doresc să
adopte soluţii NoSQL............................................................ 185
Figura 32 – Elemente necesar a fi obţinute pentru adoptarea cu
succes a utilizării unui sistem NoSQL într-o aplicaţie de
intreprindere .......................................................................... 192
Figura 33 – Structura generică a unei soluţii de prelucrare a
volumelor mari de date din generaţia următoare .................. 205
Figura 34 – Succesiunea etapelor de prelucrare a datelor de tip
Big Data ................................................................................ 210
Figura 35 – Procesarea datelor de intrare.............................. 214
Figura 36 – Categorii de sarcini de lucru .............................. 217
Figura 37 – Integrarea datelor externe .................................. 224
Figura 38 – Abordare bazată pe integrarea bazelor de date
NoSQL şi a celor relaţionale ................................................. 227
Figura 39 – Schema conceptuală a unei soluţii hibride la cheie
............................................................................................... 230
328
Figura 40 – Integrarea datelor hibride bazată pe virtualizarea

datelor.................................................................................... 234
Figura 41 – Integrarea stratului semantic pentru vizualizarea
datelor.................................................................................... 237
Figura 42 – Cadrul de lucru semantic ................................... 238
Figura 43 - Rezultatul măsurătorii pentru scenariul OLTP bazat
pe o cantitate de date de 100 MO, cu măsurători efectuate la 1
MB, 5 MB, 10 MB, 50 MB şi 100 MB ................................. 253
Figura 44 – Diagrama de context a aplicaţiei ASMDB ........ 265
Figura 45 – Diagrama cazurilor de utilizare pentru iniţializarea
aplicaţiei, pornirea şi oprirea serverului MongoDB şi operaţiile
auxiliare................................................................................. 267
Figura 46 – Diagrama cazurilor de utilizare pentru obţinerea de
informaţii despre sistemul pe care rulează ASMDB ............. 268
gestiune a bazelor de date ..................................................... 270
gestiune a conturilor de utilizator.......................................... 271
colecţiilor .............................................................................. 272
documentelor ......................................................................... 273
benchmark şi de validare....................................................... 274
Figura 52 – Diagrama cazurilor de utilizare pentru solicitarea
de informaţii despre aplicaţie ................................................ 275
Figura 53 – Aspectul aplicaţiei ASMDB în cazul în care
aceasta este conectată la un server ........................................ 284
Figura 54 – Utilitarul Informaţii despre sistem ..................... 288
Figura 55 – Form10 – vizualizarea unui document ca un
aglomerat de text ................................................................... 299
Figura 56 – Form10 – vizualizarea unui document în formă
tabelară .................................................................................. 299
329
Figura 57 – Form11 – dialogul de adăugare a unui document cu

o structură simplă într-o colecţie ........................................... 303
330
Lista tabelelor
Tabelul 1 - Un sumar al listei tehnicilor utilizate de Dynamo

împreună cu avantajele lor ...................................................... 55
Tabelul 2 – O statistică reprezentând familiile de sisteme de
operare instalate pe supercalculatoarele din Top500 .............. 69
Tabelul 3 – Utilizarea procesoarelor scalare, respectiv
vectoriale în sistemele de calcul din Top500 .......................... 72
Tabelul 4 – Distribuţia familiilor de procesoare în Top 500... 73
Tabelul 5 – Clasificarea sistemelor din Top500 după tipul de
sistem ...................................................................................... 83
Tabelul 6 – Procesoare grafice utilizate ca acceleratoare pentru
sistemele de înaltă performanţă (GPGPU) ............................ 107
Tabelul 7 – Tipurile de nevoi ale inteligenţa afacerii tratate de
modelul DSS 2.0 ................................................................... 142
Tabelul 8 – Tabelul comparativ cu facilităţile oferite de cele
trei produse selectate ............................................................. 163
Tabelul 9 – O analiză comparativă utilizabilă în stabilirea
sistemului NoSQL potrivit pentru o anumită aplicaţie ........ 196
Tabelul 10 - Coeficientul de corelaţie ................................... 256
Tabelul 11 - Coeficientul de determinare ............................. 257
Tabelul 12 - Reziduuri standardizate .................................... 258
Tabelul 13 - Coeficienţii şi nivelul de semnificaţie al modelului
............................................................................................... 259
331

Carte Big Data 2016 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Carte Big Data 2016 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

BOGDAN GEORGE TUDORICA

PRIN LUMEA BIG DATA

”Călătorie prin lumea Big Data”, by Bogdan

Tipar executat la:

Descrierea CIP a Bibliotecii Nationale a Romaniei

stocare sau pentru transmisie), dar şi metode de securizare

 Identificarea provocărilor (traduse în posibile

Lucrarea este structurată în două părţi cuprinzând cinci

a datelor, precum şi ideile care stau la baza implementării unei

Date - Datele sunt valori ale unor variabile calitative

o cantitate de date care necesită pentru prelucrare calculatoare

datele într-o bază de date în conformitate cu un model de bază

Consistenţă - În contextul ACID, consistenţa se referă

Modelul de consistenţă „în cele din urmă” are

Adresez mulţumirile cuvenite colegilor mei din cadrul

Partea întâi – trecut și prezent în Big Data

1 Aspecte privind modalitățile de structurare a

1.1 Organizarea structurată a volumelor mari de

De regulă, volumele cele mai mari de date pot fi

1.1.1 Baze de date relaţionale

În ultima perioadă, peste 86% din totalul veniturilor

DB2 şi Oracle au oferit îmbunătăţiri majore în zona de

toate acestea, capacitatea de a executa operaţii de BI într-un

În zona de management al securităţii, Oracle acceptă

Scalabilitatea este capacitatea unui SGBD de a se

fără ca aplicaţiile să sufere vreun efect vizibil. O altă variantă

procesoare pentru a executa mai multe tranzacţii în acelaşi timp

administrate individual de către noduri) sau Shared-Disk (în

Dacă utilizatorul exploatează abilitatea SGBD folosit

acceptă stocarea relaţională pentru OLAP, nu este oferită nicio

DB2 utilizează tehnologia numită Clustering Multi

(Facilitate de Partiţionare Distribuită) utilizează un algoritm

granularitate foarte fină la extindere, datorită abilităţii sale de a

Opţiunile de partiţionare oferite de Oracle suportă atât

Oracle Database şi Real Application Cluster

Oracle Real Application Clusters este o opţiune pentru

care este pachetul Oracle de extensii pentru asigurarea de

Arhitectura Oracle Real Application Clusters

Figura 1 – Arhitectura Oracle Real Application Clusters

Oracle Real Application Clusters decuplează instanţa

suplimentare, pot fi adăugate la Server Pool servere şi instanţe,

Prin acest API, orice aplicaţie care se înregistrează în

Figura 2 – Vedere de ansamblu asupra Oracle Clusterware

Microsoft SQL Server şi Azure

Microsoft SQL Azure Database este o bază de date de

Microsoft Azure poate fi utilizat pentru construcţia

o sunt disponibile constrângeri;

o Visual Studio 2010 asigură crearea de

Facilităţi anunţate - SQL Azure Data Sync

SQL Azure Data Sync care se află în prezent în stadiul

 administrarea conflictelor – cazurile în care aceleaşi

IBM DB2 şi Distributed Relational Database

Distributed Relational Database Architecture (DRDA)

O unitate de lucru distribuită (DUOW – Distributed

programatori pentru a construi aplicaţii cu ajutorul unor

DB2 Connect şi serverul IBM în cazul în care se lucrează

Figura 3 – Comunicaţia de date între staţia de lucru DB2 Connect şi

Pentru implementarea conexiunilor între SGBD, server

O unitate de lucru la distanţă (remote unit of work –

conţinând tabele de plăţi şi de depozite, precum şi o

Figura 4 – Utilizarea unei singure baze de date într-o tranzacţie.

O cerere distribuită este o funcţie a unei baze de date

modificare în aplicaţiile care solicită acele informaţii. De