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.

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

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:

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.

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.

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().

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.

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.

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