8 Tehnologii pentru date distribuite semi-structurate: baze de date

nerelaționale

a. Motivele aplicării bazelor de date nerelaționale

Datele nerelationale oferă scalabilitate și flexibilitate pentru a îndeplini cerințele comerciale în
schimbare.Au capacitatea de a captura toate tipurile de date „Big Data”, inclusiv date
nestructurate. Sunt orientate către documente.

* Performanță masivă de scriere.

* Căutări rapide de valori cheie.

* Schema flexibilă și tipurile de date.

* Nici un singur punct de eșec.

* Prototipuri și dezvoltare rapidă.

* Întreținere ușoară.

b. Teorema CAP a lui Brewer

Teorema CAP , numita si teorema lui Brewer dupa cercetatorul EricBrewer, afirma ca este
imposibil ca un system distribuit de date sa furnizeze simultan mai mult de doua din urmatoarele
trei garantii:
Consistenta: Fiecare citire primeste cea mai recenta scriere sau o eroare
 Disponibilitate: fiecare solicitare primeste un raspuns care nu este o eroare fara garantia
caacesta contine cea mai recenta scriere.

Toleranta la separare: sistemul continua sa opereze chiar daca exista o pierdere de date
sau oeroare de system. O eroare la un singur nod nu inseamna ca intregul system trebuie sa
seprabuseasca. Sistemul continua sa functioneze in ciuda numarului arbitrar de mesaje care
suntscoase (sau intarziate) de reteau intre noduri.

c.Principiile ACID versus BASE în perspectiva sistemelor distribuite

ACID (Atomicitate, Consistență, Izolare și Durabilitate)
Conceptul a existat de zeci de ani și, până de curând, a fost principalul etalon pe care toate bazele
de date se străduiesc să îl atingă.
Atomicitate: Fie sarcina (sau toate sarcinile) din cadrul unei tranzacții sunt efectuate sau niciuna
dintre acestea nu este realizată. Acesta este principiul totul sau nimic. Dacă un element al unei
tranzacții eșuează, întreaga tranzacție eșuează.
Coerență: Tranzacția trebuie să îndeplinească toate protocoalele sau regulile definite de sistem
în orice moment. Tranzacția nu încalcă aceste protocoale și baza de date trebuie să rămână într-o
stare consecventă la începutul și la sfârșitul unei tranzacții; nu există niciodată tranzacții pe
jumătate finalizate.
Izolare: Nicio tranzacție nu are acces la nicio altă tranzacție care se află într-o stare intermediară
sau neterminată. Astfel, fiecare tranzacție este independentă pentru sine. Acest lucru este necesar
atât pentru performanță, cât și pentru consistența tranzacțiilor dintr-o bază de date.
Durabilitate: Odată ce tranzacția este finalizată, aceasta va persista ca finalizată și nu poate fi
anulată; va supraviețui defectările sistemului, pierderile de energie și alte tipuri de defecțiuni ale
sistemului.
ACID
* Consistență puternică.
* Disponibilitate mai mică.
* Concurență pesimistă.
* Complex.

BASE - BASE (Basically Available, Soft state, Eventual consistency),

Practic disponibil: Această constrângere afirmă că sistemul garantează disponibilitatea datelor
în ceea ce privește teorema CAP; va exista un răspuns la orice solicitare. Dar răspunsul respectiv
ar putea fi în continuare „eșecul” de a obține datele solicitate sau datele ar putea fi într-o stare
inconsistentă sau în schimbare, la fel ca așteptarea unei verificări pentru a se șterge în contul dvs.
bancar.
Stare slabă: starea sistemului se poate schimba în timp, deci chiar și în perioadele fără intrare
pot apărea modificări datorită „consecvenței eventuale”, astfel starea sistemului este întotdeauna
„slabă”.
Coerență eventuală: sistemul va deveni în cele din urmă consecvent odată ce nu mai primește
intrare. Datele se vor răspândi oriunde ar trebui, mai devreme sau mai târziu, dar sistemul va
continua să primească intrări și nu verifică consistența fiecărei tranzacții înainte de a trece la
următoarea.
Baza
* Disponibilitatea este cel mai important lucru.
Dispus să se sacrifice pentru acest lucru .
* Consistență mai slabă (Eventual).
* Cel mai bun efort.
* Simplu și rapid.

d. Modele esențiale NoSql

În linii mari, există 4 modele diferite de baze de date NoSQL:

⦁ Baze de date bazate pe perechi cheie-valoare.

⦁ Baze de date bazate pe coloane.

⦁ Baze de date orientate pe documente.

⦁ baze de date grafice.

i. Cheie/Valoare
Bazele de date NoSQL bazate pe perechi cheie / valoare stochează date în perechi de chei și
valori. Datele sunt stocate cu o cheie potrivită, tastele ne avand nicio relație sau structură.
ii. Orientate pe coloane
Bazele de date bazate pe coloane separă datele în coloane discrete. În loc să utilizați rânduri -
prin care ID-ul rândului este cheia principală - sistemele de baze de date bazate pe coloane
răstoarnă lucrurile pentru a face din date cheia principală.
Utilizând coloane puteți obține o viteză mult mai mare atunci când interogați date. Deși este
adevărat că interogarea unui întreg rând de date ar dura mai mult într-un SGBD bazat pe coloane,
cazurile de utilizare pentru bazele de date bazate pe coloane înseamnă că probabil nu veți face
acest lucru.
iii. Orientate pe documente
Sistemele NoSQL orientate către documente sunt foarte asemănătoare cu sistemele de gestionare
a bazelor de date cheie / valoare pereche. Singura diferență este că valoarea care este asociată cu
o cheie este stocată ca document.
Pentru dezvoltatorii de software, acest lucru este esențial - din acest motiv, bazele de date
orientate spre documente, cum ar fi MongoDB și CouchDB, sunt componente utile ale lanțului
de instrumente de dezvoltare full-stack.
iv. Orientate pe grafuri
Ultimul tip de bază de date NoSQL se bazează pe grafice. Distincția notabilă a bazelor de date
NoSQL bazate pe grafuri este că acestea conțin relațiile dintre diferite date. Ulterior, bazele de
date grafice arată destul de diferit de oricare dintre celelalte baze de date de mai sus - ele
stochează date sub formă de noduri, „marginile” nodurilor descriind relația lor cu alte noduri.
Bazele de date grafice, comparativ cu bazele de date relaționale, sunt de natură
multidimensională. Acestea afișează nu doar relațiile de bază între tabele și date, ci și cele mai
complexe și multifacetate.

9. Servicii web
Un serviciu web este un serviciu pus la dispoziție utilizatorilor pe Internet. Multitudinea de
protocoale și standarde disponibile începând de la sfârșitul secolului trecut în sfera Internetului
au dat posibilitatea comunicării între aplicații pe sisteme aflate la distanțe mari, cu acces la
Internet. Astfel, există sisteme ce oferă servicii de informare și procesare a informațiilor care în
general sunt independente de platforma hardware; accesul la acestea se face prin servicii web.

a. Protocolul HTTP: metode și antete

Hypertext Transfer Protocol (HTTP) este metoda cea mai des utilizată pentru accesarea
informațiilor în Internet care sunt păstrate pe servere World Wide Web (WWW). Protocolul
HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adică, dacă un URL nu
conține partea de protocol, aceasta se consideră ca fiind http. HTTP presupune că pe
calculatorul destinație rulează un program care înțelege protocolul. Fișierul trimis la destinație
poate fi un document HTML (abreviație de la HyperText Markup Language), un fișier grafic, de
sunet, animație sau video, de asemenea un program executabil pe server-ul respectiv sau și un
editor de text.

Anteturile HTTP permit clientului și serverului să transmită informații suplimentare cu o cerere

sau răspuns HTTP. Un antet HTTP constă din numele său care nu face sensibilitatea la majuscule
și minuscule, urmat de un punct (:), apoi de valoarea sa. Spațiul alb înainte ca valoarea să fie
ignorată. Ca exemplu authentication, catching, client hints, conditionals si altele.

Anteturile pot fi grupate în funcție de contextul lor:

Antetele cererii conțin mai multe informații despre resursa care trebuie preluată sau despre
clientul care solicită resursa.

Antetele răspunsului conțin informații suplimentare despre răspuns, cum ar fi locația acestuia sau
despre serverul care îl furnizează.

Anteturile de reprezentare conțin informații despre corpul resursei, cum ar fi tipul MIME sau
codificarea/comprimarea aplicată.

Antetele încărcăturii utile conțin informații independente de reprezentare despre datele

încărcăturii utile, inclusiv lungimea conținutului și codificarea utilizată pentru transport.

Metode:
GET este una dintre cele mai importante metode si singura care era disponibila în prima
versiune a protocolului, HTTP/0.9. GET este metoda care "aduce" ceva de la resursa; mai
concret, daca resursa este un proces care produce date (o cautare de pilda), raspunsul la metoda
GET va fi o entitate care sa cuprinda acele date. Raspunsul este unul singur: aceasta este o
caracteristica de baza a protocolului. Chiar daca volumul de date care trebuie incluse în raspuns
este mare, nu se face o fractionare în bucatele mai mici, care sa permita transferul mai usor al
raspunsului. Din punct de vedere al protocolului HTTP, discutia este totdeauna simpla: o
întrebare are un raspuns. Nu se pot pune mai multe întrebari pentru a obtine un singur raspuns,
nu se pot formula mai multe raspunsuri la o întrebare.

HEAD este o metoda similara cu GET, folosita în principiu pentru testarea validitatii si/sau
accesibilitatii unei resurse, sau pentru a afla daca s-a schimbat ceva. Sintaxa este similara
metodei GET; spre deosebire de GET însa, datele eventual produse de resursa în urma cererii nu
sînt transmise; doar caracteristicile acestora, si un cod de succes sau eroare.

POST este metoda prin care resursei specificate în cerere i se cere sa îsi subordoneze datele
incluse în entitatea care trebuie sa însoteasca cererea. Cu POST se poate adauga un fisier unui
anumit director, se poate trimite un mesaj prin posta electronica, se poate adauga un mesaj unui
grup de stiri, se pot adauga date unei baze de date existente, etc. Metoda POST este generala;
care sînt procesele pe care un anumit server le accepta sau cunoaste îi sînt strict specifice.

PUT este o metoda care cere serverului ceva mai mult decît POST: sa stocheze/memoreze
entitatea cuprinsa în cerere cu numele specificat în URI. Daca resursa specificata exista deja,
entitatea noua trebuie privita ca o versiune modificata care ar trebui sa o înlocuiasca pe cea
existenta. Serverul, bineînteles, va accepta sau nu aceasta cerere, functie de drepturile de acces
pe care i le-a acordat clientului, si va raspunde cererii cu informatii.

PATCH este o metoda similara lui PUT, dar nu contine toate datele care sa defineasca resursa, ci
numai diferentele fata de versiunea existenta pe server. Cu toate informatiile necesare care sa îi
permita serverului sa reconstruiasca o versiune la zi a resursei.

COPY, MOVE si DELETE sînt metode prin care se cere ca resursa specificata în URI-ul din
cerere sa fie copiata în locatiile specificate ca parametri pentru metoda, mutata acolo sau
respectiv doar stearsa.

LINK si UNLINK sînt metode prin care resursa specificata în cerere este legata/dezlegata de
alte resurse, stabilind una sau mai multe relatii cu acestea din urma, specificate ca parametrii
pentru metoda. Ar putea fi de exemplu un index pentru o baza de date, un cuprins pentru un set
de documente, etc.

TRACE este o metoda care îi permite clientului sa vada cum ajung cererile sale la server, pentru
a verifica/diagnostica conexiunea, pentru a se verifica pe sine sau pentru a determina felul în care
eventualele proxy-uri de pe parcurs au modificat cererea initiala. Serverul, în raspuns la aceasta
cerere, va trimite în ecou cererile care îi vin de la client, fara sa le mai trateze ca cereri "reale".

WRAPPED este o metoda care "contrazice" principiul protocolului de a trimite totdeauna o

singura cerere si a astepta un singur raspuns. Via WRAPPED, mai multe cereri, care în mod
obisnuit ar fi succesive, sînt "împachetate" într-una singura. Iar o alta aplicare a metodei tinteste
masuri de securizare - o cerere poate fi cifrata si transmisa prin metoda WRAPPED, ceea ce va
determina serverul sa actioneze în doi pasi: întîi sa descifreze cererea reala, iar apoi sa îi dea curs
acesteia.

b. Stilul arhitectural REST

REST este un termen inventat de Roy Fielding pentru a descrie un stil de arhitectură a sistemelor
în rețea. REST este un acronim pentru Representational State Transfer.

Motivația pentru REST a fost de a captura caracteristicile Web care a făcut Web-ul de succes.
Ulterior, aceste caracteristici sunt folosite pentru a ghida evoluția Web-ului.

Fce standarde de utilizare:

HTTP

URL-ul

XML / HTML / GIF / JPEG /

text / XML, text / html, imagine / gif, image / jpeg, etc (tipuri MIME)

Aici sunt caracteristicile REST:

Client-Server: un stil de interacțiune bazat pe tragere: componente cu consum trage

reprezentări.

Apatrid: fiecare cerere de la client la server trebuie să conțină toate informațiile necesare
pentru a înțelege cererea, și nu pot să profite de orice context stocat pe server.

Cache: pentru a îmbunătăți eficiența rețelei de răspunsuri trebuie să poată fi etichetate ca

cacheable sau non-cacheable.

Interfață uniformă: toate resursele sunt accesate cu o interfață generică (de exemplu, HTTP GET,
POST, PUT, DELETE).

Resurse mentionate- sistemul este format din resurse care sunt numite cu ajutorul unui adresă
URL.

Reprezentări de resurse interconectate- reprezentările resurselor sunt interconectate folosind

URL-uri, permițând astfel unui client să progreseze de la o stare la alta.

Componente din strat- intermediari, cum ar fi servere proxy, servere cache, gateway-uri, etc, pot
fi inserate între clienți și resurse pentru a sprijini performanta, securitatea, etc.

c. Caching și proxing
Proxy cache permite unui server să acționeze ca intermediar între un utilizator și un furnizor de
conținut web. Atunci când un utilizator accesează un site web, proxy-urile interpretează și
răspund solicitărilor în numele serverului original.

i. Caching în sistemele distribuite

O memorie cache distribuită este un sistem care reunește memoria cu acces aleatoriu (RAM) a
mai multor computere din rețea într-un singur depozit de date în memorie utilizat ca memorie
cache de date pentru a oferi acces rapid la date. În timp ce majoritatea cache-urilor sunt în mod
tradițional într-un singur server fizic sau componentă hardware, o cache distribuită poate crește
dincolo de limitele de memorie ale unui singur computer prin conectarea mai multor computere -
denumite arhitectură distribuită sau cluster distribuit - pentru o capacitate mai mare și o putere de
procesare sporită .

ii. HTTP caching

Performanța site-urilor web și a aplicațiilor poate fi îmbunătățită semnificativ prin reutilizarea
resurselor preluate anterior. Cache-urile web reduc latența și traficul de rețea și reduc astfel
timpul necesar pentru afișarea unei reprezentări a unei resurse. Folosind cache-ul HTTP, site-
urile Web devin mai receptive.
Cache cache HTTP este opțional, dar de obicei de dorit. Cache-urile HTTP sunt de obicei
limitate la răspunsurile cache la GET; pot refuza alte metode. Cheia cache principală constă din
metoda de solicitare și URI țintă (de multe ori se folosește doar URI - acest lucru se datorează
faptului că numai cererile GET sunt ținte cache).
Formele comune de intrări în cache sunt:
Rezultate de succes ale unei cereri de recuperare: un răspuns 200 (OK) la o cerere GET care
conține o resursă precum documente HTML, imagini sau fișiere.
Redirecționări permanente: un răspuns 301 (mutat permanent).
Răspunsuri de eroare: o pagină de rezultate 404 (Not Found).
Rezultate incomplete: un răspuns 206 (Conținut parțial).
Răspunsuri altele decât GET dacă este definit ceva adecvat pentru utilizare ca cheie cache.
iii. Forward Proxy vs Reverse Proxy
Un proxy forward este intermediarul pe care clientul îl prezintă între el și orice server. Proxy-ul
invers este la celălalt capăt - ceva pe care serverul îl prezintă între el și orice client.
Pe scurt, un proxy invers este un intermediar pe partea serverului la care vă conectați. Și proxy-ul
direct este intermediarul din partea dvs. a internetului.
În esență, proxy-urile forward și reverse fac sarcini diferite, dar ambele:
mediază traficul unui client,poate autoriza sau bloca accesul,
poate fi un singur punct de acces pentru dispozitive sau servere.
d. Cadre de programare ce facilitează dezvoltarea orientată pe web servicii

i. Java/ JAX-RS - Cadrul Jersey

Cadrul Jersey RESTful Web Services este open source, calitate de producție, cadru pentru
dezvoltarea serviciilor web RESTful în Java, care oferă suport pentru API-urile JAX-RS și servește
ca un JAX-RS .

Cadrul Jersey este mai mult decât implementarea de referință JAX-RS. Jersey oferă propriul API
care extinde setul de instrumente JAX-RS cu funcții și utilități suplimentare pentru a simplifica și
mai mult serviciile RESTful și dezvoltarea clienților. Jersey expune, de asemenea, numeroase SPI-
uri de extensie, astfel încât dezvoltatorii să poată extinde Jersey pentru a se potrivi cel mai bine
nevoilor lor.

ii. .Net/ ASP.Net Web API (2)

API-ul Web oferă o modalitate de a construi o aplicație ASP.NET care este special adaptată
pentru a funcționa în stilul REST (Transfer de stat de reprezentare). Arhitectura REST presupune
utilizarea următoarelor metode sau tipuri de solicitare HTTP pentru a comunica cu serverul:
GET
POST
PUT
DELETE
De multe ori, stilul REST este deosebit de util pentru crearea de tot felul de aplicații cu o singură
pagină, care folosesc deseori cadre javascript speciale precum Angular, React sau Vue.js. În
esență, un API Web este un serviciu web la care alte aplicații pot accesa. Mai mult, aceste
aplicații pot reprezenta orice tehnologie și platformă - pot fi aplicații web, clienți mobili sau
desktop.

10. Cloud computing - cetralizarea convențională a calculului

Cloud computing este un concept modern în domeniul computerelor și
informaticii,reprezentând un ansamblu distribuit de servicii de calcul, aplicații, acces la
informații și stocare de date, fără ca utilizatorul să aibă nevoie să cunoască amplasarea
și configurația fizică a sistemelor care furnizează aceste servicii. Pentru cloud
computing încă nu există un nume românesc încetățenit.
Clasificare
După livrare:
Software as a service - Software ca serviciu
Platform as a service - Platformă ca serviciu
Network as a service - Rețea ca serviciu
Infrastructure as a service - Infrastructură ca serviciu
După implementare:
Cloud public
Cloud privat
Cloud hibrid
Cloud pentru o comunitate (community cloud)
a. Tipuri de servicii
Există trei tipuri principale de servicii în cloud: software ca serviciu (SaaS), platformă ca
serviciu (PaaS) și infrastructură ca serviciu (IaaS). Nu există o metodă unică de
abordare a cloudului; este vorba mai mult despre găsirea soluției potrivite, care să
îndeplinească cerințele dvs. de afaceri.
SaaS
Software-ul ca serviciu (SaaS) este un model de furnizare a software-ului în care
furnizorul de cloud găzduiește aplicațiile clientului în locația sa. Clientul își accesează
aplicațiile prin internet. În loc să plătească pentru întreținerea propriei infrastructuri de
calcul, clientul beneficiază de abonamentul la serviciu, plătind pe măsură ce utilizează.
PaaS
Platforma ca serviciu (PaaS) oferă clienților avantajul de a accesa instrumentele pentru
dezvoltatori de care au nevoie, pentru a crea și gestiona aplicații mobile și web fără a
investi în sau a întreține infrastructura de bază. Furnizorul găzduiește componentele
infrastructurii și middleware-ul, iar clientul accesează aceste servicii printr-un browser
web.
IaaS
Infrastructura ca serviciu (IaaS) permite accesul clienților la servicii de infrastructură la
cerere prin intermediul internetului. Avantajul esențial este că furnizorul de cloud
găzduiește componentele infrastructurii, care furnizează capacități de calcul, de stocare
și de rețea, astfel încât abonații să își poată rula fluxurile de lucru în cloud. Abonatul în
cloud este, de obicei, responsabil pentru instalarea, configurarea, securizarea și
întreținerea oricărui software în infrastructura cloud, cum ar fi baza de date,
middleware-ul și software-ul pentru aplicați
b. Principii DevOps
DevOps este un set de concepte și un mod de lucru care a luat naștere din abordările Agile și
Lean ale operațiunilor. Se referă la echipele de dezvoltare software (Dev) și operațiunile
tehnologiei informației (Ops) care lucrează împreună pentru a îmbunătăți productivitatea,
automatiza infrastructura și măsura continuu performanța aplicației. Acest lucru este pentru a
oferi mai multe soluții software într-o perioadă mai scurtă.

Dezvoltarea DevOps merge în trei direcții: oameni, procese și instrumente.

Principiile DevOps pot fi clasificate comform la CAMPS

Abrevierea CAMS înseamnă:

cultură
automatizare
măsurare
schimb