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