![Map<String, byte[]> map=new HashMap<String, byte[]>();
Principiu se pastrează şi în Cassandra doar că aici nu avem un singur hashMap ci până
la trei nivele imbricate de hash-uri. În acest caz sunt stocate valorile în tablouri de bytes şi fiecare
cheie referă un nou hashMap.
Map<String, Map<byte[],byte[]>>
map=new HashMap<String,Map<byte[],byte[]>>();
În acest fel partiţionarea datelor de stocat ca perechi cheie-valoare se face pornind de la
primul hashMap.Obţinerea unei valori se face furnizând o cheie cu ajutorul căreia se obţine un
hashMap prin parcurgerea căreia se obţine valoarea de interes.
În Cassandra perechile cheie-valoare nu sunt stocate ca două valori individuale ci
cuplate într-o clasa numită column. Cassandra îşi structurează modelul de date în spaţii de chei,
familii de coloane, coloane şi supercoloane. Un spaţiu de chei este un nume care grupează
familiile de coloane şi poate fi comparată cu schema unei singure baze de date în perspectiva
SQL.
Un spatiu de chei contine una sau mai multe familii de coloane. O familie de coloane
poate fi văzută ca un hashMap multidimensional ce se modifică dinamic. În analogia SQl o
familie de coloane ar fi o tabelă dintr-o schemă. Liniile sunt accesate prin chei şi fiecare linie
care poate fi văzută ca un hashMap de date are o serie de coloane. Fiecare coloană în cadrul unei
linii este o serie ordonată de chei pe post de nume şi de valori pe post de valoare, ambele
implementate prin tablouri de bytes. Funcţie de configuraţie Casandra poate aplica o schemă de
sortare pentru a impune o ordine asupra coloanelor dintr-o linie. Asta permite interogări de
domenii asupra coloanelor.
Supercoloanele . Unul dintre principalele avantaje este ca suportă straturi adiţionale de
hashMap-uri. Stratul adiţional se adaugă la stratul column şi permite să stochezi şi să accesezi
datele ca într-un hashMap tridimensional.
Map<String, Map<Map<byte[],byte[]>,Map<byte[],byte[]>>>();
HashMap-ul adiţional se numeste supercoloana. Putem crea oricâte super coloane într-o
familie de coloane.
CHORDLESS
Chordless este la nivelul inferior un hashTable distribuit modelat cu Chord şi DHash.
Facilitati: nivel de replicare configurabil implicit 3 copii, transparenţă la erori (nodurile de
backup devin automat decisive pentru o cheie când nodul decisiv pentru acea cheie dispare),
cheile vor fi serializate şi vor fi distribuite la noduri criptate cu Sha1, valorile pot fi apelate la
distanţă, datele pot fi persistate folosind JDBC, GUI. Se poate utiliza parserul ECMAScript
pentru a verifica conţinutul sistemului din nodul conectat sau pentru a examina comportamentul
valorilor stocate.](https://image.slidesharecdn.com/bazededatenosql-100212030454-phpapp01/85/Baze-de-date-NoSQL-4-320.jpg)
Baze de date NoSQL
- 1. BAZE DE DATE NOSQL Istrate (Sirbu) Doiniţa – student, Master Sisteme Distribuite, an II REZUMAT NoSQL este o derivare a sistemului de baze de date relaţional. Aşa cum îi spune şi numele nu este o bază de date SQL ci o unealtă la nivel de shell. Datele NoSql sunt stocate în fişiere ASCII UNIX astfel încât pot fi manipulate prin comenzi uzuale UNIX : ls, wc, mv, cp, cat, head, editate cu vi şi pot fi versionate cu CVS(Control Version System). Fiecare fişier conţine relaţii, tabele cu informaţii. Pentru a extrage informaţii un fişier cu date este trimis unuia sau mai multor operatori prin mecanismul de redirectare IO. NoSql există de mai mult de 1 deceniu şi nu are nimic de-a face cu noua mişcare NoSql aparută recent. În vreme ce prima este un pachet software bine definit cea de-a doua este mai mult un concept care pleacă de la modelul relaţional şi ar trebui să se numească NoRel (No Relation). SQL a fost dezvoltat de Andrew Richardson,Donald Messerly şi Raymond Boyce la începutul anilor 1970. Sistemele NoSQL de multe ori nu oferă garanţii şi au o coerenţa slabă, dar sunt mult mai uşor a fi distribuite. Se pot asocia matrici de perechi cheie-valoare sau baze de date XML care promovează XQuery. Multe dintre serverele de baze de date NoSQL de astăzi se bazează pe DHT (Distributed Hash Table), model, care prevede o semantică hashtable de acces. Pentru a accesa sau modifica orice dată obiect, clientul este obligat să furnizeze cheia primară a obiectului, atunci DB va căuta obiectul folosind un meci de egalitate la cheie furnizate INTRODUCERE Termenul NoSQL a fost inventat de Eric Evans angajat al companiei Rackspace. Numele a fost o încercare de a descrie aparitia unui număr tot mai mare de BD non-relaţionale, distribuite ce stochează date care de multe ori nu încercă să ofere garanţii ACID, diferite de sistemele relationale: MySQL, MSSQL, PostgreSQL concepute pentru gestionarea datelor in sistem relaţional. NoSQL este un sistem de management a bazelor de date rapid, portabil fără limite arbitrare altele decât memoria şi viteza procesorului ce rulează şi interacţioneaza cu SO UNIX. Foloseşte paradigma operator flux. Există un număr de operatori fiecare executând o funcţie unică asupra datelor. Fluxul este furnizat de mecanismul de redirectare a intrării şi ieşirilor din UNIX. Fiecare operator procesează datele după care le parsează următorului operator prin pipe, foarte eficient deoarece pipe-urile în UNIX sunt implementatte în memorie. NoSql este compatibil cu modelul relaţional însă NoSql nu vine cu nici o garanţie în ceea ce priveşte consistenţa.
- 2. Există un număr surprinzător de sisteme de NoSQL disponibile astăzi. Dintre proiectele open-source amintim: Cassandra, Chordless, CouchDB, DB4O, GTM, Hbase, Hipertable, Memcachedb Mnesia, MongoDB, Neo4j, Project_Voldemort, Redis_(DBMS). BIGTABLE BigTable este un sistem de stocare distribuit pentru date structurate, este folosit în servicii Google precum indexing, Google Earth şi Google Finance. O structură de date BigTable este un Map sortat, distribuit, persistent şi multidimensional, indexat după o cheie de rând, una de coloană şi o stampilă de timp. Valoarea rezultată este un tablou de bytes, neinterpretat. Datele sunt menţinute în ordine lexicografică după cheia de rând. Fiecare operaţie (citire/scriere) asupra datelor dintr-un rând se desfăşoară în mod atomic. Liniile sunt partiţionate în mod dinamic în tablete, care reprezintă totodată şi unitatea de măsură pentru verificarea încărcării într-un sistem distribuit. Aceasta partiţionare are avantajul simplificării găsirii unei date în cadrul structurii BigTable. Cheile de coloane sunt grupate în familii de coloane, care reprezintă unitatea de bază a controlului. Numele familiei se foloseşte pentru prefixarea cheilor de coloană din ea. Fiecare celulă poate conţine multiple versiuni ale datelor, indexate după o ştampilă de timp (timestamp). Implementarea conţine trei mari componente: biblioteca pentru clienţi, un server master şi serverele cu tablete, ce pot fi adăugate şi eliminate în mod dinamic (serverele). Masterul atribuie tablete serverelor de tablete, balansează încărcarea acestor servere, întreţine lista lor, declansează garbage collector-ul. Clienţii pot grupa mai multe familii de coloane în grupuri locale. La apariţia unui grup se crează un SSTable în tableta care grupează valorile pentru grupul respectiv. Aceasta duce la citiri mai eficiente. Grupurile locale pot fi declarate inclusiv în memorie, caz în care încărcarea lor se face lazily, dar fără acces la disc. Serverele de tablete folosesc două nivele de caching (Scan cache si Block Cache). DYNAMO Unele din serviciile de bază Amazon utilizează facilităţile (disponibilitatea şi scalabilitate) oferite de Dynamo prin sacrificarea consistenţei. Amazon foloseşte o arhitectură orientata pe servici slab cuplată, descentralizată. Întotdeauna există un număr mic de componente de reţea care se pot defecta la un moment dat, de aceea e necesar ca softul să trateze erorile ca pe nişte cazuri normale fără a afecta disponibilitatea sau performanţa. Exemplu: Clienţii trebuie să poată vedea şi să adauge itemi în coşul de cumpărături chiar dacă există probleme tehnice în cadrul organizaţiei. Pentru multe servicii cum ar fi: furnizarea listelor de best-seller-uri, coşurilor de cumpărături, preferinţele cumpărătorilor, managemnetul sesiunilor şi cataloagelor de produse folosirea unei baze de date relaţionale ar fi neeficientă şi ar limita scalabilitatea şi disponibilitatea. Dinamo furnizează o interfaţă bazată doar pe o cheie primară care îndeplineşte cerinţele acestor aplicaţii. Datele sunt partiţionate şi
- 3. replicate folosind hash-uri consistente iar consistenţa este îmbunătăţită prin versionarea obiectelor. Consistenta replicilor în timpul actualizării este obţinută printr-un protocol de sincronizare descentralizat. Adăugarea şi eliminarea nodurilor în sistem se face fără necesitatea vre-unei operaţii de partiţionare sau redistribuire. Sistemele tradiţionale de producţie îşi stochează starea în BD relaţionale. Aceasta reprezintă însă în unele cazuri o soluţie departe de ideal deoarece în multe cazuri doar se stochează şi regăsesc date conform unei chei primare, fără a folosi interogările complexe oferite de BD relaţionale, care ar solicita sisteme scumpe şi personal calificat, iar mecanismele de replicare existente sunt încă în faza incipientă. Cerinţele sistemului de stocare: modelul de interogare: operaţii simple de citire-scriere a unor date identificate printr-o cheie unică. Stările sunt stocate ca obiecte binare, identificate şi ele prin chei unice. O operaţie intervine asupra unei singure date deci nu e nevoie de o schemă. proprietăţi ACID: o operaţie logică == o tranzacţie; Experienţa la Amazon a aratat că bazele de date care garanteaza ACID au o disponibilitate slabă. Dynamo scade consistenţa pentru a obţine o disponibilitate sporită. Eficienţa. Dymano este folosit doar în cadrul Amazon-ului, într-un mediu presupus neostil, nu avem autorizări şi autentificări. Consideratii de proiectare: Algoritmii tradiţionali de replicare se execută sincron spre a pastra consistenta DB. Pentru sistemele în care sunt permise erorile de server şi de reţea se creşte disponibilitatea aplicând algoritmi de replicare în background, concurenţi. Asta implică apariţia conflictelor care trebuie rezolvate într-un anumit moment de timp şi de către o entitate anume. In Dynamo, chiar şi la apariţia unui conflict procesul de scriere continuă în mod normal iar conflictele se rezolvă la citire, invers faţă de sistemele tradiţionale. Conflictele sunt rezolvate de către aplicaţie prin unificarea celor două versiuni conflictuale. Alte principii respectate: - scalabilitate incrementală: adăugarea sau eliminarea unui nod se face cu impact minim asupra sistemului şi operatorului; - simetrie: toate nodurile au aceleaşi atribuţii şi drepturi; - descentralizare: comunicarea între noduri de tip p2p fără un control central; - eterogenitate: se pot adăuga noduri de orice capacitate, fără a conta capacitatea nodurilor existente. CASSANDRA Cassandra - este un sistem de stocare cheie-valoare structurat, scalabil, consistent şi distribuit. Cassandra combină tehnologiile sistemelor distribuite de la Dynamo şi modelul de date al produsului Big Table de la Google. Ca şi Dynamo Cassandra este eventual consistentă (sistemul de stocare garantează că dacă nu se execută update-uri asupra unui obiect toate accesele vor întoarce valoarea ultimului update). Modelul de date - poate fi descris ca nişte hash-map-uri imbricate. Hash-map-urile stochează datele printr-o cheie unică folosită pentru a regăsi datele. De exemplu pentru a mapa cu chei de tip string tablouri de bytes am scrie în java:
- 4. Map<String, byte[]> map=new HashMap<String, byte[]>(); Principiu se pastrează şi în Cassandra doar că aici nu avem un singur hashMap ci până la trei nivele imbricate de hash-uri. În acest caz sunt stocate valorile în tablouri de bytes şi fiecare cheie referă un nou hashMap. Map<String, Map<byte[],byte[]>> map=new HashMap<String,Map<byte[],byte[]>>(); În acest fel partiţionarea datelor de stocat ca perechi cheie-valoare se face pornind de la primul hashMap.Obţinerea unei valori se face furnizând o cheie cu ajutorul căreia se obţine un hashMap prin parcurgerea căreia se obţine valoarea de interes. În Cassandra perechile cheie-valoare nu sunt stocate ca două valori individuale ci cuplate într-o clasa numită column. Cassandra îşi structurează modelul de date în spaţii de chei, familii de coloane, coloane şi supercoloane. Un spaţiu de chei este un nume care grupează familiile de coloane şi poate fi comparată cu schema unei singure baze de date în perspectiva SQL. Un spatiu de chei contine una sau mai multe familii de coloane. O familie de coloane poate fi văzută ca un hashMap multidimensional ce se modifică dinamic. În analogia SQl o familie de coloane ar fi o tabelă dintr-o schemă. Liniile sunt accesate prin chei şi fiecare linie care poate fi văzută ca un hashMap de date are o serie de coloane. Fiecare coloană în cadrul unei linii este o serie ordonată de chei pe post de nume şi de valori pe post de valoare, ambele implementate prin tablouri de bytes. Funcţie de configuraţie Casandra poate aplica o schemă de sortare pentru a impune o ordine asupra coloanelor dintr-o linie. Asta permite interogări de domenii asupra coloanelor. Supercoloanele . Unul dintre principalele avantaje este ca suportă straturi adiţionale de hashMap-uri. Stratul adiţional se adaugă la stratul column şi permite să stochezi şi să accesezi datele ca într-un hashMap tridimensional. Map<String, Map<Map<byte[],byte[]>,Map<byte[],byte[]>>>(); HashMap-ul adiţional se numeste supercoloana. Putem crea oricâte super coloane într-o familie de coloane. CHORDLESS Chordless este la nivelul inferior un hashTable distribuit modelat cu Chord şi DHash. Facilitati: nivel de replicare configurabil implicit 3 copii, transparenţă la erori (nodurile de backup devin automat decisive pentru o cheie când nodul decisiv pentru acea cheie dispare), cheile vor fi serializate şi vor fi distribuite la noduri criptate cu Sha1, valorile pot fi apelate la distanţă, datele pot fi persistate folosind JDBC, GUI. Se poate utiliza parserul ECMAScript pentru a verifica conţinutul sistemului din nodul conectat sau pentru a examina comportamentul valorilor stocate.
- 5. COUCHDB CouchDB - este o bază de date orientată document ce poate fi interogată şi indexată prin JavaScript. Oferă replicare incrementală cu detecţie şi rezolvare bidirecţională a conflictelor. Furnizează un api RESTfullJSON accesibil din orice mediu ce permite cereri HTTP. Este scrisă Erlang (un limbaj de programare ideal pentru sisteme distribuite concurente). Un server CouchDB tine BD stocheaza documente. Fiecare document are un nume unic în BD şi CouchDB furnizează un API RESTfullHTTP pentru citirea şi actualizarea documentelor. Documentele sunt tipuri primare de date şi constau din orice număr de câmpuri şi ataşamente. Includ deasemeni şi metadate întreţinute de către sistem. Câmpurile au nume unice şi conţin valori de tipuri diverse nefiind limitate ca dimensiune sau număr. Editarea documentelor se face de către client prin încărcarea documentului modificarea lui şi rezolvarea în BD. Dacă un alt client editează acelaşi document şi îşi salvează schimbările clientul obţine un conflict la salvare. Rezolvarea conflictului se face prin deschiderea ultimei versiuni a documentului şi reactualizarea ei. Actualizarile sunt atomice. Proprietatile ACID. Pe disc întotdeauna baza de date este într-o stare consistentă. Cu excepţia câmpurilor BLOB (Bynary Large Object) a căror actualizare este concurentă toate actualizările sunt serializate. Orice număr de clienţi poate citi documentul fără a fi întrerupt de actualizările concurente. Operaţiile de citire folosesc un model MVCC (Multi Version Concurrenty Control) prin care fiecare client vede o imagine consistentă a bazei de date pe toată durata operaţiei de citire. Documentele sunt indexate în B-arbori după nume şi id de secvenţă. Fiecare actualizare generează o nouă secvenţă. Id-urile de secvenţă se folosesc pentru a găsi schimbările în baza de date. B-arborii sunt actualizaţi simultan la salvari şi ştergeri. Datele sunt deja împachetate pentru stocare în loc de a fi împărţite în tabele şi rânduri. Periodic se realizează o compactare a BD prin clonarea tuturor datelor active într-un nou fişier şi ştergerea fişierului vechi. În tot timpul acestei operaţii DB rămâne accesibilă. Vizualizări - view-uri: Datele sunt stocate in documente semistructurate, flexibile, fiecare cu propria structură. View-urile sunt metode prin care se realizează agregări, join-uri şi rapoarte ale unor seturi de date, executate dinamic, la cerere. View-urile nu modifică documentul cu date. CouchDB are posibilitatea de a proteja documentul alocând drepturi de acces pentru o serie de utilizatori. Există acces de administrator, care poate crea alte conturi de admin şi poate actualiza documentele de design. Acestea sunt documente speciale, conţinând definiţii de view- uri şi formule, ca şi câmpuri ordinare şi blob-uri. Documentele CouchDB pot avea asociată o listă de cititori pentru a le proteja conţinutul. Totodată, la actualizare, pot fi introduse validari javascript pentru securitate şi consistenţa datelor. Actualizari distribuite si replicari. Sunt permise actualizările off-line asupra datelor, urmând ca mai tarziu modificările să se facă inclusiv pe server (când există conexiune). La nivelul bazei de date mecanismul de replicare examinează documentele modificate după ultima replicare. Pentru fiecare din aceste documente, sunt apoi replicate doar câmpurile şi blob-urile modificate. Acest mecanism permite o uşoară recuperare după o cădere a conexiunii. Pot fi replicate doar anumite documente, selectate prin filtre JavaScript.
- 6. Conflictele în CouchDB reprezintă o stare comună, nu una excepţională, permiţând oricărui număr de documente conflictuale să existe în DB. În fiecare instanţă se determină care versiune este caştigătoare şi care sunt cele conflictuale. Cel câştigător apare în view-uri, în vreme ce restul vor fi eliminate la proxima compactare. CouchDB este proiectat pornind de la o viziune consistentă a unui sistem de baze de date distribuit. Fiecare maşină este independentă şi datele replicate în cluster-ul propriu coincid cu cele de pe server. Asta înseamnă că la căderea serverului DB poate fi restaurată total prin juxtapunerea informaţiilor din clustere. Astfel, la restart, întregul sistem devine imediat disponibil. DB4O DB4O - este disponibil pentru Java, .net si visual basic. Are trei modele de interogari: Query by Example - QBE, Native Queries NQ si SODA Query API (SODA). QBE - are o serie de limitări : DB4O trebuie să reflecte toţi membri din obiectul exemplu, nu se pot efectua interogări avansate cu and, or etc, constrângerile nu pot fi aplicate pentru valorile implicite, 0 pt numere, şirul vid pentru şiruri sau nul pentru tipul referinţă, trebuie să poţi crea obiecte fără să iniţializezi câmpurile, deci nu se pot iniţializa câmpurile la declarare. Pentru a evita aceste constrângeri exista Native Queries NQ. NQ este variantă recomandată pentru interogări în DB4O. Permite rularea unei porţiuni de cod asupra instanţelor unei clase. SODA Query API este pentru interogări de nivel scăzut permiţând acces direct la nodurile grafului de interogare. Deoarece SODA foloseşte stringuri ca identificatori pentru câmpuri, expresiile nu sunt verificate la momentul compilării şi de asemeni sunt dificil de scris. SODA se foloseşte la generarea dinamică a interogărilor. Tranzactii: Orice interacţiune cu DB4O se desfăşoară în cadrul unei tranzacţii. Aceasta porneşte la deschiderea containerului, iar la inchidere se face comit. Există posibilitatea de a anula ultima tranzacţie prin metoda rollBack. Nivelul implicit al tranzacţiilor este read Committed, fiecare client având în container propria referinţă slabă la obiectele deja cunoscute. Pentru a actualiza valorile obiectelor cu cele rezultatte în urma comit-urilor altor clienţi este necesar un refresh al obiectelor de la server. Într-o reţea se specifică un port şi se setează conturi pentru clienţi. Aceştia se conectează introducând hostul, portul, user-name-ul şi parola. Cateodata un client trebuie să trimită un mesaj special serverului spre a-i transmite o comandă cum ar fi o defragmentare sau oprire. Asta se realizează prin apelul metodei setMessageRecipient();. Mesajul este recepţionat de server şi procesat cu metoda processMessage();. Evaluation este o modalitate de a transmite constrângeri definite de utilizator şi de a rula cod arbitrar într-o interogare SODA. API-ul Evaluation constă din două interfeţe evaluation şi candidate. Implementarile lui evaluation realizate de utilizator sunt injectate în interogare. În timpul execuţiei interogării ele vor fi apelate de motorul DB4O cu o instanţă candidat pentru a decide ce anume să includă în result-ul curent. Interfaţa evaluation conţine metoda evaluate care primeste un argument de tip candidate. şi va fi apelată de către DB4O pentru a verifica dacă obiectul încapsulat în acest candidat trebuie inclus în rezultat. Interfaţa candidate conţine trei metode: getObject(), include() şi objectContainer().
- 7. O implementare a lui evaluation poate apela metoda getObject pentru a obţine obiectul de evaluat, poate apela include() pentru a transmite lui DB4O dacă să includă sau nu acest rezultat si poate accesa direct baza de date prin apelul metodei objectContainer(). Un dezavantaj al lui evaluation este acesta că lucrează doar pe obiecte complet instanţiate în vreme ce interogările lucrează cu baza de date. De aici rezultă o penalizare de performanţă la instanţierea obiectului, timp pierdut dacă obiectul nu este inclus în rezultat. Interogările uzuale pot sări peste încapsulări accesând direct membri privaţi dar evaluation trebuie să utilizeze API-ul, deci membri privaţi pot fi obtinuţi doar prin intermediul accesorilor. GTM GTM - este o platformă de talie industrială pentru dezvoltarea tranzacţiilor de înaltă performanţă asupra procesării bazelor de date scabili la nivel enterprise, include toate functionalităţile necesare pentru implementarea aplicaţiilor de procesare a tranzacţiilor. Suportă tranzacţii ACID, este mai rapid decat bazele de date relaţionale, nu impune restricţii asupra schemei, este o suită completă de capabilităţi de administrare a sistemului incluzând funcţii cum ar fi: hotBackup() H creează direct o copie a bazei de date din momentul începerii operaţiunii fără a fi necesare fişierele de jurnalizare. GTM include o bază de date robustă de înaltă performanţă multiparadigma şi independentă de arhitectură. Modelele relaţionale orientat obiect şi ierarhic pot fi aplicate aceloraşi date care sunt accesibile aplicaţiilor client server prin C, C++, SQL si M. Stocarea datelor se face într-o variabilă fără tip, un tablou nestructurat de bytes.Relaţiile pot fi descrise în egală măsură ca fiind ierarhice, tablouri multidimensionale sau memorie cu conţinut asociativ. La nivel programatic conţinutul este accesat prin nume de variabile globale persistente. Modelele relational orientat obiect şi navigaţional se mapează corect pe baze de date GTM. Se pot aplica mai multe modele pe aceleaşi date şi în acelaşi moment pentru acces concurent. HBASE Hbase – este un server de baze de date de la Hadoop. Se foloseşte atunci când avem nevoie de acces read-write aleator şi în timp real asupra unei colecţii mari de date. Scopul proiectului este stocarea tabelelor foarte mari de miliarde de rânduri şi milioane de coloane. Hbase conţine: - clase de bază necesare pentru copierea task-urilor hadoopMapReduce în tabele Hbase. - interogarea predicatelor pe partea de server - optimizare pentru interogări în timp real - gateway thrift de mare performanţă - serviciu web RESTful care suporta codare XML protobuf şi date binare - surse cascading - shell extensibil bazat pe jruby - suport pentru exportul metricilor prin subsistemul metricilor hadoop în fişiere sau ganglia sau jmx.
- 8. Dacă rulează pe o singura maşină nu este necesară configurarea. Operarea distribuită poate fi pseudo sau complet distribuită. Modul pseudodistribuit reprezintă modul distribuit rulând pe o singura maşină. CERCETĂRI ÎNRUDITE: Sisteme p2p. Primele sisteme p2p erau nestructurate, folosite doar pentru partajarea de fişiere, iar căutarea în ele se făcea prin emiterea unui semnal broadcast de interogare a fiecărui nod în parte în legătură cu o resursă. Au apărut apoi reţelele p2p structurate, în care fiecare nod putea ruta în mod eficient o interogare spre nodurile care deţin data cerută. Sisteme distribuite de fişiere şi baze de date distribuite: Faţă de sistemele p2p care trebuie să suporte spaţii de nume plane, sistemele de fişiere distribuite suportă spaţii de nume ierarhice. Ficus şi Coda replică fişierele pentru disponibilitate sporită, cu preţul consistenţei. Conflictele se rezolvă folosind proceduri specializate. Farsite nu foloseşte nici un server central. Google File System foloseşte un server central pentru stocarea metadatelor, iar datele sunt stocate, în blocuri, pe servere de blocuri. Bayou este un sistem distribuit pentru baze de date relaţionale ce permite lucrul off-line şi asigură eventuala consistenţă. Neo4J este un model unic, stocând obiectele şi relaţiile ca noduri şi arce intr-un graf. Pentru interogări care se potrivesc acestui model (date ierarhice), răspunsul poate fi de 1000 de ori mai rapid decât în cazul altor baze de date. Scalaris este singurul server de baze de date care oferă tranzacţii distribuite pe chei multiple. CONCLUZII NoSQL este un sistem de management al bazelor de date care nu oferă garanţii ACID, este însă rapid, portabil fără alte limite decât memoria şi viteza procesorului ce rulează şi interacţionează cu SO UNIX. Foloseşte paradigma operator flux. Există un număr de operatori şi fiecare execută o funcţie unică asupra datelor. Daca se lucreaza cu o cantitate mare de date şi se doreşte rularea de interogări dinamice ad-hoc, se va folosi o baza de date relaţională SQL. Folosirea cheie-valoare nu are sens decât dacă se doreşte distribuirea muncii pe diferite maşini fără a trece prin crearea unui cluster de baze de date. Dacă se doreste pastrarea obiectelor într-o stare persistenta şi se doreste un acces de performanţă ridicată la ele se va folosi o stocare cheie valoare. Existã un numãr mare de sisteme NoSQL disponibile astãzi cum ar fi: Cassandra, Chordless, CouchDB, DB4O, GTM, Hbase, HiperTable, Memcachedb, Mnesia, MongoDB, Neo4J, Project_Voldemort, Redis_(DBMS). Dintre acestea HBase şi Cassandra se remarcă în mod deosebit. Diferenţele dintre aceste două proiecte se pot măsura în facilităţile oferite şi arhitectură. Hbase este o clonă apropiată a lui BigTable de la Google iar Cassandra este un hibrid între BigTable şi Dynamo.
- 9. Bibliografie: Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels - Dynamo: Amazon’s Highly Available Key-value Store Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber - Bigtable: A Distributed Storage System for Structured http://incubator.apache.org/cassandra http://couchdb.apache.org http://www.db4o.com http://fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm http://hadoop.apache.org/hbase http://www.hypertable.org http://memcachedb.org http://www.erlang.org/doc/apps/mnesia/index.html http://www.mongodb.org/display/DOCS/Home http://neo4j.org http://wiki.huihoo.com/index.php?title=Project_Voldemort http://sthweb.bu.edu/archives/index.php?Redis_(dbms) http://www.sti.nasa.gov/spinoff/spinitem?title=Cordless+Instruments http://nosql.mypopescu.com/post/267817106/hbase-vs-cassandra-nosql-battle http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf http://labs.google.com/papers/bigtable.html http://www.allthingsdistributed.com/2008/12/eventually_consistent.html