PROGRAMUL DE STUDIU MANAGEMENT ÎN TEHNOLOGIA INFORMAȚIEI FORMA DE ÎNVĂȚĂMÂNT IF LUCRARE DE DISERTA ȚIE COORDONATOR ȘTIINȚIFIC PROF . DR. ING…. [607379]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU MANAGEMENT ÎN
TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT IF

LUCRARE DE DISERTA ȚIE

COORDONATOR ȘTIINȚIFIC
PROF . DR. ING. CORNELIA AURORA GYŐRÖDI

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU MANAGEMENT ÎN
TEHNOLOGIA INFORMA ȚIEI
FORMA DE ÎNVĂȚĂMÂNT IF

ANALIZA PERFORMAN ȚELOR
BAZEI DE DATE RELA ȚIONALE
MYSQL COMPARATIV CU BAZA DE
DATE NO -SQL CASSANDRA

COORDONATOR ȘTIINȚIFIC
PROF. DR. ING. CORNELIA AURORA GYŐRÖDI

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI

TEMA

Lucrare de fina lizare a studiilor a student: [anonimizat] : BACTER RĂZVAN – IOAN

1) Tema lucrării de finalizare a studiilor:
ANALIZA PERFORMANȚELOR BAZEI DE DATE RELAȚIONALE MYSQL
COMPARATIV CU BAZA DE DATE NO -SQL CASSANDRA

2) Termenul pentru predarea lucrării: 03 septembrie 2020

3) Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor: baza de date
relațională MySQL + limbajul SQL, baza de date distribuită Cassandra + limbajul CQL ,
limbajul PHP.

4) Conținutul lucrării de finalizare a studiilor: Introducere; Concepte teoretice ale baze lor
de date relaționale – Introducere în baza de date MySQL, Baze de date relaționale, Operații
SQL de bază, Comanda CREATE , Comanda INSERT , Comanda UPDATE , Comanda
SELEC T, Comanda DELETE ; Concepte teoretice ale bazelor de date NoSQL – Introducere în
teoria bazelor de date NoSQL , Baza de date Cassandr a, Caracteristici ale bazei de date
Cassandra , Arhitectura bazei de date Cassandra , Structura bazei de date Cassandra , Replicarea
datelo r, Operațiile de scriere/citire ; Studiu comparativ – Instalarea MySQL și Cassandr a,
Proiectarea bazelor de dat e, Teste de performanță , INSERT – operația de adăugare a datelor ,
SELECT – operația de interogare a datelor , UPDATE – operația de actualizare a datelor ,
DELETE – operația de ștergere a datelo r; Concl uzii; Bibliografie.

5) Material grafic: schem e, grafice , capturi de ecran .

6) Locul de documentare pentru elaborarea lucrării: Internet, biblioteca universității

7) Data emiterii temei : 02 octombrie 2 019

Coordonator științific
Prof. dr. ing. Cornelia Aurora GYŐRÖD I

1

Cuprins

INTRODUCERE ………………………….. ………………………….. ………………………….. …………….. 2
CAPITOLUL I. CONCEPTE TEORETICE ALE BAZELOR DE DATE
RELA ȚIONALE ………………………….. ………………………….. ………………………….. …………….. 5
I.1. INTRODUCERE ÎN BAZA DE DATE MYSQL ………………………….. ……………………. 5
I.2. BAZE DE DATE RELAȚIONALE ………………………….. ………………………….. …………. 6
I.3 OPERAȚII SQL DE BAZ Ă………………………….. ………………………….. …………………….. 7
I.3.1 Comanda CREATE ………………………….. ………………………….. ………………………….. … 7
I.3.2 Comanda INSERT ………………………….. ………………………….. ………………………….. ….. 8
I.3.3 Comanda UPDATE ………………………….. ………………………….. ………………………….. … 8
I.3.4 Comanda SELECT ………………………….. ………………………….. ………………………….. …. 8
I.3.5 Comanda DELETE ………………………….. ………………………….. ………………………….. …. 9
CAPITOLUL II. CONCEPTE TEORETICE ALE BAZELOR DE DATE NOSQL …. 10
II.1 INTRODUCERE ÎN TEORIA BAZELOR DE DATE NOSQL ………………………….. . 10
II.2 BAZA DE DATE CASSANDRA ………………………….. ………………………….. …………. 12
II.2.1 Caracteristici ale bazei de date Cassandra ………………………….. ……………………… 12
II.2.2 Arhitectura bazei de date Cassandra ………………………….. ………………………….. …. 13
II.2.3 Structura bazei de date Cassandra ………………………….. ………………………….. ……. 14
II.2.4 Replicarea datelor ………………………….. ………………………….. …………………………. 15
II.2.5 O perațiile de scriere/citire ………………………….. ………………………….. ………………. 17
CAPITOLUL III. STUDIU COMPARATIV ………………………….. ………………………….. … 18
III.1 INSTALAREA MYSQL ȘI CASSANDRA ………………………….. ……………………….. 18
III.2 PROIECTAREA BAZELOR DE DATE ………………………….. ………………………….. . 19
III. 3 TESTE DE PERFORMANȚĂ ………………………….. ………………………….. ……………. 23
III.3.1 INSERT – operația de adăugare a datelor ………………………….. ……………………… 24
III.3.2 SELECT – operația de interogare a datelor ………………………….. ……………………. 28
III.3.3 UPDATE – operația de actualizare a datelor ………………………….. ………………….. 31
III.3.4 DELETE – operația de ștergere a datelor ………………………….. ………………………. 33
CONCLUZII ………………………….. ………………………….. ………………………….. ………………… 36
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. …………… 37

2
INTRODUCERE

Societatea contemporan ă este foarte mult influențată de progresul tehnologic , progres
aflat în continuă inovare și dezvoltare, drept urmare indiferent de domeniul de activitate din
care facem parte, suntem afectați, deja în mod direct, de această eră a digitalizării, întrucât
oriunde am privi sau oriunde ne -am îndrepta, constatăm că fără tehnologia din ziua de azi
probabil am fi foarte debusol ați, în special că genereația noastră a crescut concomitent cu
tehnologia.
Fiecare domeniu de activitate încearcă să își gestioneze sarcinile și să își ușureze munca
prin diverse aplicații de gestiune și de management în care cu un simplu click să se urmă rească
rapoarte reale cu privire la progresul afacerii, astfel se va ști cu exactitate ce proces trebuie
îmbunătățit pentru a atinge scopul inițial.
Drept urmare, i ntroducerea mai multor resurse de calcul și aplicarea lor din ce în ce mai
mare a dat nașt ere unei cantități masive de date, ceea ce a dus la generarea de date structurate
și nestructurate cunoscute sub numele de Big Data.
Big Data reprezintă un termen cheie utilizat pentru descrierea datelor dificil de analizat
din cauza dimensiunii sale uri așe. După cum indică numele, Big Data poate fi asociat cu
volumul mare de date, dar mai ales este asociat cu o nouă tehnologie inovatoare, o tehnologie
care ajută la gestionarea unei cantități uriașe de date și stocarea acestora prin intermediul
diferitelo r instrumente sau procese. [1]
În ziua de astăzi , principala problemă o constituie faptul că datele de care avem nevoie
pentru a analiza o situație dată trebuie să le obținem într -un mod rapid, lucru realizat de
preferință cu costuri reduse și la performa nțe ridicate.
O tehnică de rezolvare a acestei probleme o reprezintă sistemele distribu ite. Aceste
sisteme distribuite permit conectarea unei rețele cu un grup de calculatoare autonome, care
împreună vor distribui resurse și își vor coordon a activitățile pentru furnizarea unei facilități de
calcul și pentru a fi dispuse să se identifice ca o singură unitate.
O bază de date distribuită poate fi considerată ca un exemplu de sistem distribuit în care
dispozitivele de stocare nu sunt conectate l a o singură mașină de calcul, în schimb sunt
gestionate de un singur sistem distribuit de gestionare a bazelor de date.
De-a lungul secolului al III -lea înainte de Hristos, s -a considerat că întreaga cunoaștere
uman ă se putea regăsi în Biblioteca din Alex andria, dar luând în calcul situația de astăzi
referitoare la cantitatea de informați e prezentă în lume, dacă oricărei perso ane în viață i se va

3
oferi o cantitate suficientă de informații, aceasta va fi de 320 de ori mai mult decât s -a
preconizat că se afl ă în Biblioteca din Alexandria , echivalent al 1200 Exabyte , iar dacă toate
aceste date sunt inscripționate pe CD -uri, atunci vor fi necesare cinci mormane de CD -uri
stivuite , mormane ce vor ajunge până la lună. [1]
Această creștere semnificativă a datelor nu a fost sesizabilă până în anul 2000. Pe atunci
doar un sfert din informațiile din întreaga lume au fost digitale, restul informațiilor fiind
înregistrate și stocate pe hârtie. Odată cu accelerarea cantității de date și a digitalizării lor,
tendința sto cării și înregistrării datelor s -a schimbat semnificativ, drept urmare, în prezent se
preconizează că doar 2% din cantitatea de date sunt stocate și înregistrate pe hârtie, restul fiind
digitalizate.
Dacă pentru o simplă aplicație web este suficient să se utilizeze o bază de date
relațională, în cele mai multe cazuri MySQL, bază de date folosită strict pentru stocarea
informațiilor relevante, preluate dintr -un singur loc, la nivelul aplicației nu și din alte sfere,
pentru o aplicație de management și gest iune, de exemplu al unei rafinării, în care preluarea
datelor se realizează din mai multe direcții precum senzori, semnale GPS, adrese IP ale
diverselor calculatoare conectate etc. , iar la final va da un răspuns real și corect cu toate datele
realizând ast fel un raport sau o statistică, baza de date relațională nu va fi îndeajuns, astfel se
va apela la o bază de date distribuită, care să fie capabilă să preia informații din mai multe
direcții și să formeze un tot unitar cu acestea.
Deja, aproape orice comp anie descoperă că trebuie nu doar să gestioneze volume de
date din ce în ce mai mari în sistemele lor în timp real, dar și să analizeze aceste informații
astfel încât să poată lua rapid deciziile potrivite pentru a concura eficient pe piață sau pentru a
evita inevitabilul în cazul unor procese în care riscul de a produce un impact violent asupra
comunității sau a mediului înconjurător este destul de ridicat, de exemplul în cauzul unei
rafinării petroliere sau în cazul transportului aerian, în care datele transmise trebuie să se
realizeze cât mai aproape de timpul real.
Drept urmare, datorită volumului mar e de date înregistrate și totodat ă afișate, în
prezenta lucrare de diserta ție surpind o comparație între dou ă baze de date utilizate, o baz ă de
date rela țional ă MySQL, utilizat ă în majoritatea aplicațiilor web, și baz a de date Cassandra, o
bază de date NoSQL (Not Only SQL), distribuită de înaltă performanță , scalabilă, proiectată
pentru a gestiona cantități mari de date de pe mai multe servere .
În ceea ce privește această lucrare de disertație, ea este structurată în trei mari capitole,
respectiv partea de concluzii și bibliografie.

4
În primul capitol al lucrării de disertație intitulat “ Concepte teoretice ale bazelor de date
relaționale ” se prezintă principalele aspecte teoretice ale bazei de date relaționale MySQL,
instalarea programelor necesare pentru a avea acces la baza de date, modul în care se realizează
operațiile de bază CRUD ( create – read – update – delete ) pe datele stocate, precum și uti litățile
acestui tip de bază de date.
Capitolul al doilea denumit “ Concepte teoretice ale bazelor de date N oSQL ” va ilustra
principalele aspecte ale bazei de date NoSQL Cassandra, utilitățile acestui tip de bază de date,
precum și modul de a manipula date le stocate utilizând operațiile de bază CRUD.
Cel de -al treilea capitol numit “ Studiu comparativ ” prezintă analiza propriu -zisă a
performanțelor bazei de date relaționale MySQL comparativ cu baza de date distribuită
Cassandra. În acest capitol am urmărit c ele două baze de date din punct de vedere al timpului
de procesare al operațiilor CRUD pe diverse cantități de date, precum și modul de
implementare și de rulare al acestor operații în rândul celor două baze de date studiate. În plus,
rezultatele obținute în urma rulării operațiilor respective le voi reprezenta grafic pentru a putea
remarca cu ușurință performanțele celor două baze de date.

5
CAPITOLUL I. CONCEPTE TEORETICE ALE BAZELOR DE DATE
RELA ȚIONALE

I.1. INTRODUCERE ÎN BAZA D E DATE MYSQL

O bază de date reprezint ă o aplicație separată care stochează o colecție de date. Fiecare
bază de date are una sau mai multe API -uri distincte pentru crearea, accesarea, administrarea,
căutarea și replicarea datelor pe care le deține .
De aseme nea, se pot utiliza și alte modalități de înregistrare și stocare a datelor, precum
sistemul de fișiere (file system) sau chiar tabelele din memoria calculatorului ( hash tables ), însă
scrierea și citirea datelor nu s -ar face atât de rapid și ușor ca în caz ul unei baze de date dedicate.
MySQL este cel mai popular sistem relațional de gestiune a bazelor de date , în special
pentru realizarea aplicațiilor web. Este un software specializat care permite accesul și
gestionarea bazelor de date, folosindu -se de limbajul SQL (Structured Query Language). [ 2]
Limbajul SQL a luat ființă în anul 1970 , fiind dezvoltat de către IBM. Acest limbaj a
fost conceput și dezvoltat pentru a putea înregistra și gestiona date structurate conform
modelului relațional al lu i Edgar F. Codd și reprezintă limbajul standard pentru bazele de date
relaționale.
SQL permite stocarea și ulterior manipularea datelor prin diverse interogări care duc la
analiza unor cantități mari de date structurate , astfel încât contribuie la buna de sfășurare a
activităților unei companii , analizându -se cu ușurință situația de față a acesteia. Un exemplu
concret este reprezentat de obținerea de indicatori de performanță pentru fiecare departament
în parte.
MySQL reprezintă o componentă esențială a pl atformei LAMP (Linux, Apache,
MySQL și PHP). Această bază de date poate fi ușor accesibilă de către utilizatori, întrucât poate
fi descărcată și implementată gratui t, fiind open -source și având referințe bine definite și o
documentație bine elaborată. Baza de date MySQL poate să ruleze pe orice sistem de operare,
fie el Linux, Windows sau MAC, drept urmare nu va fi un impediment din acest punct de
vedere.
Dezvoltarea bazei de date relaționale MySQL a început în anul 1994 de către compania
suedeză MySQL AB, iar în decursul anilor a suferit diferite modificări din punct de vedere
juridic, astfel în anul 2008 proiectul MySQL AB a fost achiziționat în totalitate de către Sun
Microsystems, iar ulterior, în 2010, a fost cumpărat de către Oracle, care o deține și î n ziua de

6
astăzi. MySQL are la bază limbajul de programare C/C++, dar există numeroase API -uri care
fac posibilă conexiunea și cu alte limbaje de programare precum PHP, Python, Java, C#, Ruby,
Perl etc.
MySQL oferă dou ă versiuni disponibile: MySQL server s ystem (sistem de server) și
MySQL embedded system (sistem încorporat). Atât software -ul server -ului MySQL, cât și
sistemul încorporat MySQL au licență duală : versiunea 2 GPL (General Public License) și
licența proprie. [3]
Pe lângă MySQL, există și alte sisteme de baze de date accesibile în mod gratuit fiind
open -soure, astfel putem enumera: PostgreSQL, Firebird, SQLite, Derby sau HSQLDB.

I.2. BAZE DE DATE RELAȚIONALE

În prezent, pentru stocarea și gestionarea unui volum imens de date folosim sisteme
relaționale de gestionare a bazelor de date. O bază de date relațională reprezintă de fapt o
colecție de date organizate în tabele diferite, tabele între care se stabilesc anumite relații de
legătură folosind chei primare (primary keys) sau alte chei intitulate “foreign keys”, conform
cerințelor și specificațiilor fiecărui proiect. Tabelele sunt structurate în rânduri și coloane,
fiecare rând repre zentând o nouă înregistrare, iar fiecare coloană semnificând un câmp specific
înregistrării res pective.
Un rând din baza de date reprezintă un singur element de date structurat implicit într –
un tabel. O coloană semnifică un set de valori ale unui anumit tip de date. Coloanele formează
structura ce compune fiecare înregistrare, rând. Un câmp dintr -o tabelă reprezintă un element
care se află la intersecția dintre un rând și o coloană.
După cele specificate anterior, relațiile dintre tabele se realizează atât prin chei primare
(primary keys), cât și prin chei străine (foreign keys). O cheie primară ide ntifică în mod unic
fiecare înregistrare din tabel, de exemplu în majoritatea cazurilor, cheia primar ă a unei
înregistrări este evidențiată prin ID -ul înregistrării, ID unic ce se incrementează în mod automat
cu fiecare înregistrare. Spre deosebire de chei a primar ă a unei înregistrări, cheia străină
identifică o coloană sau un set de coloane dintr -un tabel de referință care se referă la o coloană
sau la un set de coloane dintr -un alt tabel referit.

Fig. I.1 Structura un ei înregistrări dintr -un tabel

7
Figura I.1 ilustrată mai sus, prezintă structura unei înregistrări dintr -o tabel ă din baza
de date MySQL, o structură bine definit ă pe coloane. Conform imaginii de mai sus remarcăm
o înregistrare în tabela “book”, o înregistrare a unei cărți ce are ca și a tribute caracteristice “id –
ul” înregistrării, titlul, autorul, editura și anul publicării respectivei cărți. ID-ul înregistrării este
cheia primară a acestui tabel, drept urmare în tabela “book”, nu vor putea exista mai multe
înregistrări cu același ID, ac esta incrementându -se în mod automat cu fiecare înregistrare în
parte.
Drept urmare un sistem relațional de gestionare a unei baze de date (Relational
DataBase Management System – RDBMS) este un program software care îndeplinește
următoarele aspecte :
• Permi te implementarea unei baze de date cu tabele, coloane și index -uri;
• Garanteaz ă integritatea referențială între rândurile diferitelor tabele ;
• Actualizează în mod automat index -urile;
• Interpretează interogările SQL și combină informațiile din diverse tabele. [4]

I.3 OPERAȚII SQL DE BAZ Ă

După cum am specificat anterior, bazele de date sunt utilizate în primă fază pentru
stocarea informațiilor, iar ulterior pentru manipularea acestora în vederea obținerii unor afișări
sau rapoarte esențiale formării unui punct de vedere cu privire la o companie.
Pentru stocarea și manipularea datelor, limbajul SQL dispune de numeroase operații
CRUD ( create – read – update – delete) asupra bazei de date, operații fără de care nu am putea
gestiona și analiza datele.

I.3.1 Comanda CREATE

După cum îi zice și numele, comanda “creat e” este utilizat ă pentru crearea atât a bazei
de date, cât și a tabelelor aferente acesteia. Pentru a crea o nou ă bază de date, se va folosi
următoarea comandă, în care db_name reprezintă denumirea bazei de date.
CREATE DATABASE db _name;
Crearea unei baze de date corespunde creării unui director în care vor fi păstrate
elementele specifice cum ar fi tabelele aferente proiectului.
Pentru a crea tabelele aferente unei baze de date se va utiliza comanda de mai jos în
care tabel _name reprezintă numele unei tabele în care se v or înregistra datele, column1 ..

8
reprezint ă denumirea coloanei asociată fiecărui câmp al unei înregistrări, iar parametrul
datatype specifică tipul de date înregistrate. Tipul datelor poate fi: șir de caractere (string),
numeric și dată (date and time).
CREATE TABLE table_name (
column1 datatype, column2 datatype, column3 datatype,
….);

I.3.2 Comanda INSERT

Comanda “insert” permite ad ăugarea de noi înregistrări (rânduri) într -o tabelă.
Deoarece sistemul MySQL este pur relațional, nu există nici o diferenț ă între inserarea de noi
date sau adăugarea lor. În ambele situa ții, locul în care se realizează adăugarea nu este precizat,
nefiind relevant.
La sistemele care nu sunt pur relaționale (cum este dBase sau FoxPro) opera ția de
adăugare semnifică adăugarea la sfârșitul unei tabele, pe când inserția înseamnă inserarea între
alte două înregistrări existente.
Sintaxa de bază pentru această comandă este următoarea:
INSERT INTO table_name (column1, column2, column3, …)
VALUES (value1, value2, value3, …);

I.3.3 Comanda UPDATE

Cu ajutorul aceste i comenzi “update” utilizatorul poate actualiza (modifica) valorile
inițiale dintr -o tabelă.
UPDATE table_name
SET column1 = value1, column2 = value2, …
WHERE condition;
Spre deosebire de celelalte comenzi, în cazul modificării datelor dintr -un anumit tabel,
vom avea nevoie și de o clauză “where”, pentru a modifica doar acele înregistrări care respectă
condiți a impusă .

I.3.4 Comanda SELECT

Această comandă este cea mai utilizată comandă SQL. Ea permite extragerea și
vizualizarea datelor din tabelele bazei de date, date pe baza cărora utilizatorul poate să observe
întreaga activitate, astfel se vor putea crea diverse rapoarte cu privire la un domeniu de
activitate, rapoarte în urma cărora să se tragă o concluzie, fie una de îmbunătățire a procesului
până la punctul stabilit, fie al continuării procesului dacă acesta a atins deja limitele stabilite.

9
Comanda “select” poate fi utiliz ată fie pe întreg tabelul din baza de date astfel vor fi
afișate toate câmpurile înregistrărilor , fie doar pe anumite câmpuri din acest tabel afișându -se
astfel doar câmpurile specificate ale înregistrărilor . Desigur se pot extrage informații și
aplicând a numite condiții, astfel se vor afișa doar acele înregistrări care respectă condițiile
impuse în clauza “where”.
SELECT column1, column2, … SELECT *
FROM table_name; FROM table_name;
Comanda “select” în forma de mai sus permite ef ectuarea operației de interogare a
datelor doar dintr -o singură tabelă, însă limbajul SQL permite tot prin utilizarea acestei
comenzi, interogarea datelor din diferite tabele aflate în legături relaționale stabilite între cheia
primară a tabelei de bază și cheile străine (foreign keys) ale tabelelor de legătură , fapt
concretizat prin operatorul JOIN. Preluarea datelor din mai multe tabele se realize ază astfel :
SELECT column_name(s)
FROM table1
LEFT JOIN table2
ON table1.column_name = table2.column_name;

I.3.5 Comanda DELETE

Pentru a șterge datele din tabele se va utiliza comanda “delete”, însă un aspect foarte
important este faptul că datele odată șterse nu mai pot fi recuperate. Comanda “delete” are
următoarea sintaxă :
DELETE FROM table_name WHERE condition;

10
CAPITOLUL II. CONCEPTE TEORETICE ALE BAZELOR DE DATE
NOSQL

II.1 INTRODUCERE ÎN TEORIA BAZELOR DE DATE NOSQL

În ziua de astăzi, datorită tehnologiilor în continuă dezvoltare, aplicațiile web țin să
tindă spre înglobarea a mai multor aplicații particulare, care împreună, prin pr opriile
funcționalități, să formeze un tot unitar, o aplicație nouă care să poat ă permite manipula rea și
gestionarea datelor și din alte aplicații.
În plus, dacă în urmă cu câțiva ani, o simplă aplicație web obișnuia să conecteze de la
mii până la zeci de mii, chiar sute de mii de utilizatori, acum, o aplicație poate conecta simultan
utilizatori de ordinul milioanelor , de exemplu Facebook sau Instagram, utilizatori ce sunt
conectați în permanență.
Toate aceste aplicații au în spate un volum imens de date care sunt partajete fiecărui
utilizator, astfel în vederea creării unei aplicații fie ea de n ivel înalt sau unul moderat, este
important să se ia în calcul varianta de bază de date utilizată pentru stocarea întregii informații.
În vederea stocării informațiilor, cea mai utilizată metodă pe scară largă în vederea
stocării datelor o reprezintă bazel e de date relaționale, baze de date perfecte și cu o bună
performanță atunci când se gestionează o cantitate limitată de date. Însă, pentru stocarea și
manipularea a unui volum ridicat de date, utilizarea bazelor de date tradiționale este ineficientă,
deoa rece se realizeaz ă simultan sute de mii sau chiar milioane de interogări cu scopul de a
obține informația relevantă fiecărui utilizator, precum în cazul Facebook de exemplu.
Pentru a depăși acest impas în ceea ce privește stocarea și manipularea unor canti tăți
mari de date, a fost introdus termenul de “NoSQL” de către Carlo Strozzi în 1998 reprezentând
numele bazei sale de date relaționale open -source și fără interfață SQL , referindu -se la o bază
de date non -relațională. Termenul de NoSQL a fost reintrodus și în anul 2009 de către Eric
Evans care în cadrul unui eveniment ce avea ca tematică bazele de date distribuite, a folosit
acest termen nu pentru a defini un întreg sistem, ci termenul a fost folosit pentru a arăta și a
accentua evoluția bazelor de date r elaționale către baze de date cu performanțe sporite, iar mai
recent acest termen a căpătat o nouă semnificație, și anume “Not Only SQL”, comparativ cu
varianta inițială, o variantă anti -relațională. [6]
Unul dintre motivele apariției NoSQL îl reprezintă f aptul că aplicațiile web tind spre a
stoca și a manipula cantități mari de date pentru a putea rămâne competitive pe piață, oferind

11
multe funcționalități utilizatorilor. Pe măsura trecerii timpului, cantitatea de informații crește
exponențial astfel dezvol tatorii trebuie să găsească soluții pentru ca o aplicație să suporte și să
poată manipula cantități mari de date.
Utilizatorii nu se mai mulțumesc doar cu rolul de a folosi bazele de date prelu ând doar
informația , ci doresc și să producă conținut și astfel s-a produs o restructurare a modalității de
stocare și folosire a datelor de pe Web. Din acest punct de vedere, bazele de date relaționale nu
mai prezintă eficiență din perpectiva timpului, în special în contextul aplicațiilor mari. [6]
Bazele de date NoS QL se caracterizează ca fiind noua generație de baze de date care
îndeplinesc un set de condiții : nu sunt relaționale, sunt distribuite, open -source și se
caracterizează prin scalabilitate orizontală.
O bază de date NoSQL este concepută diferit, având o structură diferită față de o baza
de date relațională clasică, astfel NoSQL va avea alt model în ceea ce privește înmagazinare a
datelor, ignorând principiile RDBMS (Relational DataBase Management System). Într-o bază
de date NoSQL nu mai există o schemă propriu -zisă a datelor, i nformațiile nu vor mai fi stocate
folosind tabelele precum în cazul bazelor de date relaționale, ci vor fi stocate folosind chei de
identificare, iar aceste date vor putea fi regăsite în funcție de cheile asignate (perechi cheie –
valoare) .
Bazele de date NoSQL au la bază teorema CAP (Consistency – Availability – Partition
Tolerance) cu privire la modul de stocare, gestionare și de distribuire a informației către toți
utilizatorii aplicației respective. Ace astă teoremă precizează tr ei cerințe esențiale de care ar
trebui să se țină cont în momentul în care se proiectează diferite aplicații ce prevăd un sistem
distribuit. Aceste cerințe de bază includ consistența, disponibilitatea și toleranța partițiilor.
Prima cerință asigură coere nța datelor după efectuarea unei operații, d e exemplu, după
executarea unei operații de actualizare, toți clienții ar trebui să vadă aceleași date în același
timp. Disponibilitatea garantează că serviciul funcționează fără timp de oprire , iar t oleranța
partiției se referă la toleranț a la erori, astfel dacă apare o eroare de comunicare ce are loc între
două sau mai multe servere, atunci sistemul trebuie să funcționeze în continuare. [1]
În practică, cele trei cerințe de bază
nu vor putea fi îndeplinite simul tan într -un
sistem distribuit. Așa cum se arată în
figura II.1, bazele de date N oSQL
funcționează prin combinarea o ricăror
două cerințe.
Fig. II.1 Reprezentarea grafic ă a teoremei CAP [1]

12
II.2 BAZA DE DATE CASSANDRA

Printre primele aplicații mari, ce au ridicat problem a scalabilității, se număra aplicația
Facebook. Această rețea de socializare presupune un număr impresionant de utilizatori, la
nivelul milioanelor. Prin adoptarea bazelor de date NoSQL scalarea masivă a adus un beneficiu
enorm.
Unul din primele sisteme NoSQL pentru managementul datelor a fost proiectat inițial
de Facebook prin perspectiva indienilor Avinash Lakshman ( unul dintre dezvoltatorii bazei de
date Amazon's Dynamo) și Prashant Malik , și poartă numele de “Cassandra”. A fost dezvol tat
pentru a aduce un plus funcției de căutare al aplicației Facebook. [5]
Baza de date Cassandra, este o bază de date non -relațională, orientată pe coloană,
distribuită, dezvoltată pentru stocarea unor cantități mari de date nestructurate pe mai multe
servere. Totodată, Cassandra este disponibilă utilizatorilor în mod gratuit fiind open -source.
Cassandra este o bază de date scalabilă, consistentă, distribuită, care pentru stocarea
informațiilor folosește perechi cheie -valoare. Aceasta reunește tehnologiile sistemelor
distribuite de la Amazon’s Dynamo și modelul de date de la Google BigTable. [5]
Apache Cassandra a devenit una dintre cele mai populare baze de date NoSQL. De la
înființarea sa în 2008, baza de date Cassandra s -a dovedit a fi imbatabilă atunci când este nevoie
de disponibilitate și scalabilitate , astfel pentru a asigura în mod continuu diverse funcționalități
ale serviciilor și o experiență cât mai placută și totodată individualizată a utilizatorilor,
numeroase companii de renume ca Netflix, Instagram, eBay, GitHub etc., utilizeaz ă Cassandra
ca bază de date.

II.2.1 Caracteristici ale bazei de date Cassandra

De-a lungul timpului, Cassandra și -a dovedit eficiența în rândul bazelor de date NoSQL
în vederea stocării și manipulării unor cantități semnificative de date prin caracteristicile sale :
• Scalabilitate ridicat ă – Cassandra reprezint ă o bază de date puternic scalabilă, întrucât
permite fără probleme adăugarea m ai multor echipamente de stocare, dar și a mai
multor dispozitive hardware pentru a permite stocarea mai multor clienți și a mai multor
date conform cerințelor ;
• Arhitectura – Datorit ă arhitecturii sale, Cassandra este construită astfel încât să
răspundă pr ompt situațiilor critice , având toate nodurile la acel ași nivel oferind
simplitate operațională ;

13
• Toleranță la defecte – Cassandra este tolerantă la erori. Să presupunem că există 4
noduri într -un cluster, aici fiecare nod are o copie a acelorași date. Dacă un nod nu mai
servește, atunci alte trei noduri pot furniza informații conform cererii ;
• Performanță rapidă – Prin scalabilitatea linia ră Cassandra menține un timp de răspuns
rapid în special pe măsură ce numărul nodurilor dintr -un cluster cresc;
• Stocarea de date flexibilă – Cassandra poate stoca orice fel de date fie ele structurate,
fie semi -structurate sau nestructurate, astfel poate adapta dinamic structurile de date în
funcție de nevoie ;
• Distribuirea datelor – Oferă flexibilitatea de a distribui datele , replicându -le în mai
multe centre de date ;
• Suport pentru tranzac ții – Cassandra oferă suport pentru proprietăți ca atomicitate,
consistență, izolare și durabilitate ;
• Scriere rapid ă – Cassandra a fost proiectată să funcționeze pe suport hardware ieftin,
drept urmare poate să efectueze scrieri rapide stocând astfel date de ordinul a sute de
terabytes ;
• Cassandra Query Language (CQL) – Cassandra furnizează un limbaj de interogare care
este similar cu limbajul SQL. [7]

II.2.2 Arhitectura bazei de date Cassandra

Baza de date Cassandra a fost proiectată pentru a stoca și gestiona o cantitate mai mare
de date pe mai multe noduri fără un singur punct de eșec. Are un sistem distribuit peer -to-peer
pe nodurile sale , astfel datele sunt distribu ite între toate nodurile dintr -un cluster.

Fig. II. 2 Arhitectura Cassandra [9]

După cum se poate remarca în figura II. 2 ilustrată mai sus, structura bazei de date
Cassandra are în compoziție următoarele :

14
• Nodurile – Reprezintă locul în care sunt stocate datele. Este componenta de bază a bazei
de date NoSQL Cassandra ;
• Data Center – O colecție de noduri se numește data center (centru de date) . Mai m ulte
noduri sunt clasificate ca data center;
• Cluster – Un cluster reprezint ă componenta care conține unul sau mai multe data centers
(centre de date) .
Fiecare nod este independent, dar în același timp este interconectat cu cel elalte noduri,
toate nodurile dintr -un cluster jucând același rol. Fiecare nod dintr -un cluster poate accepta
operații de citire sau scriere indiferent de locul în care datele sunt de fapt stocate în cluster.
Dacă un nod nu mai răspunde solicitărilor, cere rile de citire sau scriere vor fi acceptate de către
celelalte noduri aflate în rețea.

II.2.3 Structura bazei de date Cassandra

Cassandra oferă un model de date bazat pe Column -Family, un model ce conține
rânduri și coloane, doar că spre deosebire de mod elul relațional rândurile nu au în mod
obligatoriu aceleași coloane, în plus unui rând se pot adăuga oricând noi coloane.
Familia de coloane este un obiect NoSQL care conține perechi cheie -valoare. Fiecare
cheie este mapată într -un set de coloane. Acest ob iect a împrumutat câteva caracteristici ale
bazei de date relaționale. Familia de coloane reprezintă un tabel în care fiecare pereche de
cheie -valoare este reprezentat ă printr -un rând. Rândurile pot avea mai multe coloane diferite.
Fiecare coloană conține informații cu privire la numele, valoarea și ora. Coloanele se pot grupa,
astfel se formează o familie de coloane.
În figura II. 3 intitulat ă “Structurarea informației ” se prezin tă modul în care o
înregistrare este stocată în baza de date, astfel un tabel din baza de date conține unul sau mai
multe rânduri specifice fiecărei înregistr ări. La fel ca și în cazul bazei de date relaționale
MySQL, Cassandra stochează informația sub for mă de rânduri definite prin coloane, fiecare
coloan ă având o valoare. În plus față de MySQL regăsim cheia rândului, astfel fiecărui rând i
se va atribui o cheie utilizată pentru indexarea respectivei înregistrări.

15

Fig. II. 3 Structurarea informației [8]
De exemplu, dacă dorim să stocăm informațiile unui utilizator într -o tabelă numit ă
“user” , crearea unei noi tabele se realizează ca și în cazul bazelor de date relațional e, unde
definim coloane le și tipu l acestora.
Inserarea datelor în Cassandra este puțin diferit ă, deoarece nu trebuie să ad ăugăm toate
coloanele de fiecare dată când adăugăm o nouă înregistrare . De exemplu, dacă dorim să
înregistrăm și numerele de telefon ale utilizatorilor vom întâmpina mici probleme , deoarece
unii utilizatori pot avea unul sau mai multe numere de telefon, iar alții nu. Drept urmare, î n
ciuda faptului că pentru baza de date relațional ă MySQL pentru valori pe care nu le cunoaștem,
trebuie să stocăm nul l, utilizând baza de date Cassandr a nu salvăm niciodată coloana dacă
aceasta este null, astfel tabel a “user” care are înregistrați 2 utilizatori, unul cu un număr de
telefon, iar altul fără număr de telefon va arăta ca în figura II. 4 de mai jos.

Fig. II. 4 Structura unui tabel cu două înregistrări dacă o coloană este nu lă [10]

II.2.4 Replicarea datelor

Fiind o bază de date distribuită, Cassandra este creată pentru a gestiona cantități mari
de date pe mai multe servere.
Așa cum am menționat în cele de m ai sus , Cassandra folosește arhitectura peer -to-peer,
drept urmare toate nodurile sunt interconectate. Clientul se conectează la unul dintre noduri ,
iar n odul care primește solicitarea se numește nod coordonator. Dacă cheia căutată nu are

16
legătură cu inter valul de coordonatori, solicitarea este trimisă celuilalt nod a cărui cheie este
asociată. [10]
Printre caracteristicile importante ale bazelor de date NoSQL se enumeră și toleranța la
defecte sau erori. Drept urmare un aspect important îl reprezintă capa citatea bazei de date
Cassandra de a face back -up datelor sau altfel zis de a nu lăsa nici o cale de eșec netratată,
astfel toate datele stocate vor fi replicate în noduri diferite. Prin urmare, dacă va apărea fie o
problem ă hardware a centrului de date, fie o problemă de targetare a unei rute (nod sau cluster) ,
este necesară o soluție pentru a oferi o copie de rezervă a informațiilor .
Aceast ă caracteristică de replicare a datelor înseamnă că pentru fiecare înregistrare , sunt
create mai multe copii de siguranță în cluster. Numărul de copii de siguranță se poate seta după
factorul de replicare. Această caracteristică face posibilă garantarea disponibilității într -o
defecțiune a nodului. În plus, replicarea determină mai multe mașini implicate în adăug area
sau eliminarea nodurilor pentru migrarea datelor, prin urmare, performanța a crescut. [10]
Figura II. 5 ilustrează modul în care Cassandra duplică datele, astfel dac ă unele dintre
noduri vor răspunde solicitării utilizatorului cu o valoare depășită, C assandra va putea returna
cea mai recentă valoare, regăsită într -un alt nod, după care va efectua o operație de actualizare
a datelor, pentru a păstra la zi toate datele stocate și replicile acestora.

Fig. II. 5 Replicarea datelor [7]
După cum am prezentat anterior, replicarea datelor se efectuează pe noduri diferite pe
baza a doi factori : strategia de replicare ce determină locația unde se plasează următoarea
replică și factorul de replici ce reprezintă numărul total de replici plasate pe noduri diferite,
astfel u n factor de replicare înseamnă că există o singură copie de date, în timp ce trei factori
de replicare înseamnă că există trei copii ale datelor pe trei noduri diferite. Pentru a asigura că
nu există un singur punct de eșec, fa ctorul de replicare ar trebui să fie cât mai mare . [9]

17
II.2.5 Opera țiile de scriere/citire

Arhitectura bazei de date Cassandra este diferită față de bazele de date relaționale.
Cheia sa principală este definită diferit. Este o bază de date distribuită și folosește o funcție
avansată de hash pentru a stoca și accesa date pe mai multe servere. Baza de date Cassandra
stochează datele atât în memorie , cât și pe disc.
Pentru scrierea informațiilor în baza de date , clientul se conectează la nodul
coordonator. Acest nod atribuie cererea către un serviciu numit “storage Proxy ”. Atribuțiile
acestui serviciu const au în identificarea tuturor nodurilor responsabile cu stocarea acestor date.
Când sunt specificate nodurile replică, storageProxy le trimite mesaje tuturor. Serviciul
așteaptă apoi răspunsul de la nodurile responsabile. [10]
Procesul de scriere este prezent at în figura II. 6 ilustrată mai jos, astfel c ând operația de
scriere este efectuată, datele sunt scrise imediat în registrul Commit Log . Acesta reprezint ă un
mecanism de recuperare a datelor. Operația de scriere nu va reuși până când nu este scrisă în
registrul Commit Log . Dacă baza de date se blochează sau se închide, registrul Commit Log se
asigură că datele nu sunt pierdute , astfel atunci când nodul începe să funcționeze, registrul este
citit în vederea recuperării datelor.
După ce datele sunt scrise cu success în registrul Commit Log , acestea se vor stoca
temporar și pe o structură de date rezidentă din memorie numită memTable. În momentul în
care structura rezidentă din memorie este plină (memTable) , atunci datele vor fi încărcate pe
disc în fișierul d e date SSTable , mai apoi fiind creat un nou memTable .

Fig. II. 6 Procesul de scriere/citire [7]
La fel c a în cazul procesului de scriere, în cazul procesului de citire clientul trimite
solicitările de citire nodului coordonator , iar acest nod coordonator atribuie cererea unui
serviciu proxyStorage. Când este trimisă o cerere de citire, la început sunt citite tabele le
memT able, care sunt foarte rapid e fiind stocate direct în memorie . Dacă nu se găsesc datele
necesare, Cassandra v a căuta în SSTable , procesul fiind mult mai lent deoarece accesul la disc
este mai lent decât accesul la memorie.

18
CAPITOLUL III. STUDIU COMPARATIV

În această lucrare urmăresc performanțele de procesare și rulare ale operațiilor CRUD
(create – read – update – delete), atât pentru baza de date relațională MySQL, cât și pentru o
bază de date distribuită NoSQL, Cassandra.
Acest studiu comparativ are la bază modul de creare al ce lor două baze de date , MySQL
și Cassandra, precum și analizarea performanțelor acestoră prin prisma rulării comenzilor
aferente operațiilor de bază prin intermediul cărora datele sunt stocate în baza de date, iar mai
apoi manipulate astfel încât să se obțină rezultatele dorite.
În vederea realizării acestui studiu com parativ și pentru a analiza performanțele de
rulare ale operațiilor de bază CRUD, am realizat diverse interogări, atât pe baza de date
relațională MySQL, cât și pe baza de date Cassandra. Interogările s -au efectuat în mai multe
etape astfel : am început pri n analizarea performanțelor celor două baze de date prin executarea
unei singure interogări, după care am trecut la analizarea performanțelor celor două baze de
date prin executarea a unor comenzi SQL/CQL pe volume diferite de date : 10, 50, 100, 500,
1000 , 5000 și 10000 înregistr ări. Analiza testelor efectuate o voi prezenta în cele ce urmează
prin intermediul a diferite grafice, astfel ne putem da seama cu ușurință despre modul de rulare
și performanțele celor două baze de date atunci când vine vorba de efectuarea unei singur e
operații sau de efectuarea mai multor operații simultane pe volume mai mari de date.
Pentru a afectua testele propuse anterior, atât pentru baza de date MySQL, cât și pentru
Cassandra voi realiza o bază de date ce prevede înregistrar ea și gestionarea cărților dintr -o
bibliotecă, astfel se vor putea înregistra diferite cărți ce vor avea o structură bine definită și se
vor putea manipula prin operații de citire, modificare și respectiv ștergere a acestora din baza
de date.

III.1 INSTA LAREA MYSQL ȘI CASSANDRA

Pentru gestionarea bazei de date relaționale MySQL, am folosit programul XAMPP , un
program software open -source ce poate fi descărcat și utilizat pe orice sistem de operare, fie el
Linux, fie Windows, în mod gratuit. XAMPP are în alcătuire atât un server pentru baza de date
MySQL v5.7.30 (database server) , cât și un web server HTTP “Apache”. În plus, oferă
posibilitatea gestionării bazei de date direct din interfața phpMyAdmin. Această interfață este

19
avantajoasă din punct d e vedere al simplității, drept urmare se pot realiza operații CRUD
(create – read – update – delete) asupra bazei de date direct din această interfață.
Pentru rularea bazei de date distribuite Cassandra, trebuie îndeplinite două cerințe:
instalarea pe sist emul de calcul al Java JDK, respectiv instalarea Python pentru a putea folosi
comanda proprie cqlsh (Cassandra Query Language Shell). Dacă cele două programe software
sunt instalate atunci se poate descărca în mod gratuit Apache Cassandra v2.0.10 . La fel c a și în
cazul bazei de date MySQL, Cassandra poate să ruleze indiferent de sistemul de operare folosit.

III.2 PROIECTAREA BAZELOR DE DATE

Primul pas în proiectarea bazelor de date ce st au la baza studiului comparativ între
MySQL și Cassandra, const ă în realizarea structurii bazei de date, crearea tabelelor necesare
efectuării testelor de performanță și stabilirea relațiilor dintre tabele, acest pas ajutând ulterior
la gestionarea și manipul area cât mai ușoară a datelor .
În vederea creării unei baze de date trebuie să ținem cont de toate aspectele necesare,
de ceea ce vrem cu adevărat să dezvoltăm prin tr-o aplicație, de toate necesitățile pentru ca mai
apoi să gestionăm și să manipulăm datel e înregistrate cu ușurință.
După cum am prezentat anterior, cele două baze de date utilizate în vederea realizării
acestui studiu comparativ va permite stocarea unor cărți, respectiv manipularea acestora
precum se întâmplă în cazul unei biblioteci. Drept u rmare, pentru aceasta am creat o bază de
date numită “library”.
Înainte de a începe crearea bazelor de date, trebuie să cunoaștem cu exactitate cum
dorim să stocăm datele și să le manipulăm ulterior, de ce tabele avem nevoie în vederea stocării
datelor, ca re sunt câmpurile aferente fiecărei tabele, astfel trebuie să modelăm tabelele cu toate
câmpurile acestora . Inițial, structura bazei de date a fost schițată sugestiv pe o hârtie, după care
a fost realizată atât în MySQL, cât și în Cassandra.
Încă de la mo delarea datelor remarcăm o primă mare diferență între bazele de date
ralaționale și cele distribui te. Dacă în cazul bazei de date MySQL putem crea diferite tabele
care să relaționeze între ele prin efectuarea de comenzi de tip join între cheia primar ă (primary
key) al tabelei secundare și cheia străină (foreign key) al tabelei principale , Cassandra nu
permite astfel de legături, drept urmare, dacă în MySQL pentru a realiza baza de date “library”
am creat 4 tabele: book (ce va stoca toate c ărțile ), author (stochează numele autorilor),
publisher (stochează denumirea editurii) și type (ce va stoca denumirea genului ), în baza de
date distribuită Cassandra, nefiind permisă crearea de relații între tabele, a fost necesar ca toate

20
datele să le stochez în d oar o singură tabelă numită “ book ” în care se va specifica direct numele
autorului, editura și genul cărților înregistrate .
În MySQL, pentru a crea baz a de date “library” am utilizat direct interfața
“phpMyAdmin” pus ă la dispoziție de către programul XAMP P așa cum am specificat mai sus ,
astfel am creat 4 tabele, fiecare având propriile câmpuri (coloane) ce vor stoca diverse
informații :
• Tabela book – utilizată pentru a reține informațiile cărților înregistrate în baza de date,
precum titlul cărții, numele autorului și a editurii respectivei cărți, anul în care a fost
publicată cartea, numărul total de exemplare din cartea respectivă, cât și detalii
referitoare la genul sau tipul cărții (de exemplu poezie, proză, IT) . Numele autorului,
a editurii și a tipul ui cărții vor fi luate din tabelele aferente acestora. Acest lucru este
posibil datorită celor trei chei externe (foreign key) authorId, publisherId, typeId.

• Tabela author – reține informațiile cu privire la numele autorilor, care prin cheia
externă authorId din tabela book vor fi atribuite cărților înregistrate în sistem.

• Tabela publisher – conține informații referitoare la numele editurilor, care prin cheia
externă publi sherId din tabela book vor fi atribuite cărților înregistrate în sistem.

• Tabela type – conține informații cu privire la genul sau tipul cărții (de exemplu poezie,
proză, IT), care prin cheia externă typeId din tabela book vor fi atribuite cărților
înregistrate în baza de date.
Folosind Cassandra, crearea bazei de date și a tabelelor este diferită față de MySQL. În
primul rând Cassandra nu oferă o interfață intuitiv ă precum oferă MySQL, astfel crearea bazei
de date am realizat -o utilizând propria linie de comandă furnizată în mod implicit de Cassandra .
Această linie de comandă poartă numel e de “cqlsh” (Cassandra Query Language Shell) și poate
fi utilizată pentru a defini schema bazei de date, pentru a crea tabelele și coloanele aferente lor
și pentru a insera și manipula datele prin diverse comenzi la fel ca și în cazul MySQL .
Pornirea ser ver-ului Apache Cassandra se realizeaz ă prin rularea executabilului
“cassandra”, astfel prin intermediul Command Prompt putem rula direct comanda
cassandra . În urma rulării executabilului cassandra, vom putea utiliza și comenzile cqlsh.
Crearea bazei de d ate Cassandra “library” se realizeaz ă diferit față de MySQL,
deoarece baza de date propriu -zisă din MySQL, este reprezentată prin keyspace în Cassandra.

21
Un keyspace reprezintă un obiect care deține familiile de coloane, tipurile definite de
utilizator. Folosind Cassandra, un keyspace este similar cu baza de date RDBMS. Keyspace
deține familii de coloane, indexuri, tipuri definite de utilizator, strategia folosită precum și
factoru l de replicare. Pentru crearea keyspace -ului “library”, am rulat în cqlsh următoarea
comandă :
CREATE KEYSPACE library WITH replication = {'class':
'SimpleStrategy', 'replication_factor': 3}
După cum am prezentat în subcapitolul II.2.4 intitulat “Replica rea datelor ”, întâlnim
două componente esențiale atunci când dorim să creăm un keyspace, astfel întâlnim strategia
de replicare a datelor și factorul de replicare al datelor.
Există două tipuri de strategii de replicare : “simple strategy ” și “network topology
strategy ”. Simple strategy este utilizată atunci când avem doar un centru de date. În această
strategie, prima replică este plasată pe nodul selectat , iar nodurile rămase sunt plasate în sensul
acelor de ceasornic în inel . Cea de a doua strategie, n etwork topology strategy este folosită în
cazul în care avem mai mult e centre de date. În această strategie, trebuie să furniz ăm separat
factorul de replicare pentru fiecare centru de date. [9]
Factorul de replici reprezintă numărul total de re plici plasate pe noduri diferite, astfel
un factor de replicare înseamnă că există o singură copie de date, în timp ce trei factori de
replicare semnifică existența a trei copii ale datelor pe trei noduri diferite. Pentru a asigura că
nu există un singur p unct de eșec, factorul de replicare ar trebui să fie cât mai mare, așa cum
am precizat și în subcapitolul II.2.4 .
Concret, pentru keyspace -ul ‘library’ creat, am utilizat strategia simple strategy,
deoarece am un singur centru de date, și anume propriul ca lculator ce servește ca server, iar
factorul de replicare este 3 semnificând că voi avea 3 copii de siguranță ale datelor.
Așa cum am prezentat anterior, Cassandra nu oferă posibilitatea de a stabili relații între
două sau mai multe tabele diferite precum o face MySQL, drept urmare dac ă în cazul MySQL
am creat 4 tabele diferite pentru stocarea datelor, în Cassandra voi crea doar o singură tabelă
“book ” care va include atât numele autorului, cât și denumirea editurii și a genului de încadrare
a respectivei cărți .
Înainte de a începe crearea tabelelor aferente celor două baze de dat e, în Cassandra
trebuie să se specifice keyspace -ul ce va fi utilizat în vederea stocării datelor, acest lucru
realizându -se prin comanda cqlsh use library , asa cum este prezentat în figura III.1 de
mai jos , astfel linia de comandă va indica keyspace -ul pe care se va lucra în continuare, evitând

22
astfel ambiguitatea și eventualele erori în cazul în care avem definite și alte spații cheie de lucru
(keyspace).

Fig. III.1 Alegerea spațiului de lucru
Crearea tabelei book am realizat -o prin rularea următoarei co menzi cqlsh :
CREATE TABLE book (
id int PRIMARY KEY,
title text, author text ,
publisher text, type text,
publishingYear int,
totalNumber int
);
În cazul de față, din cele menționate anterior, folosind Cassandra informațiile vor fi
înmagazinate doar în tabela book, o singură tabelă ce va îngloba atât titlul unei cărți, anul
publicării, numărul total de exemplare, cât și numele autorului, denumirea editurii și a genului,
întrucât bazele de date distribuite nu permit stabilirea de rela ții între tabele prin cheia primar ă
a unei tabele și cheia străină a altei tabele, astfel schema structurării datelor trebuie regândită
dacă se dorește migrarea de la o bază de date relațională, la o astfel de bază de date distribuită,
precum în cazul Cassandra.
Figura III.2 ilustrează schema celor două baze de date, în cazul MySQL vom remarca
cele 4 tabele interconectate între ele prin stabilirea de relații, iar în cazul Cassandra datele vor
fi structurate doar într -o singură tabelă.

Fig. III.2 .a. Fig. III.2.b .
Structura bazei de date M ySQL Structura bazei de date Cassandra

23
Vizualizarea tuturor tabelelor create în baza de date și structura fiecărei tabele în
MySQL se realizează foarte simplu prin interfața intuitivă phpMyAdmin, așa cum este
prezentat în figura III.3 de mai jos.

Fig. III.3 Vizualizarea tabelelor în MySQL
Neavând o interfață intuitivă la fel ca în cazul MySQL, în Cassandra, vizualizarea
tabelelor din spațiul de lucru (keyspace) se realizează tot cu ajutorul comenzilor cqlsh conform
figurii III. 4 , în cazul de față în keyspace -ul “library” am definit o singură tabelă “book”:

Fig. III.4 Vizualizarea tabelelor în Cassandra

III. 3 TESTE DE PERFORMAN ȚĂ

Pentru realizarea testării și analiza testelor de performanță ale celor două baze de date,
MySQL comparativ cu Cassandra, s -au efectuat diverse operații pe cele două baze de date.
Aceste ope rații sunt cele patru operații de bază care pot fi efectuate pe orice bază de date, și
anume operațiile CRUD : crearea (inserarea) înregistrărilor, citirea acestora, modificare a
(actualizare a) lor și nu în ultimul rând ștergerea acestora definitivă din baza de date. Pentru o
mai bună analiză a testelor, cele patru operații le -am efectuat atât pentru o înregistrare, cât și
pentru 10, 50, 100, 500, 1000 , 5000 și 10000 înregistrări.
Deoarece rezultatele testelor depind de sistemul de calcul pe care sunt efectua te acestea ,
este important de reținut că toate testele și rezultatele obținute în urma testărilor au fost rulate
pe un sistem de calcul (laptop) personal care prezintă următoarele caracteristici: Windows 10
Pro pe 64 de biți, procesor Intel Core i 5 (2,4 GHz), 4 GB memorie RAM și 256 GB memorie
SSD.

24
III.3. 1 INSERT – operația de adăugare a datelor

În urma creării celor două baze de date și a tabelelor aferente acestora prezentate în
subcapitolul III.2, am realizat pentru baza de date MySQL un script PHP care, în urma rulării
acestuia, va executa operațiile cerute, în cazul de față va realiza inserarea unei înregistrări în
baza de date. În acest caz, conexiunea cu baza de date “library” se realizeaz ă conform
următoarei secvențe de cod:
$serverna me = "localhost";
$username = "root";
$password = "";
$dbname = "library";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn ->connect_error) {
die("Connection failed: " . $conn ->connect_error);
}
echo "Connected successfully";
Secvența de cod de mai sus realizează conexiunea cu baza de date, în cazul în care apar
probleme de conexiune, atunci va returna un mesaj de eroare care atenționează că respectiva
conexiune nu a avut loc, î n caz contrar va afișa mesajul “Connected successfully”.
Pentru a monitoriza timpul de execu ție al operațiilor CRUD și pentru ca la final să pot
interpreta fără probleme r ezultatele obținute, în MySQL am utilizat funcția PHP microtime
care înregistrează ti mpul de la începutul rulării scriptului până la finalizarea acestuia, funcție
prezentată în cele ce urmează :
$start = microtime(true);
–– (script pentru operațiile CRUD) ––
$end = microtime(true);
echo "Execution time :" . number_format($end – $start, 3) . "seconds";
Deoarece, în MySQL avem 4 tabele, interconectate între ele prin stabilirea de relații,
înainte de a introduce o nouă carte în baza de date, trebuie să luăm în calcul tabelele author,
publisher și type. Cheia primară a acestor tabele face legătura cu cheile străine din tabel a
principală book, drept urmare în scriptul PHP realizat am interogat mai întâi tabelele adiacente
(author, publisher și type) pentru a afla și mai apoi a atribui în mod aleator câte un id fiecărei
cărți înregistra te. Secvența de cod ilustrată mai jos reprezintă modul în care preiau datele din
tabelele de legătură pentru ca mai apoi să le atribui în mod aleatoriu cărților introduse :
$publisherQuery = "SELECT id FROM publisher";

25
$typeQuery = "SELECT id FROM type";
$authorQuery = "SELECT id FROM author";
$publisherResults = $conn ->query($publisherQuery);
$publisherList = $publisherResults ->fetch_all(MYSQLI_ASSOC);
$typeResults = $conn ->query($typeQuery);
$typeList = $typeResults ->fetch_all(MYSQLI_ASSOC);
$authorResults = $conn ->query($authorQuery);
$authorList = $authorResults ->fetch_all(MYSQLI_ASSOC);
Pentru adăugarea a mai multor înregistrări conform testelor efectuate, am folosit clauza
for, așa cum se prezintă în secvența de cod următoare :
for ($i = 1; $i <= 5000; $i++) {
$publisherRandom = $publisherList[array_rand($publisherList)]
['id'];
$typeRandom = $typeList[array_rand($typeList)]['id'];
$authorRandom = $authorList[array_rand($authorList)]['id'];
$bookInsert =
"INSERT INTO book (title, publisherId, publishingYear,
typeId, totalNumber, authorId)
VALUES (concat('Book title ', $i), $publisherRandom,
2020, $typeRandom, 20, $authorRandom)";
$result = $conn ->query($bookInsert);
}
În ceea ce privește inserarea datelor în baza de date distribuită Cassandra, această
operație am realizat -o prin rularea comenzilor proprii cqlsh . Astfel, asemănător cu sintaxa SQL
este și sintaxa CQL pentru inserarea unei noi înregistrări în baza de date doar cu o singură
precizare : în cazul în care se inserează un singur element în baza de date, atunci comanda cqlsh
este asemănătoare cu cea SQL și anume :
INSERT INTO book (id, author, publisher, publishingYear, title,
totalNumber, type)
VALUES (1, 'Author name', 'Publisher name', 2020,'Book title1', 10,
'Type name');
Însă, pentru a înregistra mai multe cărți în baza de date folosind linia de comandă cqlsh,
nu este permisă utilizarea clauzei for precum în cauzul de mai sus, cel al scriptului PHP folosit
pentru ba za de date MySQL, drept urmare pentru a introduce mai multe înregistrări, Cassandra
dispune de BATCH. Cassandra BATCH este utilizat pentru a executa mai multe instrucțiuni
de introduce re, actualiza re sau șterge re simultan e. Pentru a înregistra două sau mai multe cărți
se apelează următoarea secvență ilustrată în figura III.5 :

26

Fig. III.5 Executarea mai multor instrucțiuni în Cassandra
La fel ca și în cazul bazei de date MySQL, trebuie să monitorizez timpii de execuție al
operațiilor CRUD efectuate, astfel și Cassandra dispune de o comandă cqlsh care înregistrează
și afișează timpul de execuție al fiecărei operație. Această comandă cqlsh este : tracing on .
Figura III.6 ilustrat ă în cele ce urmează , reprezintă timpul de execuție al unei singure
înregistrări, timp surprins prin activarea comenzii tracing on. După cum îi spune și numele,
această comandă nu doar că afișează timpii de execuție al unui query, ci și pașii pe care îi
parcurge respectiva în registrare începând de la rularea comenzii până la finalizarea procesului.
Concret, după cum se poate remarca în imagine, timpul de execu ție al unei comenzi de inserare
este de 0.001447s.
Prin această figură se poate observa și mecanismul de scriere al dat elor în baza de date
Cassandra, astfel datele sunt înscrise în registrul Commit Log, iar mai apoi sunt păstrate
temporar într -o structură de date rezidentă din memorie memTable. Acest mecanism este
detaliat în subcapitolul II.2.5 intitulat “Operațiile de s criere/citire ”.

Fig. III.6 Cassandra tracing on (timpii de execuție al unei înregistrări)
După cum am menționat pe parcursul acestei lucrări, pentru a scoate în evidență
performanțele celor două baze de date din punct de vedere al timpului de execuție al operațiilor
CRUD de bază, am realizat aceste operații pentru o singură înregistrare, 10, 50, 100, 500, 1000,
5000 și 10000 de astfel de înregistrări , rezultatul acestora fiind analizat conform graficelor

27
generate pe baza lor , grafice ce pot fi întâlnite în subcapitolele aferente fiecărei operații
studiate , în cazul acestui subcapitol graficul generat fiind ilustrat în figura III.7.
Pentru a putea interpreta cu ușurință graficele rezultatelor obținute în urma efectuării
testelor, ne vom folosi de cele două axe ale acestora , astfel axa Ox va afișa cantitatea de date
(numărul înregistrărilor) pe care se operează , iar ax a Oy va conține timpii de execuție exprimați
în secunde ale tuturor operațiilor efectuate.
În ceea ce privește rezultatul rulării operațiilor de inserare atât pentru baza de date
relațională MySQL, cât și pentru baza de date distribuită NoSQL Cassandra, g raficul ilustrat
în figura III.7 de mai jos va indica faptul că operați a de introducere a datelor în bazele de date
este mai eficientă din punct de vedere al timpului de execuție pentru baza de date Cassandra ,
astfel cu cât se realizează inserarea a mai mu ltor date , cu atât se va observa că timpul de
execuție pentru baza de date Cassandra este mai eficient (mai mic) decât timpul de execuție al
acelorași înregistrări , dar executate pentru baza de date MySQL.

Fig. III.7 Performan ța opera ției INSERT – timp de execu ție (Sec)
După cum se remarcă în graficul ilustrat prin figura III.7, operația de inserare în rândul
bazei de date Cassandra este mult mai eficientă în comparație cu aceeași operație doar că în
rândul bazei de date MySQL , astfel se constată că la introducere a în sistem a 10000 de cărți,
operația de inserare în baza de date relațională durează aproximativ 10 secunde, pe când în ceea
ce privește baza de date distribuită Cassandra, această operație de introducere a cărților este
mult re dusă, astfel aceast a se întinde pe doar 0.253 secunde.
1 10 50 100 500 1000 5000 10000
MySQL 0.006 0.023 0.084 0.172 0.623 1.096 10.636 9.988
Cassandra 0.0005 0.001 0.004 0.01 0.021 0.03 0.094 0.2530246810SecundeINSERT
timp de execu ție
MySQL Cassandra

28
În primul rând această eficiență se datorează neexistenței relațiilor între tabele pentru
Cassandra, astfel în momentul în care se adaugă o nouă carte în baza de date, nu mai trebuie să
se verifice și să se aduca informațiile cu privire la autor, editură și genul de încadrare al
respectivei cărți, astfel toate aceste informații se vor scrie direct doar într -o singură tabelă
“book” fără a mai fi necesar să se verifice și alte condiții precum în cazul MyS QL, în care
înainte de a adăuga o carte se mai realizează și alte operații precum aducere a din baza de date
a autorilor, editurilor și genurilor de încadrare, toate aceste a fiind stocate în tabele separate de
tabela de bază “book”.
Concluzionând acest subc apitol, operația “insert” executat ă pe cele două baze de date
diferite este mult mai rapidă din punct de vedere al timpului de execuție în cazul bazei de date
Cassandra, astfel introducerea simultană a mai multor date se efectuează într -un timp mult mai
scurt.

III.3. 2 SELECT – operația de interogare a datelor

Odată ce cele două baze de date sunt populate cu date , se pot efectua și alte operații pe
aceste date. Cea mai folosită operație o reprezintă operația de interogare a datelor din baza de
date în scopul procesării și utilizării acestora fie pentru a întocmi diferite rapoarte cu privire la
o situație sau pentr u a le afișa în interfața unei aplicații , fie pentru a crea noi funcționalități sau
pentru a folosi aceste date în realizarea unei noi sarcini precum am folosit eu în cazul operației
de introducere a datelor în baz a de date MySQL, astfel pentru a introduce o carte în baza de
date, am fost nevoit să aduc datele din încă trei tabele precum “author”, “publisher” și “type”,
acestea din urmă fiind tabelele de legătură cu principala tabelă “book” , toate acestea afl ându –
se în relații de legătură stabilite între ch eia primară (primary key) a tabelelor adiacente și cheile
străine (foreign keys) ale tabelei “book ”.
Pentru a analiza performan țele din punct de vedere ale timpului de execuție a operației
“select” de interogare a datelor pentru cele dou ă baze de date studiate, aceasta s -a realizat, la
fel ca în cazul operației “insert” pentru 1, 10, 50, 100, 500, 1000, 5000 și 10000 de înregistrări .
În cazul bazei de date MySQL, datorită strânselor relații de legătură între cele patru
tabele, pentru aduc erea și afișarea tuturor datelor stocate pentru o carte trebuie să se realizeze
operația de JOIN aplicat ă tabelelor, astfel încât în momentul în care se dorește afișarea unei
cărți din sistem, să se aducă respectiva carte cu tot cu numele autorului, denumi rea editurii și a
genului de încadrare. Pentru a realiza acest lucru, am utilizat secvența de cod scrisă în PHP

29
ilustrată mai jos care presupune comanda “select” de interogare a patru tabele: tabela de baz ă
book și trei tabele de legătură publisher, type ș i author :
$sql = “SELECT b.title, p.name AS publisherName, t.name AS typeName,
a.name AS authorName, b.publishingYear, b.totalNumber FROM book b
LEFT JOIN publisher p ON b.publisherId = p.id
LEFT JOIN type t ON b.typeId = t.id
LEFT JOIN author a ON b.authorId = a.id ”;
$result = $conn ->query($sql);
echo ‘<pre/>’;var_dump($result ->fetch_all(MYSQLI_ASSOC));
În secvența de cod prezentată, pentru fiecare dintre cele patru tabele am utilizat alias –
uri, astfel cu ajutorul acesto ra știm cu exactitate ce câmpuri din cele patru tabele vom referi.
Așa cum am specificat anterior, legătura dintre aceste tabele se realiează conform comenzii
LEFT JOIN care specifică tabelele de legătură și modul în care acestea colaborează, astfel
câmpul “id” (primary key) al tabelelor secundare “author”, “publisher”, “type” este acela și cu
cele trei câmpuri de legătură (foreign key) “authorId”, “publisherId”, “typeId” al tabelei de
bază “book” , în final afișându -se în browser toate cărțile din baza de d ate cu detaliile aferente.
În ceea ce privește baza de date distribuită Cassandra, lucrurile vor sta puțin diferit,
deoarece conform acest or baze de date nu se permite realizarea de condiții JOIN, astfel toate
informațiile cu privire la o carte vor fi stocate într -o singură tabelă, iar operația “select” va fi
scrisă în cqlsh într-o variantă mai simpl istă precum în secvența de cod de mai jos :
SELECT * FROM book;
În cazul liniei de comandă cqlsh, dacă există mai mult de 100 de înregist rări, rezultatele
afișării vor fi distribuite pe pagini multiple, fiecare pagină conținând doar 100 de înregistrări.
Pentru a monitoriza timpul de execuție al operației “select” din cadrul bazei de date Cassandra,
avem nevoie ca toate înregistrările să fie afișate direct într -o pagină, astfel cqlsh vine cu o
comandă care va dezactiva paginarea, această comandă fiind : paging off . Dezactivând
paginarea, toate cărțile vor fi afișate în browser , indiferent dacă numărul lor este mai mare de
100. Efectuând operaț ia “select” în cadrul Cassandra, toate înregistrările cărților împreună cu
detaliile aferente lor , vor putea fi vizualizate în linia de comandă cqlsh precum în figura III.8

Fig. III.8 Vizualizarea datelor înregistrate în Cassandra

30
În cele ce urmează, prezint graficul ce ilustrează comparația celor două baze de date
privind timpul de execuție al operației de interogare a datelor (select) în cazul uneia și a mai
multor înregistrări.

Fig. III.9 Performan ța opera ției SELECT – timp de execu ție (S ec)
Conform rezultatelor obținute în urma testării, se poate observa faptul că timpul de
execuție aferent operației “select” de obținere a tuturor înregistrărilor stocate în cele două baze
de date este din nou mai mic în ceea ce privește Cassandra. Dacă în cazul MySQL, pentru a
obține o singură carte timpul de execuție este de 0.003 secunde, iar pentru a obține 10000 cărți
timpul tinde spre 0.151 secunde, în cazul Cassandra rezultatele sunt diferite , astfel pentru
obținerea unei înregistr ări avem nevoie de 0.00 05 secunde, iar pentru a obține 10000
înregistrări timpul crește la aproximativ 0. 132 secunde.
Pentru a concluziona și acest subcapitol, rezultatele obținute pentru operația “select” în
cazul celor două baze de date din punct de vede re al timpului de execuție este net superior în
rândul Cassandra, atât pentru obținerea a numai cât orva cărți, cât și pentru a obține mai multe
înregistrări. Cu toate că pentru utilizator, cel care solicită datele cu scopul de a le afișa sau de
a efectua diverse operații asupra lor, s -ar putea ca timpul de execuție al acestor instrucțiuni să
fie insesizabil, se poate remarca faptul că operația “select” este mult mai eficientă în rândul
bazei de date distribuite Cassandra, comparativ cu baza de date relațională MySQL , fapt ce o
încadrează în rândul bazelor de date rapide și puternice, des întâlnite în cadrul aplicații lor care
rulează simultan operații de ordinul zecilor de mii sau chiar al milioanelor precum Facebook
sau Netflix (mari aplicații care utilizează Cassandra ca bază de date).

1 10 50 100 500 1000 5000 10000
MySQL 0.003 0.003 0.006 0.008 0.014 0.027 0.121 0.151
Cassandra 0.0005 0.0005 0.001 0.002 0.007 0.016 0.049 0.13200.050.10.15SecundeSELECT
timp de execu ție
MySQL Cassandra

31
III.3. 3 UPDATE – operația de actualizare a datelor

Modificarea sau actualizarea datelor reprezintă o operație necesară de bază când avem
de lucru cu datele deja stocate , deoarece fie nu am înregistrat corect datele, fie pe parcurs apar
diverse modificări cu privire la acestea, drept urmare pentru a nu șterge cu totul respectiva
înregistrare și a o crea din nou cu datele corectate, se apelează la operația de “update”, oper ție
ce actualizează datele deja existente cu n oile valori ale acestora.
În cazul de față, pentru a compara performanțele celor două baze de date MySQL și
Cassandra din punct de vedere al timpului de execuție voi realiza operația “update”, la fel ca
celelalte operații de mai sus, pentru un set de opt volume de date , la final reprezentând grafic
și interpretând rezultatele obținute în urma testelor efectuate.
Pentru cele două baze de date, studiul performanței din punct de vedere al timpului de
execuție este realizat prin modificarea anului publicării fi ecărei cărți, adică modificarea
câmpului “publishingYear” al tabelei “book”.
Realizarea automat ă a actualizărilor prezentate pentru baza de date MySQL a fost
efectuată tot cu ajutorul limbajului PHP, asemeni celorlalte operații deja prezentate în
subcapito lele anterioare, astfel următoarea secvență de cod este utilizată pentru a modifica anul
publicării cărților înregistrate în sistem :
$sql = "UPDATE boo k SET publishingYear = 3000 WHERE id > 0";
$result = $conn ->query($sql);
echo '<pre/>'; var_dump ($result);
În conformitate cu secvența de cod ilustrată, după executarea operației , utilizatorului i
se va afișa valorile booleene true sau false după cum urmează : “true” dacă operația s-a efectuat
cu succes sau “false” în caz contrar.
La fel ca în cazul b azei de date MySQL, folosind Cassandra instrucțiunea “update”
poate modifica una sau mai multe coloane a unei înregistrări din tabel prin parametrul “set”.
Ceea ce face ca baza de date Cassandra să fie diferită față de MySQL din punct de vedere al
sintaxei în cazul operației de modificare al datelor este clauza “where”, condiți e care trebuie să
fie îndeplinită pentru ca datele să se actualizeze, astfel neaparat clauza “where” trebuie să
includ ă cheia primară a respectivei tabel e, în cazul de față câmpul “id ” al tabelei “book” .
În plus, o altă diferență față de baza de date MySQL o reprezintă faptul că instrucțiunea
“update” nu verifică în mod implicit existența anterioară a unei înregistrări, astfel dacă nu există
o înregistrare care să se potrivească condiției impuse, în Cassandra se va crea o nouă
înregistrare cu datele propuse modificării. Desigur, dac ă se dorește ca totuși să nu se creeze o

32
nouă înregistrare în cazul în care condiția operației “update” nu este îndeplinită , se poate apela
la următoarea secvență de cod care se va executa doar dac ă clauza “where” este satisf ăcută :
UPDATE book SET publishingYear = 2020 WHERE id = 30000 IF EXISTS;
În cazul Cassandra, dacă se dorește a se actualiza mai mult de o înregistrare / o carte în
baza de date, atunci acest proces diferă față de MySQL, deoarece clauza “where” nu permite
utilizarea operatorilor: >, >=, <, <= , “between ”, astfel pentru a modifica simultan mai multe
înregistrări va trebui utilizat operatorul “IN”.
De exemplu, în cazul de față pentru a modifica anul publicării tuturor cărților care au
id-ul mai mare de 0 și mai mic decât 6 se va apela la următoarea secvență de cod cqlsh:
UPDATE book SET publishingYear = 2020 WHERE id IN (1,2,3,4,5);
Pentru a studia performan țele celor două baze de date MySQL și Cassandra din punct
de vedere al timpului de execuție, am rulat operația “update”, la fel ca și operațiile anterioare
(insert și select ) pentru 1, 10, 50, 100, 500, 1000, 5000, 10000 înregistrări , iar rezultatele
obținute s unt ilustrate în următorul grafic ul din figura III.10.
Interpretând rezultatele obținute în urma testelor efectuate, se poate remarca faptul că
baza de date Cassandra este din nou într -un avantaj semnificativ față de MySQL, întrucât
timpul de execuție al o perației de actualizare a datelor în cazul bazei de date distribuite este net
superior timpului de execuție a l aceleiași operații în cazul bazei de date relaționale , astfel dacă
pentru a modifica anul publicării a 10000 de cărți în Cassandra am avut nevoie de aproximativ
0.047 secunde, pentru MySQL această operație s -a întins până la 0. 085 secunde.

Fig. III.10 Performan ța opera ției UPDATE – timp de execu ție (Sec)
1 10 50 100 500 1000 5000 10000
MySQL 0.002 0.002 0.005 0.008 0.007 0.01 0.033 0.085
Cassandra 0.0002 0.0003 0.0004 0.0009 0.006 0.012 0.025 0.04700.020.040.060.08SecundeUPDATE
timp de execu ție
MySQL Cassandra

33
Dacă stăm să analizăm o eventuală previziune a timpilor de execuție în ceea ce privește
operația de modificare a datelor de ordin mai mare decât cel studiat, vom constata cu precădere
că pe măsură ce se lucrează cu un nivel mai mare de date , Cassandra are un randament mult
mai mare din punct de vedere al timpului de execuție, astfel în gener al, eficiența bazelor de
date distribuite se poate întrevedea la operații de ordin mare, întrucât timpul de așteptare pentru
operații de ordin mic va fi pentru utilizator insesizabil, desi și în cazul unei actualizari a 10
înregistrări din sistem se poate observa că MySQL se întinde până la 0.002 secunde pentru
rularea instrucțiunii “ update ”, în timp ce Cassandra atinge un timp de aproximativ 0.0003
secunde. Însă toate aceste valori nu sunt percepute de utilizator, dar pentru operații de ordin
mare, cu sigu ranță nu este tot una un timp de execuție mare comparativ cu un timp de execuție
mic.
Realizând un sumar al acestui subcapitol, procesul de actualizare al datelor în cazul
celor două baze de date este diferit din punct de vedere al timpului de execuție, de oarece bazele
de date distribuite, inclusiv Cassandra, au fost proiectate pentru a putea gestiona și manipula
cantități însemnate de date într -un timp cât mai scurt, deoarece în ziua de astăzi aplicațiile nu
se limitează la doar câteva funcționalități, ci ele tind spre îndeplinirea a mai multor funcții
pentru a le face mai atractive și mai folositoare, respectând totodată cerințele utilizatorilor.

III.3.4 DELETE – operația de ștergere a datelor

Ultima operație de bază utilizată în gestionarea și manipularea datelor înregistrate în
baza de date, o reprezintă operația “delete”, operație care va elimina datele permanent din baza
de date. Aceast ă operație este mai rar utilizată în rândul aplicațiilor web, deoarece întotdeauna
este bine venit să avem un istoric al activităților noastre.
De regulă, operația de ștergere a datelor în rândul a numeroase aplicații este înlocuită
cu operația de modificare a acestora, astfel în cazul în care se dorește a se șterge o înregistrare,
de fapt se execută o modificare a unui câmp, de regulă “isActive”, iar în cazul în care acest
câmp este 1, înregistrarea este vizibilă, iar când acesta este setat la 0 , adică se dorește ștergerea
ei, înregistrarea nu mai poate fi uti lizată, fiind considerată de utilizatori ca ștearsă .
Însă pentru a studia performanțele celor două baze de date MySQL și Cassandra din
punct de vedere al timpilor de execuție, ștergerea datelor va fi executată în adevăratul sens al
cuvântului, adică datele odată șterse, vor fi eliminate definitiv din cele două baze de date, f ără
a mai avea astfel acces la ele.

34
Pentru a șterge toate înregistrările stocate în baza de date MySQL am utilizat
următoarea secvență de cod PHP:
$sql = "DELETE FROM book WHERE id > 0 ";
$result = $conn ->query($sql);
echo '<pre/>'; var_dump($result);
Precum în cazul operației “update” prezentată anterior, pentru a șterge toate
înregistrările mă voi folosi tot de id -ul fiecărei cărți stocate . Dacă operația de ștergere se
execută fără probleme, utilizatorului i se va afișa “true”, iar în caz contrar se va afișa “false”.
Pentru baza de date Cassandra, sintaxa opera ției “delete” este asemănătoare cu cea
folosită pentru baza de date MySQL, doar că se aplică regulile prezentate în subcapito lul
anterior, atunci când am prezentat modificarea datelor, astfel pentru a șterge una sau mai multe
înregistrări trebuie îndeplinite condițiile specificate în clauza “where”. De re ținut este faptul
că, la fel ca și în cazul operației “update”, clauza “whe re” trebuie s ă conțină cheia primară a
tabelei din care se dorește eliminarea definitivă a datelor, în cazul de față cheia primar ă a tabelei
“book ” fiind câmpul id. Desigur, și pentru a șterge mai mult de o înregistrare va trebui ca în
clauza “where” s ă se utilizeze operatorul “IN” , ceilalți operatori nefiind acceptați , drept urmare
pentru a șterge primele 5 înregistrări, se va utiliza următoarea secvență cqlsh :
DELETE FROM book WHERE id IN (1,2,3,4,5);
Pentru a studia timpii de execuție ai acestei ultime o perații de ștergere a datelor, am
rulat instrucțiunea “delete”, la fel ca în cazul celorlalte instrucțiuni , pentru un set de înregistrări,
iar rezultatele obținute în urma testării pot fi analizate din graficul prezentat în figura III.11
următoare :

Fig.III.11 Performan ța opera ției DELETE – timp de execu ție (Sec)
1 10 50 100 500 1000 5000 10000
MySQL 0.002 0.003 0.004 0.004 0.007 0.01 0.019 0.051
Cassandra 0.0002 0.0002 0.0004 0.0009 0.004 0.006 0.018 0.04100.020.04SecundeDELETE
timp de execu ție
MySQL Cassandra

35
În conformitate cu graficul de mai sus obținut în urma testelor efectuate, se poate
remarca din nou o diferență esențială a timpilor de execuție al aceleiași operații “delete”
efectuate pentr u cele două baze de date studiate MySQL și Cassandra, drept urmare se poate
sublinia performanțele ridicate ale bazei de date distribuite, comparativ cu cea relațională,
astfel pentru a șterge definitiv același număr de cărți atât din baza de date MySQL, c ât și din
Cassandra, cea din urmă obține timpi de execuție mai mici.
Concluzionând și acest subcapitol, baza de date Cassandra este net superioară bazei de
date MySQL în ceea ce privește timpii de execuție al operației “delete”, astfel un volum mai
mare de date este eliminat mai repede folosind Cassandra , decât același volum de date eliminat
utilizând MySQL .

36
CONCLUZII

După cum se poate observa în acest studiu comparativ din punct de vedere al
performanțelor între cele două baze de date, MySQL – o bază de date relațională și Cassandra
– o bază de date distribuită, există o esențială deosebire, și anume timpii de execuție al
operațiilor de creare, modificare, citire și ștergere a datelor stocate.
Deși cele două tipuri de baze de date folosesc aceeași sintax ă SQL doar cu mici
precizări precum în cazul în care condițiile clauzei “where” trebuie s ă conțină neaparat cheia
primară a tabelei r espective, bazele de date distribuite se desprind din rigorile relaționale prin
lipsa unei scheme în care tabelele cooperează între ele pe baza realizării relațiilor de legătură
dintre acestea folosindu -se cheile primare și cele str ăine.
Lipsa necesității de normalizare a datelor și de stocare a acestora prin relațiil e dintre
tabele aduc un beneficiu important bazei de date Cassa ndra și a bazelor de date distribuite în
general, deoarece nu se mai efectuează și alte operații secundare pe lângă cele dorite, drept
urmare performanțe le aplicațiilor care utilizează acest tip de baze de date sunt sporite .
De asemenea acest tip de baze de date îmbunătățesc și răspunsul la schimbări de -a
lungul timpului. Într -un sistem relațional nu există flexibilitatea necesară pentru a asimila
modificări în modelul de date. Faptul că bazele de date NoSQL nu au o schemă de date fixă
face aceste baze de date să fie mult mai flexibile și adaptabile la schimbări de model , de
exemplu într -o bază de date relațională dacă pe parcurs se dorește a se introduce un nou câmp
la o tabelă deja existent ă vor apărea unele probleme, în special dac ă aceste tabele comunică cu
altele prin intermediul relațiilor de legătură, pe când Cassandra permite modificarea structurii
tabelelor cu ușurință, deoa rece nu sunt strâns legate de nici o altă tabelă.
După cum am precizat în această lucrare, baza de date relațională MySQL este cea mai
utilizată bază de date în rândul aplicațiilor web statice precum un webiste , deoarece de exemplu
un website al unei compa nii nu necesită o rulare simultană excesivă a mai multor operații, dar
pentru aplicații mari, în care se efectuează zeci de mii sau chiar milioane de interogări pe
secundă (exemplu Facebook, Netflix, etc.) , timpul de operare și de răspuns al acestora este
esențial utilizatorilor , astfel o bază de date înceată nu va fi niciodată potrivită.
În concluzie, conform testelor efectuate ce stau la baza acestei lucrări, se dovedește că
baza de date distribuită Cassandra este mult mai eficientă decât baza de date relațională MySQL
din punct de vedere al timpilor de procesare și execuție al opera țiilor CRUD de bază .

37
BIBLIOGRAFIE

[1] Sheffi Gupta, Rinkle Rani , “Data Transformation and Query Analysis of Elasticsearch and
CouchDB Document Oriented Databases ”, Editura : Thapar University , 2016, (Roll No.
801431027) , Consultat la 20.06.2020.
[2] W. Jason Gilmore, “Beginning PHP and MySQL: From Novice to Professional, Fourth
Edition” , Editura: Apress, 2010, ISBN 978 -1-4302 -3115 -8, Consultat la 2 0.06.2020.
[3] http://zetcode.com/mysql/introduction/ , Consultat la 21.06.2020.
[4] https://www.tutorialspoint.com/mysql/mysql -introduct ion.htm , Consultat la 21.06.2020.
[5] http://blog.marc -seeger.de/assets/papers/Ultra_Large_Sites_SS09 –
Seeger_Key_Value_Stores.pdf , Marc Seeger , “Key -Value stores: a practical overview” ,
2009, Consultat la 04.07.2020 .
[6] https://rria.ici.ro/wp -content/uploads/2012/12/06 -art.-Ularu -si-Puican -reviz uit.pdf , Elena –
Geanina Ularu , Florina Puican , “Noua generație de baze de date NoSQL” , Editura: Revista
Română de Informatică și Automatică, vol. 22, nr. 4, 2012, Consultat la 04.07.2020.
[7] https://www.javatpoint.com/cassandra -features , Consultat la 05.07.2020.
[8] https://portfoliowebsite.piushvaish.com/data -analysis -resources/a -comparison -between –
cassandra -and-mysql/ , Consultat la 05.06 .2020.
[9] https://www.guru99.com/cassandra -architecture.html , Consultat la 05.07.2020.
[10] http://iahpc.ir/paperspdf/85.pdf , Seyyed Ali Hosseini, Fereshteh -Azadi Parand, Farzam
Matinfar, “Data processing in Cassandra vs MySQL: A comparative analysis in the query
performance” , 2018, Consultat la 25.07.2020.

DECLARAȚIE DE AUTENTICITATE A
LUCRĂRII DE FINALIZARE A STUDIILOR

Titlul lucrării: Analiza performanțelor bazei de date relaționale MySQL
comparativ cu baza de date No-SQL Cassandra

Autorul lucrării: Bacter Răzvan – Ioan

Lucrarea de finalizare a studiilor este elaborată în vederea susținerii
examenului de finalizare a studiilor organizat de către Facultatea de Inginerie
Electrică și Tehnologia Informației din cadrul Universității din Oradea, sesiunea
septembrie a anului universitar 2019-2020.
Prin prezenta, subse mnat ul Bacter Răzvan – Ioan, CNP: 1950120055086 ,
declar pe proprie răspundere că această lucrare a fost scrisă de către mine, fără
nici un ajutor neautorizat și că nici o parte a lucrării nu conține aplicații sau studii
de caz publicate de alți autori.
Declar, de asemenea, că în lucrare nu există idei, tabele, grafice, hărți sau
alte surse folosite fără respectarea legii române și a convenții lor internaționale
privind drepturile de autor.

Oradea,
02.09.2020 Semnătura