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

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

ANALIZAREA 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:
ANALIZAREA PERFORMANȚELOR BAZEI DE DATE RELAȚIONALE MYSQL
COMPARATIV CU BAZA DE DATE NON -SQL CASSANDRA

2) Termenul pentru predarea lucrării: 03 iulie 20 20

3) Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor: baza de date
relațională MyS QL + limbaju l SQL, baza de date d istribuită Cassandra + limbajul CQL ,
limbajul PHP.

4) Conținutul lucrării de finalizare a studiilor: Introducere; MySQL – baza de date
relațională – Introducere în baza de d ate MySQL, Baze de date relaționa le, Operații SQL de
bază, Comanda CREATE , Comanda INSERT , Comanda UPDATE , Comanda SELEC T,
Comanda DELETE ; Cassandra – baza de date No-SQL – Introducere NoSQL , Introducere în
baza de date Cassandr a, Caracteristici Cassandra , Arhitectura Cassandra , Structura Cassandra ,
Replicarea datelo r, Operațiile de scriere/citire ; Studiu comparativ – Instalarea MySQL și
Cassandr a, Proiectarea bazelor de dat e, Teste de performanță , INSER T – operația de adăugare
a datelor , SELECT – operația de aducere a datelor , UPDATE – operația de actualizare a datelor ,
DELETE – operația de ștergere a datelo r; Concluzii; 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. MYSQL – BAZA DE DATE RELAȚIONALĂ ………………………….. …….. 5
I.1. INTRODUCERE ÎN BAZA DA 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. CASSANDRA – BAZA DE DATE NO -SQL ………………………….. ……… 10
II.1 INTRODUCERE NOSQL ………………………….. ………………………….. ……………………….. 10
II.2 INTRODUCERE ÎN BAZA DE DATE C ASSANDRA ………………………….. …………… 12
II.2.1 Caracteristici Cassandra ………………………….. ………………………….. …………………….. 12
II.2.2 Arhitectura Cassandra ………………………….. ………………………….. ……………………….. 13
II.2.3 Structura Cassandra ………………………….. ………………………….. ………………………….. 14
II.2.4 Replicarea datelor ………………………….. ………………………….. ………………………….. … 15
II.2.5 Operaț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ăug are a datelor ………………………….. ………………………… 23
III.3.2 SELECT – operația de aducere a datelor ………………………….. …………………………. 28
III.3.3 UPDATE – operația de actualizare a datelor ………………………….. ……………………. 30
III.3.4 DELETE – operația de ștergere a datelor ………………………….. …………………………. 33
CONCLUZII ………………………….. ………………………….. ………………………….. …………………….. 35
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ……………….. 36

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 debusolați, în special că genereația noastră a crescut concomitent cu
tehnologia.
Fiecare domeniu de activitate încearcă să își gesti oneze 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 a tinge scopul inițial.
Drept urmare, i ntroducerea mai multor resurse de calcul și aplicarea lor din ce în ce mai
mare a dat naștere 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 uriaș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
diferitelor 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 performanț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 la 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 Alexandria, dar luând în calcul situația de astăzi
referitoare la cantitatea de informați e prezentă în lume, dacă oricărei pe rsoane î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 stocării și înregistrării datelor s -a schimbat semnificativ, drept urmare, în prezent se
preconizează că doar 2% din cant itatea 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 gestiune , de exemplu al unei rafinării, în care preluarea
datelor se realizează din mai multe direcții precum senzori, sem nale GPS, adrese IP ale
diverselor calculatoare conectate etc. , iar la final va da un răspuns real și correct cu toate datele
realizând astfel un raport sau o statistică, baza de date relațională nu va fi îndeajuns, astfel se
va apela la o bază de date dis tribuită, care să fie capabilă să preia informații din mai multe
direcții și să formeze un tot unitar cu acestea.
Deja, aproape orice companie descoperă că trebuie nu doar să gestioneze volume de
date din ce în ce mai mari în sistemele lor în timp real, d ar ș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 companii în care riscul de a produce un impact violent asupra
comunității sau a mediul ui î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 mari de date înreg istrate și totodata afișate, în
prezenta lucrare de disertatie surpind o comparație între doua baze de date utilizate, o baza de
date relationala MySQL, utilizata în majoritatea aplicațiilor web, și o baza 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 “MySQL – baza de date rela țională ”
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
utilitățile acestui tip de bază de date.
Capitolul al doilea denumit “Cassandra – baza de date noSQL” 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 stocate utilizând operațiile de bază CRUD.
Cel de -al treilea capitol numit “ Studiu comparativ ” prezintă în detaliu statisticile
furnizate în urma rulării diverselor operații CRUD pe bazele de date prezentate, statistici
referitoare la timpul de procesare al operațiilor respective, precum și la modul de implementare
și rulare ale acestora.

5
CAPITOLUL I. MYSQL – BAZA DE DATE RELAȚIONALĂ

I.1. INTRODUCERE ÎN BAZA DA 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 asemenea, 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 cazul 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 struc turate conform
modelului relațional al lui 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 struct urate , astfel încât contribuie la buna desfăș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.
MyS QL reprezintă o componentă esențială a platformei 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, fiind open -source și având referințe bine definit e ș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 1 994 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
astăzi. MySQL are la bază limbajul de programare C/C++, dar există numeroase API -uri care

6
fac posibilă conexiunea și cu alte limbaje de programare precum PHP, Python, Java, C#, Ruby,
Perl etc.
MySQL oferă d oua versiuni disponibile: MySQL server system (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 propri e. [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ă fol osind 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 respective.
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 fiecar e î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ăin e (foreign keys). O cheie primară identifică în mod unic
fiecare înregistrare din tabel, de exemplu în majoritatea cazurilor, cheia primara a unei
înregistrări este evidențiată prin ID -ul înregistrării, ID ce se incrementează în mod automat cu
fiecare înre gistrare. Spre deosebire de cheia 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 unui î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 atribute 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 tabela “book”, nu vor putea exista mai multe
înregistrări cu același ID, acesta 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 în deplinește
următoarele puncte :
• Permite 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 “create” este utilizat ă pentru crearea atât a bazei
de date, cât și a tabelelor aferente acesteia. Pentru a crea o noua bază de date, se va folosi
următoarea coman dă, î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 aferent e unei baze de date se va utiliza comanda de mai jos în
care tabel _name reprezintă numele unei tabele în care se va înregistra datele, column1 ..

8
reprezint ă denumirea coloanei asociată fiecărui câmp al unei înregistrări, iar parametrul
datatype specifică ti pul de date înregistrate. Tipul de date poate fi de mai multe tipuri: de tip
șir de caractere (string), de tip numeric și de tip 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ța între inserarea de noi
date sau adăugarea lor. În ambele situatii, locul în care s e face adăugarea nu este precizat,
nefiind relevant.
La sistemele care nu sunt pur relaționale (cum estedBase sau FoxPro) operația de
adăugare semnifică adăugarea la sfârșitul unei tabele, pe când inserția înseamnă inserarea intre
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 comenzi “update” utilizatorul poate actu aliza (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ă
o anumită condiție.

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 al procesului
până l a punctul stabilit, fie al continuării procesului dacă acesta a atins deja limitele stabilite.

9
Comanda “select” poate fi apelat ă fie pe întreg tabelul din baza de date, fie doar pe
anumite câmpuri din acest tabel. Desigur se pot extrage informații și aplic ând anumite 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 efectuarea operației de extragere a
datelor doar dintr -o singură tabelă, însă limbajul SQL permite tot prin utilizarea acestei
comenzi, colectarea 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 realizează astfel :
SELECT column_name(s)
FROM table1
LEFT JOIN table2
ON table1.column_name = table2.column_n ame;

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. CASSANDRA – BAZA DE DATE NO -SQL

II.1 INTRODUCERE 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 pripriile
funcționalități, să formeze un tot unitar, o aplicație nouă care să poate permi te manipularea ș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 pana la
milioan e de utilizatori, 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 nivel în alt 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ă bazele de da te 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ă,
deoarece se realizeaza 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 cantităț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 reintr odus ș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 d ate relaț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 reprezi ntă faptul 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
multe funcționalități utilizatorilor. Pe măsura trecerii timpului, cantitatea de informații crește

11
exponențial astfel d ezvoltatorii trebuie să găsească soluții pentru ca o aplicație să suporte și să
poată manipula cantități mari de date.
Utlizatorii 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 as tfel 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 NoSQL 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
datelor, ignorând principiile RDBMS (Relational DataBase Management System). Într-o bază
de date NoSQL nu mai există o schemă p ropriu -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 cu privire la modul de stocare,
gestionare și de distribuire a informației către toți utilizatorii aplicației respective. Acesta
teoremă precizează trei 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 (Consistency) , disponibilitatea (Availability)
și toleranța partițiilor (Partition Tolerance) . Prima cerință asigură coerenț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 simultan într -un
sistem distribuit. Așa cum se arată în
figura II.1, bazele de date NOSQL
funcționează prin combinarea oricăreia
dintre aceste două cerințe.
Fig. II.1 Reprezentarea grafic ă a teoremei CAP

12
II.2 INTRODUCERE ÎN BAZA DE DATE CASSANDRA

Printre primele aplicații mari, ce au ridicat problemă 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 bazel or 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 d e “Cassandra”. A fost dezvoltat
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 nestru cturate 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. Aceas ta 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., utilizeaza Cassandra
ca bază de date.

II.2.1 Caracteristici 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ș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 fi furnizate 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;
• Stoca rea 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 da tele, 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 Ca ssandra

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 distribuite între toate no durile dintr -un cluster.

Fig. II. 2 Arhitectura Cassandra

14
După cum se poate remarca în figura II. 2 ilustrată mai sus, structura bazei de date
Cassandra are în compoziție următoarele :
• 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 centre
de date .
Fiecare nod este independent, dar în același timp este interconectat cu celelalte 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, cererile de citire s au scriere vor fi acceptate de către
celelalte noduri aflate în rețea.

II.2.3 Structura 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 modelul relațional rândurile nu a u î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 obiect a împrumutat câteva carac teristici 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 intitulata structurarea informației se prezintă modul în care o înregistrarea
este stocată în baza de date, astfel un tabel d in baza de date conține unul sau mai multe rânduri
specifice fiecărei înregistrari. La fel ca și în cazul bazei de date relaționale MySQL, Cassandra
stochează informația sub formă de rânduri definite prin coloane, fiecare coloana având o
valoare. În plus f ață 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
De exemplu, dacă dorim să stocăm informațiile unui utilizatorului î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ționale MySQL pentru valori pe care nu le cunoaștem,
trebuie să stocăm nul l, în Cassandra nu salvăm niciodată coloana dacă aceasta este null, astfel
tabel a “user” care are înregistrați 2 uti lizatori, 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ă [9]

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 mai 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 intervalul de coordonatori, solicitarea este trimisă celuilalt nod a cărui cheie este
asociată. [9]
Printre caracteristicile importa nte ale bazelor de date NoSQL se enumeră și toleranța la
defecte sau erori. Drept urmare un aspect important îl reprezintă capacitatea 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țiil or.
Aceasta 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ă ga rantarea disponibilității într -o
defecțiune a nodului. În plus, replicarea determină mai multe mașini implicate în adăugarea
sau eliminarea nodurilor pentru migrarea datelor, prin urmare, performanța a crescut. [9]
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ă, Cassandra 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
După cum am prezentat anterior, replicarea datelor se efectuează pe noduri diferite pe
baza a doi factori : strategia de replicare c e 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, factorul de replicare ar trebui să fie cât mai mare . [8]

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. [9]
Procesul de scriere este prezentat î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ân d 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 de date SSTable , mai apoi fiind creat un nou memTable .

Fig. II. 6 Procesul de scriere/citire
La fel c a în cazul procesului de scriere, în cazul procesului de citire clientul trimite
solicitările de citire nodului coordonat or, iar acest nod coordonatorul 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, Cassand ra va 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
baza de date distribuită, NoSQL, Cassandra.
Acest studiu comparativ are la bază modul ce creare al ce lor două baze de date , MySQL
și Cassandra, precum și analizarea perfo rmanț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 comparat iv ș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 prin ana lizarea performanțelor celor două baze de date prin crearea
unei singure interogări, după care am trecut la analizarea performanțelor a 10, 50, 100, 500,
1000 , 5000 și 10000 interogări. Analiza testelor efectuate o voi prezenta în cele ce urmează
prin inte rmediul 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 o singură interogare sau de
mai multe interogări simultane.
Pentru a afectua testele propuse anterio r, atât pentru baza de date MySQL, cât și pentru
Cassandra voi realiza o aplicație ce prevede 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ți i de citire, modificare și respectiv ștergere a acestora din baza de date.

III.1 INSTALAREA 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 o interfață pe care o oferă
“phpMyAdmin”, cât și un server HTTP “Apache”. Interfața phpMy Admin este avantajoasă din
punct de 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 d ouă cerințe:
instalarea pe sistemul de calcul al Java JDK, respectiv instalarea Python pentru a putea folosi

19
comanda proprie cqlsh (Cassandra Query Language Shell). Dacă cele două sunt instalate atunci
se poate descărca în mod gratuit Apache Cassandra. La fel ca ș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 acestei aplicații ce stă la baza studiului comparativ între
MySQL și C assandra, const ă în realizarea structurii bazei de date, crearea tabelelor necesare
implementării aplicației și stabilirea relațiilor dintre tabele, acest pas ajutând ulterior la
gestionarea și manipularea 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 aplicație, de toate necesitățile pentru ca mai apoi
să gestionăm și să manipulăm datele înregistrate cu ușurință.
După cum am prezentat anterior, aplicația dezvoltată î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 urmare, 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, care sunt câmpurile aferente fiecărei tabele, astfel trebuie să modelăm t abelele 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 modelarea datelor remarcăm o primă mare diferență între bazele de date
ralaționale și cele distribui e. 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 primara (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 dintre tabele, a fost necesar ca
toate datele să le stochez în doar o singură tabelă book în care se va specifica direct numele
autorului, editu ra și genul cărților.
În MySQL, pentru a crea baz a de date “library” am utilizat direct interfața
“phpMyAdmin” pus ă la dispoziție de către programul XAMPP așa cum am specificat mai sus ,

20
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 to tal 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 tipului cărții vor fi luate din tabelele aferente acestora. Acest lucru este
posibil datorită ce lor 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
înregi strate î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ă numele 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 pent ru a insera și manipula datele prin diverse interogări.
Pornirea server -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 date Cassandra “library” se realizeaz ă diferit față de MySQL,
deoarece baza de date obișnuită din MySQL, este reprezentată prin keyspace în Cassandra.
Un keyspace reprezintă un obiect ca re deține familiile de coloane, tipurile definite de
utilizator. În Cassandra, keyspace este similar cu baza de date RDBMS. Keyspace deține
familii de coloane, indexuri, tipuri definite de utilizator, strategia folosită precum și factorul de
replicare. Pentru crearea keyspace -ului “library”, am rulat în cqlsh următoarea comandă :

21
CREATE KEYSPACE library WITH replication = {'class':
'SimpleStrategy', 'replication_factor': 3}
După cum am prezentat în subcapitolul II.2.4 intitulat Replicarea 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 st rategy ” ș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. [8]
Factorul de replici ce reprezintă număr ul total de replici 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 punct 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 simple strategy, deoarece am un
singur centr u de date, și anume propriul calculator 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 dintre
două sau m ai multe tabele diferite precum o face MySQL, drept urmare daca î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 genulu i de încadrare
a respectivei cărți .
Înainte de a începe crearea tabelelor aferente aplicației, î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 m ai jos , astfel linia
de comandă va indica keyspace -ul pe care se va lucra în continuare, evitând 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 comenzi cqlsh :

22
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 primara
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 cazu l
Cassandra datele vor fi structurate doar într -o singură tabelă.

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

Fig. III.3 Vizualizarea tabelelor în MySQL

23
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 .

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 operaț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
(actualizare) 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 efectuate aceste
teste, 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.

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 a 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:
$servername = "localhost";
$username = "root";
$password = "";

24
$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ă timpul 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, int erconectate î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 tabele
principală book, drept urmare în scriptul PHP realizat am citit 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 înregistrate. Secvența de cod ilustrată mai jos reprezintă modul în care pr eiau 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";
$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);

25
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 baza de date MySQL, drept urmare pentru a introduce mai mult e înregistrări, Cassandra
dispune BATCH. Cassandra BATCH este utilizat pentru a executa mai multe instrucțiuni de
introduceți, actualiza re sau șterge re simultan. Pentru a înregistra două sau mai multe cărți se
apelează următoarea secvență ilustrată în figu ra III.5 :

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 .

26
Figura III.6 ilustrat ă mai jos, 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 străbate
respectiva înregistrare începând de la rularea comenzii până la finalizarea procesului. Concret,
după cum se poate vedea în i magine, timpul de executare al unei comenzi de inserare este de
0.001447s.
Prin această figură se poate remarca și mecanismul de scriere al datelor î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 scriere/citire ”.

Fig. III.6 Cassandra tracing on (timpii de execuție al unei înregistrări)
După cum am precizat 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 operații simultane, rezultatul acestora fiind analizat conform
graficelor generate pe baza lor.
Î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 dis tribuită NoSQL Cassandra, graficul ilustrat
în figura III.7 de mai jos va indica faptul că operație 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 re alizează mai multe operații de adăugare simultane, cu atât se va observa că

27
timpul de execuție pentru baza de date Cassandra este mai eficient (mai mic) decât timpul de
execuție al acelorași operații dar executate pentru baza de date MySQL.

Fig. III.7 INSERT – timp execuție
După cum se remarcă în graficul ilustrat prin figura III.7 de mai sus, 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 distribuită Cassandra, această operație de introducere a cărților
este mult redusă, as tfel această operație se întinde pe doar 0.253 secunde.
Î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 My SQL, în care
înainte de a adăuga o carte se mai fac și alte operații precum aducere a din baza de date a
autorilor, editurilor și genurilor de încadrare, toate aceste fiind stocate în tabele separate de
tabela de bază “book”.
Concluzionând acest subcapitol, 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.
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
III.3.2 SELECT – operația de aducere a datelor

Odată ce avem adăugate date în cele două baze de date, se pot efectua și alte operații
pe aceste date. Cea mai folosită operație o reprezintă operația de aducere 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, 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ă “boo k”, toate acestea afl ându -se în relații de legătură stabilite între cheia
primară (primary key) a tabelelor adiacente și cheile străine (foreign keys) ale tabelei “book ”.
Pentru a analiza performantețe din punct de vedere ale timpului de execuție a operați ei
“select” de aducere 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 interogări .
În cazul bazei de date MySQL, datorită strânselor relații de legătură între cele patru
tabele, pentru aducerea și afișarea tuturor datelor stocate pentru o carte trebuie să se realizeze
operația de JOIN aplicata tabelelor, astfel încât în momentul în care se dorește afișarea unei
cărți din sistem, să se aducă respe ctiva carte cu tot cu numele autorului, denumirea editurii și a
genului de încadrare. Pentru a realiza acest lucru, am folosit secvența de cod scrisă în PHP
ilustrată mai jos :
$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($r esult->fetch_all(MYSQLI_ASSOC));
În secvența de cod prezentată, pentru fiecare dintre cele patru tabele am utilizat alias –
uri, astfel cu ajutorul acestora știm cu exactitate ce câmpuri din cele patru tabele vom referi.
Așa cum am specificat anterior, legăt ura 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âmpu ri 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 date cu detaliile aferente.

29
În ceea ce privește baza de date distribuită Cassandra, lucrurile vor sta puțin diferit,
deoarece conform aceste 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 înregistră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 direct, indifferent dacă afișăm mai mult 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
În cele ce urmează, prezint graficul ce ilustrează comparația celor două baze de date
privind timpul de execuție al operației de aducere a datelor (select) în cazul uneia și a mai
multor înregistrări.

Fig. III.9 SELECT – timp execuție
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

30
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 rezulta tele 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 vedere al timpului de execuție este net superior în
rândul Cassandra, atât pentru obținerea a numai câteva cărți, cât și pentru a obține mai multe
înregistrări. Cu toate că pentru utilizator, cel care s olicită 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 d istribuite 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 pentru aplicații 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).

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 “updat e”, oper ție
ce actualizează datele deja existente cu noile 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 interogări, 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 e ste realizat prin modificarea anului publicării fiecă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, asemen i celorlalte operații deja prezentate în

31
subcapitolele anterioare, astfel următoarea secvență de cod de mai jos 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 interogării, utilizatorului
i se va afișa valorile booleene true sau false după cum urmează : “true” dacă interogarea s -a
efectuat cu succes sau “false” în caz contrar.
La fel ca în cazul bazei 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ția care trebuie să
fie îndeplinită pentru ca datele să se actualizeze, astfel neaparat clauza “where” trebuie să
includ ă cheia primară a respectivului tabel, în cazul de față câmpul “id” a 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 d acă 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
nouă înregistrare în cazul în care condiția operației “upd ate” 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 lucrurile stau puțin diferit față de MySQL, deoarece clauza “where” nu
permite utilizarea operatorilor: >, >=, <, <= , “between ”, astfel pentru a modifica simultan mai
multe înregistrăr i 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 WHE RE 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 sunt 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

32
timpul de execuție al operației de actualizare a datelor în cazul bazei de date distribuite este net
superior timpului de execuție a 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 UPDATE – timp execuție
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 mai multe date, Cassandra are un randament mult mai mare din
punct de vedere al timpul ui de execuție, astfel în general, 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 în registră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 siguranță 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 ved ere al timpului de execuție, deoarece 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 d oar 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.
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
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, fară
a mai avea astfel acces la ele.
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);
La fel ca și î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 . Daca operația de ștergere se
execută fără probleme, utilizatorului i se va afișa “true”, iar în caz contrar acestuia i 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 subcapitolul
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ți ei “update”, clauza “where” trebuie s ă conțină cheia primară a
tabelei din care se dorește eliminarea definitivă a datelor, în cazul de față cheia primara 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);

34
Pentru a studia timpii de execuție ai acestei ultime operaț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 figu ra III.11
următoare :

Fig.III.11 DELETE – timp execu ție
Î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 pentru cele d ouă baze de date studiate MySQL și Cassandra, drept urmare se poate
sublinia din nou eficiența și performanțele ridicate ale bazei de date distribuite, comparative 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 vol um mai
mare de date este eliminat mai repede folosind Cassandra , decât același volum de date eliminat
utilizând MySQL .

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
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 sintaxa SQL doar cu mici
precizări precum în cazul în care condițiile clauzei “where” trebuie s ă conțină neaparat cheia
primară a tabelei respective, 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 straine.
Lipsa necesități i de normalizare a datelor și de stocare a acestora prin relațiilor 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 daca aceste tabele comunică cu
altele prin intermediul relațiilor de legătură, pe când Cassandra permite modificarea structurii
tabelelor cu ușurință, deo arece 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 comp anii 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
esential 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 re lațională MySQL
din punct de vedere al timpilor de procesare și execuție al opera țiilor CRUD de bază .

36
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 2 1.06.2020.
[4] https://www.tutorialspoint.com/mysql/mysql -introduction.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 -revizuit.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 0 4.07. 2020.
[7] https://www.javatpoint.com/cassandra -features , Consultat la 05.07.2020 .
[8] https://www.guru99.com/cassandra -architecture.html , Consultat la 05.07.2020.
[9] 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: Analizarea performanțelor bazei de date relaționale MySQL
comparativ cu baza de date no-SQL C assandra

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 univers itar 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țiilor internaționale
privind drepturile de autor.

Oradea,
16.08.2020 Semnătura