În primul rând, trebuie să dea o definiție a NoSQL. Acest termen a devenit prea des folosit. Acestea sunt denumite în mod colectiv ca mecanismele de stocare a datelor care nu sunt relațională, și, prin urmare, nu necesită utilizarea de SQL pentru a accesa datele. Articolul «Abordarea critica NoSQL» (bit.ly/rkphh0) Bredli Holt (Bradley Holt), un expert în CouchDB, menționează că a auzit unele suprascriere NoSQL ca „nu numai SQL (nu numai SQL)». Punctul său de vedere este că NoSQL, în orice caz, nu ar trebui să fie văzută ca o mișcare împotriva SQL. Acest punct de vedere este pe placul meu, pentru ca prefer sa folosesc pentru un anumit loc de muncă cele mai bune instrumente.
Din setul de baze de date disponibile de documente, mă voi concentra pe cele două cele mai populare - MongoDB (mongodb.org) și couchdb (couchdb.apache.org), precum și RavenDB (ravendb.net), care a fost scris pentru Microsoft .NET Framework și câștigă o mare popularitate (a se vedea. articolul „Integrarea RavenDB în ASP.NET MVC 3 aplicație“ în această problemă). Toate detaliile acestor baze de date, puteți afla vizitând site-urile lor.
O alternativă la bazele de date relaționale, și nu un înlocuitor
NoSQL bază de date de documente și date - este o alternativă la bazele de date relaționale, mai degrabă decât să le înlocuiască. Fiecare dintre ele are propria nișă, și se extind doar intervalul de alegere. Dar cum de a alege pe cel potrivit? Un criteriu important - teorema coerenței, partiții disponibilitate și toleranță la erori (coerență, disponibilitate și partiție toleranță, PAC). Ea susține că, atunci când se lucrează în sisteme distribuite, puteți obține doar două din cele trei garanții (C, A sau P), deci va trebui să decidă ce este mai important. Daca consecventa este cel mai important, atunci trebuie să utilizați o bază de date relațională.
Un exemplu de consecvență în cazul în care ar fi cea mai importantă garanție, - cererea bancară sau, eventual, o aplicație care rulează pe o centrală nucleară. În astfel de scenarii, este important să se ia în considerare fiecare bucată de date în fiecare moment. Dacă cineva se retrage bani din cont, într-adevăr trebuie să știți despre ea, atunci când te uiți la soldul contului său. Prin urmare, vă sunt susceptibile de a prefera o bază de date relațională cu un nivel ridicat de control asupra tranzacțiilor sale.
Un termen veți auzi de multe ori - „coordonare finală» (eventuala coerență) sau, așa cum este exprimat pe site-ul RavenDB:. «Este mai bine la date învechite decât de sine“ În unele domenii suficient de coerență final. Nu e mare lucru în cazul în care datele nu sunt recuperabile relevante pentru milisecundă.
În unele situații, poate mai important decât existența unei versiuni a datelor, mai degrabă decât de așteptare pentru logare toate tranzacțiile. Aceasta se referă la disponibilitatea (A) CAP, care este în primul rând asociat cu serverul de suport uptime. Încrederea pe care le puteți accesa oricând baza de date, prioritatea, și poate accelera în mod semnificativ munca de baze de date (t. E. Documentele de baze de date sunt rapid!). Vei vedea că reziliență secțiunilor (P) este de asemenea important pentru documentele de baze de date, în special în timpul scalarea pe orizontală.
HTTP API REST - pentru cea mai mare parte
Multe dintre bazele de date NoSQL sunt disponibile în stil REST, astfel încât vă conectați cu baza URI a datelor și interogările și comenzile sunt transmise ca HTTP-apeluri. Excepția este MongoDB. În mod implicit, se utilizează TCP pentru a comunica cu baza de date, disponibile cel puțin un API HTTP. CouchDB și MongoDB furnizează API specifice pentru anumite limbi, care vă permit să scrie și să execute interogări și actualizări în limba corespunzătoare, fără a fi nevoie de codificare HTTP-apeluri. În RavenDB disponibile API NET-client, care simplifică interacțiunea cu baza de date.
înregistrare de date înrudite
Mulți oameni cred eronat, în cazul în care nu o bază de date relațională - un fișier plat. Documentele stocate în baza de date document poate conține date cu o structură complexă: copaci cu noduri. Fiecare intrare în baza de date este un document, și poate fi setat autonom de date. În acest caz, înregistrarea poate conține o schemă unică și nu depinde în mod necesar orice alte documente.
Mai jos este un exemplu tipic de ce să caute intrarea în datele din document (am împrumutat acest exemplu de un student dintr-un manual pe MongoDB):
chei unice
Cheile sunt necesare în orice bază de date. Dacă nu le furnizează, ele sunt create pentru tine la nivel interior. Fără chei nu pot fi indexate de baze de date, dar chei cunoscute (chei cunoscute) pot fi solicitate în zona dvs. subiect. Observați în exemplul anterior, cu publicarea link-ul de blog pe «utilizatorii / 203907.“ Exact RavenDB utilizează valori cheie și vă permite să definiți relația dintre documente.
Depozitarea în format JSON
În general, în toate aceste exemple, înregistrările - care utilizează spațiul de stocare JSON. CouchDB și RavenDB (și multe altele) păstrează datele în JSON. MongoDB foloseste varianta JSON numit binar JSON (BSON), care permite serializare binare. BSON - este o reprezentare internă a datelor, prin urmare, din punct de vedere al programării, nici o diferenta nu ar trebui să fie.
Simplitatea obiect JSON facilitează transformarea structurilor de aproape orice limbă în format JSON. Prin urmare, puteți identifica obiecte în cererea dumneavoastră și a le stoca direct în baza de date. Acest lucru salvează dezvoltatorii de a trebui să utilizeze ORM (cartograf relațională-obiect) pentru traducere constantă între schema de baze de date și clase de schemă / obiecte.
Mecanisme de căutare full-text, de exemplu Lucene (lucene.apache.org), pe care se sprijină RavenDB, oferă căutare de mare viteză a datelor de text.
Notați data publicării în exemplul blog. JSON nu este tipul care acceptă data, dar fiecare bază de date oferă o modalitate de interpretare a tipurilor datează din orice limbă în care codul. Dacă examinați lista tipurilor de date și Convenții pentru MongoDB BSON API (bit.ly/o87Gnx), veți vedea că tipul de dată se adaugă la acesta, împreună cu multe altele.
Stocarea și regăsirea datelor aferente în înregistrările, pot oferi beneficii enorme în performanță și scalabilitate. Baze de date, în acest caz, nu trebuie să lopata toate informațiile în datele legate de căutare, deoarece acestea sunt stocate într-un singur loc.
seturi de tipuri
În cazul în care cererea dumneavoastră știe când interacționează cu baza de date, ca un element este un student, celălalt - cartea, iar al treilea - publicarea unui blog? Aceste baze de date utilizează conceptul de seturi (colecții). Orice document, indiferent de circuitul său este mapat la un anumit set (de exemplu, un set de elev), pot fi recuperate atunci când interogarea datelor din acest set. De asemenea, pentru a indica tipul de des utilizat de către orice domeniu. Acest lucru simplifică foarte mult operațiunea de căutare, dar pentru a decide ce ar trebui să fie incluse în setul, și că - nu, trebuie să te.
Schema bazei de date, fără a
elev de înregistrare, descris mai sus cuprinde un circuit. Fiecare intrare este responsabil pentru propriul său sistem, chiar dacă este conținută într-o singură bază de date sau un set. Iar una dintre înregistrările studențești nu corespunde în mod necesar la alte înregistrări de student. Desigur, software-ul ar trebui să înțeleagă diferențele dintre ele. Această flexibilitate ar putea fi utilizați pentru a îmbunătăți eficiența. De exemplu, ceea ce pentru a stoca null-valoare? Atunci când o astfel de proprietate most_repeated_class nu contează, ai putea face următoarele:
suport tranzacție
Fiecare bază de date oferă un anumit nivel de suport pentru tranzacții (care sunt mai mult, unele mai puțin), dar nici unul dintre ele nu poate atinge același nivel ca și în bazele de date relaționale. Pe această problemă, eu vă referiți la documentele.
Document Baza de date și DDD
Unul dintre conceptele de bază de proiectare a domeniului de date controlate (de dezvoltare bazate pe domeniu, DDD), se referă la domeniul de modelare folosind rădăcini agregate. Atunci când se planifică clase de domenii (care poate fi un document în baza de date), puteți căuta date, care de multe ori sunt auto-suficiente (de exemplu, o comandă cu pozițiile sale), și să se concentreze asupra lor ca structuri de date individuale. Sistemul de comanda pe care sunt, de asemenea, susceptibile de a fi clienți și produse. Dar, la comanda pot fi accesate fără necesitatea de a obține informații despre client și produsul poate fi utilizat fără a necesita acces la ordinea în care este prezent. Asta este, cu toate că veți găsi multe structuri de date de sine stătătoare posibile (aceeași ordine cu pozițiile sale), acest lucru nu exclude în anumite situații conexiune de date necesare sau posibile prin chei externe.
Pentru toate bazele de date atașate la diverse managementul de template-uri disponibile, și determina care dintre ele de multe ori a permis să reușească utilizatorilor lor. De exemplu, documentația menționată la MongoDB șablon Array înaintașilor, care accelerează accesul la datele asociate aderării.
În cazul în care repetarea datelor într-o bază de date relațională este considerat un păcat, atunci când se lucrează cu baze de date NoSQL, distribuite în special, de-normalizarea datelor utile și destul de acceptabile.
Cereri și actualizare
Fiecare bază de date are un API pentru a interoga și de actualizare. Cu toate acestea nu pot face parte din API-ul de bază, add-on-uri sunt disponibile printr-o varietate de API limbă. Pentru a intra în .NET Framework în lumea bazelor de date RavenDB interogări de sprijin prin intermediul documentelor LINQ - o mare oportunitate pentru NET-developers.
Alte căutări se bazează pe performanțele predefinite - șablon corespunzător este numit hartă / reduce (comparație / reducere). O parte a procesului privind comparația, folosește prezentarea, și gama sarcinilor sale este diferită în diferite baze de date. Comparație permite, de asemenea, o interogare a bazei de date pentru a distribui procesarea între mai multe procesoare. Reducerea ia rezultatul obținut în etapa comparând interogarea (sau interogări în cazul în care a fost alocat), și agregate de date în rezultatele returnate clientului.
Harta / reduce - acest model, și este pus în aplicare în mod diferit în diferite baze de date. Rob Eșton (Rob Ashton) a oferit o comparație interesantă a modului în care RavenDB și CouchDB efectua comparația / reducere (bit.ly/94OCME).
Dacă RavenDB necesită vederi predefinite pentru interogări și CouchDB vă permite să solicitați numai prin comparație / reducere, MongoDB (utilizat, de asemenea, prezentarea și compararea / reducere) sprijină în plus nevoile specializate (interogari ad-hoc). Cu toate acestea, capacitatea de a efectua căutări specializate pentru cea mai mare parte se pierde atunci când vă mutați departe de bine-cunoscute circuite și natura relațională a bazelor de date SQL.
Revoluția în baze de date
Sub umbrela NoSQL ascunde o mulțime de baze de date non-relaționale. Și acum, când ușile deschise, ele vor fi chiar mai mare, în măsura în care programator va afla ce este disponibil și apoi să viseze despre ceea ce ar putea fi îmbunătățit în ele. Eu cred că RavenDB - un mare exemplu de acest lucru, și puteți viziona ca Reich-ul și-a dezvoltat baza sa de date, în conformitate cu intențiile și dorințele utilizatorilor lor.
Mi se pare că intriga în jurul acestor baze de date contagioase. Acum am săpa mai adânc și să învețe noi baze de date. Dar chiar și cei trei, pe care am spus că atât de interesat de ceea ce sa aleaga doar una dintre ele este dificil. Acum, curiozitatea mea este condus de, nu o provocare pur de afaceri reale și proiecte în curs de desfășurare am fost destul de satisfac bazele de date relaționale.
Îmi exprim recunoștința mea pentru revizuirea lor de a deveni un expert Ted Neward (Ted Neward) și Savas Parastatidisu (Savas Parastatidis).