Što je NoSQL? Baze podataka za budućnost u oblaku

Jedan od najosnovnijih izbora koji treba donijeti prilikom razvijanja aplikacije je hoće li se za pohranu podataka koristiti SQL ili NoSQL baza podataka. Uobičajene SQL (tj. Relacijske) baze podataka proizvod su desetljeća evolucije tehnologije, dobre prakse i stvarnog testiranja otpornosti na stres. Dizajnirani su za pouzdane transakcije i ad hoc upite, osnovne stavke poslovnih aplikacija. No, oni su također opterećeni ograničenjima - poput krute sheme - koja ih čine manje pogodnima za druge vrste aplikacija.

Kao odgovor na ta ograničenja nastale su baze podataka NoSQL. NoSQL sustavi pohranjuju podatke i upravljaju njima na načine koji omogućavaju veliku operativnu brzinu i veliku fleksibilnost programera. Mnoge su razvile tvrtke poput Googlea, Amazona, Yahooa i Facebooka koje su tražile bolje načine za pohranu sadržaja ili obradu podataka za masivne web stranice. Za razliku od SQL baza podataka, mnoge se baze podataka NoSQL mogu horizontalno skalirati na stotinama ili tisućama poslužitelja.

Prednosti NoSQL-a ne dolaze bez troškova. NoSQL sustavi općenito ne pružaju istu razinu dosljednosti podataka kao SQL baze podataka. U stvari, dok su SQL baze podataka tradicionalno žrtvovale performanse i skalabilnost za svojstva ACID koja stoje iza pouzdanih transakcija, NoSQL baze podataka uglavnom su odbacile ta ACID jamstva za brzinu i skalabilnost.

Ukratko, baze podataka SQL i NoSQL nude različite kompromise. Iako se mogu natjecati u kontekstu određenog projekta - kao u onome koji će odabrati za ovu ili onu aplikaciju - oni se nadopunjuju u široj slici. Svaka je pogodna za različite slučajeve upotrebe. Odluka nije toliko slučaj ili / ili koliko je pitanje koji je alat prikladan za posao.

NoSQL nasuprot SQL-u

Temeljna razlika između SQL-a i NoSQL-a nije toliko komplicirana. Svaka ima drugačiju filozofiju načina na koji se podaci trebaju čuvati i dohvaćati.

Kod SQL baza podataka svi podaci imaju svojstvenu strukturu. Uobičajena baza podataka kao što je Microsoft SQL Server, MySQL ili Oracle Database koristi shemu - formalnu definiciju načina na koji će biti sastavljeni podaci umetnuti u bazu podataka. Na primjer, zadani stupac u tablici može biti ograničen samo na cijele brojeve. Kao rezultat, podaci zabilježeni u koloni imat će visok stupanj normalizacije. Kruta shema SQL baze podataka također čini relativno jednostavnim izvođenje agregiranja podataka, na primjer putem PRIDRUŽIVANJA.

S NoSQL-om podaci se mogu pohranjivati ​​bez sheme ili u slobodnom obliku. Bilo koji podaci mogu se pohraniti u bilo koji zapis. Među NoSQL bazama podataka pronaći ćete četiri uobičajena modela za pohranu podataka koji vode do četiri uobičajene vrste NoSQL sustava:

  1. Baze podataka dokumenata (npr. CouchDB, MongoDB). Umetnuti podaci pohranjuju se u obliku JSON struktura ili "dokumenata" slobodnog oblika, gdje podaci mogu biti bilo što, od cijelih brojeva do nizova do teksta slobodnog oblika. Nema inherentne potrebe za određivanjem koja će polja, ako ih ima, dokument sadržavati.
  2. Trgovine ključne vrijednosti (npr. Redis, Riak). Vrijednostima slobodnog oblika - od jednostavnih cijelih brojeva ili nizova do složenih JSON dokumenata - pristupa se u bazi podataka pomoću ključeva.
  3. Široke trgovine s stupcima (npr. HBase, Cassandra). Podaci se pohranjuju u stupce umjesto u retke kao u uobičajenom SQL sustavu. Bilo koji broj stupaca (i prema tome mnogo različitih vrsta podataka) može se grupirati ili agregirati prema potrebi za upite ili prikaze podataka.
  4. Grafikujte baze podataka (npr. Neo4j). Podaci su predstavljeni kao mreža ili graf entiteta i njihovih odnosa, pri čemu je svaki čvor na grafikonu komad podataka slobodnog oblika.

Pohrana podataka bez sheme korisna je u sljedećim scenarijima:

  1. Želite brz pristup podacima i više vas brinu brzina i jednostavnost pristupa nego pouzdane transakcije ili dosljednost.
  2. Spremate veliku količinu podataka i ne želite se zaključati u shemu, jer bi kasnije mijenjanje sheme moglo biti sporo i bolno.
  3. Uzimate nestrukturirane podatke iz jednog ili više izvora koji ih proizvode i želite zadržati podatke u izvornom obliku radi maksimalne fleksibilnosti.
  4. Želite podatke pohraniti u hijerarhijsku strukturu, ali želite da te hijerarhije opisuju sami podaci, a ne vanjska shema. NoSQL omogućuje da se podaci ležerno autoreferenciraju na načine koji su složeniji za oponašanje SQL baza podataka.

Upit o NoSQL bazama podataka

Strukturirani jezik upita koji koriste tradicionalne baze podataka pruža jedinstven način komunikacije s poslužiteljem prilikom spremanja i dohvaćanja podataka. Sintaksa SQL visoko je standardizirana, pa iako pojedine baze podataka mogu različito rukovati određenim operacijama (npr. Funkcije prozora), osnove ostaju iste.

Suprotno tome, svaka NoSQL baza podataka ima svoju sintaksu za upite i upravljanje podacima. CouchDB, na primjer, koristi zahtjeve u obliku JSON-a, poslane putem HTTP-a, za stvaranje ili preuzimanje dokumenata iz svoje baze podataka. MongoDB šalje JSON objekte putem binarnog protokola, putem sučelja naredbenog retka ili jezične biblioteke.

Neki NoSQL proizvodi mogu koristiti sintaksu sličnu SQL-u za rad s podacima, ali samo u ograničenoj mjeri. Na primjer, Apache Cassandra, baza podataka pohrane stupaca, ima vlastiti jezik sličan SQL-u, Cassandra Query Language ili CQL. Neke od sintaksa CQL-a izravno su iz SQL knjige, poput ključnih riječi SELECT ili INSERT. Ali ne postoji način da se PRIDRUŽI ili podupit u Cassandri, a time ni povezane ključne riječi ne postoje u CQL-u.

Arhitektura zajedničkog ničega

Izbor dizajna zajednički za NoSQL sustave je "zajedničko-ništa" arhitektura. U dizajnu zajedničkog ničega, svaki čvor poslužitelja u klasteru radi neovisno od svakog drugog čvora. Sustav ne mora postići konsenzus svakog pojedinog čvora da bi klijentu vratio dio podataka. Upiti su brzi jer se mogu vratiti s bilo kojeg čvora koji je najbliži ili najprikladniji.

Još jedna prednost zajedničkog ničega je elastičnost i proširivanje. Proširivanje klastera jednostavno je poput okretanja novih čvorova u klasteru i čekanja da se sinkroniziraju s ostalima. Ako padne čvor NoSQL, ostali poslužitelji u klasteru nastavit će se mijenjati. Svi podaci ostaju dostupni, čak i ako je dostupno manje čvorova za posluživanje zahtjeva.

Imajte na umu da dizajn zajedničkog ničega nije ekskluzivan za baze podataka NoSQL. Mnogi konvencionalni SQL sustavi mogu se postaviti na dijeljeni način, iako to obično uključuje žrtvovanje dosljednosti u klasteru radi izvedbe.

NoSQL ograničenja

Ako NoSQL pruža toliko slobode i fleksibilnosti, zašto ne bismo u potpunosti napustili SQL? Jednostavan odgovor: Mnoge se aplikacije i dalje pozivaju na vrste ograničenja, dosljednost i zaštitne mjere koje pružaju SQL baze podataka. U tim se slučajevima neke "prednosti" NoSQL-a mogu pretvoriti u nedostatke. Ostala ograničenja proizlaze iz činjenice da su NoSQL sustavi relativno novi. 

Nema sheme

Čak i ako uzimate podatke u slobodnom obliku, gotovo uvijek im morate nametnuti ograničenja kako bi bili korisni. S NoSQL-om nametanje ograničenja uključuje prebacivanje odgovornosti s baze podataka na programera aplikacije. Na primjer, programer bi mogao nametnuti strukturu kroz objektni sustav relacijskog mapiranja ili ORM. Ali ako želite da shema živi sa samim podacima , NoSQL to obično ne radi.

Neka NoSQL rješenja pružaju neobavezne mehanizme za tipkanje i provjeru podataka. Na primjer, Apache Cassandra ima mnoštvo izvornih tipova podataka koji podsjećaju na one pronađene u konvencionalnom SQL-u.

Eventualna dosljednost

NoSQL sustavi trguju snažnom ili trenutnom dosljednošću radi bolje dostupnosti i performansi. Uobičajene baze podataka osiguravaju da su operacije atomske (svi dijelovi transakcije uspiju ili niti jedan), dosljedne (svi korisnici imaju isti pogled na podatke), izolirane (transakcije se ne natječu) i trajne (nakon dovršetka opstaju neuspjeh poslužitelja).

Ova se četiri svojstva, koja se zajednički nazivaju ACID, u većini NoSQL sustava obrađuju različito. Umjesto trenutne dosljednosti na klasteru, imate konačnu dosljednost zbog vremena potrebnog za kopiranje ažuriranja na druge čvorove u klasteru. Podaci umetnuti u klaster na kraju su dostupni svugdje, ali ne možete jamčiti kada.

Semantika transakcija koja u SQL sustavu jamči da su svi koraci u transakciji (npr. Izvršavanje prodaje i smanjenje zaliha) dovršeni ili vraćeni unatrag, obično nisu dostupni u NoSQL-u. Za bilo koji sustav u kojem mora postojati "jedan izvor istine", poput banke, NoSQL pristup neće dobro funkcionirati. Ne želite da se stanje na vašem računu razlikuje, ovisno o tome na koji bankomat idete; želite da se to svugdje prijavljuje kao ista stvar.

Neke baze podataka NoSQL imaju djelomične mehanizme za zaobilaženje ovoga. Na primjer, MongoDB ima jamstva dosljednosti za pojedinačne operacije, ali ne i za bazu podataka u cjelini. Microsoft Azure CosmosDB omogućuje vam odabir razine dosljednosti po zahtjevu, tako da možete odabrati ponašanje koje odgovara vašem slučaju upotrebe. No s NoSQL-om očekujte eventualnu dosljednost kao zadano ponašanje.

NoSQL zaključavanje

Većina NoSQL sustava konceptualno su slični, ali se implementiraju vrlo različito. Svaka ima svoje metafore i mehanizme kako se podaci pretražuju i upravljaju njima.

Jedna nuspojava toga je potencijalno visok stupanj sprege između aplikacijske logike i baze podataka. To nije tako loše ako odaberete NoSQL sustav i držite se njega, ali on može postati kamen spoticanja ako promijenite sustav na putu.

Ako migrirate s, recimo, MongoDB na CouchDB (ili obrnuto), morate učiniti više od samog migriranja podataka. Također se morate kretati razlikama u pristupu podacima i programskim metaforama - drugim riječima, morate prepisati dijelove svoje aplikacije koji pristupaju bazi podataka.

NoSQL vještine

Još jedan nedostatak NoSQL-a je relativni nedostatak stručnosti. Tamo gdje je tržište konvencionalnih SQL talenata još uvijek prilično veliko, tržište NoSQL vještina tek započinje.

Za referencu, Indeed.com izvještava da od kraja 2017. godine opseg popisa poslova za konvencionalne SQL baze podataka - MySQL, Microsoft SQL Server, Oracle Database i tako dalje - ostaje veći u posljednje tri godine od obujma poslova za MongoDB, Couchbase i Cassandra. Potražnja za stručnošću za NoSQL raste, ali to je još uvijek dio tržišta za konvencionalnim SQL-om.

Spajanje SQL-a i NoSQL-a

Možemo očekivati ​​da će neke razlike između SQL i NoSQL sustava vremenom nestati. Već mnoge SQL baze podataka sada prihvaćaju JSON dokumente kao izvorni tip podataka i mogu izvoditi upite prema tim podacima. Neki čak imaju izvorne načine nametanja ograničenja JSON podacima, tako da se s njima postupa s istom strogošću kao i s uobičajenim podacima redaka i stupaca.

S druge strane, NoSQL baze podataka ne dodaju samo jezike upita slične SQL-u, već i druge mogućnosti tradicionalnih SQL baza podataka. Na primjer, najmanje dvije baze podataka dokumenata - MarkLogic i RavenDB - obećavaju da će biti u skladu s ACID-om.

Tu i tamo postoje znakovi da će buduće generacije baza podataka raširiti paradigme i ponuditi i NoSQL i SQL funkcionalnost. Microsoftov Azure Cosmos DB, na primjer, koristi skup primitiva ispod poklopca kako bi naizmjenično reproducirao ponašanja obje vrste sustava. Google Cloud Spanner je SQL baza podataka koja kombinira snažnu dosljednost s horizontalnom skalabilnošću NoSQL sustava.

Ipak, čisti SQL i čisti NoSQL sustavi imat će svoje mjesto dugi niz godina. Potražite NoSQL za brz, vrlo skalabilan pristup podacima u slobodnom obliku. To dolazi s nekoliko troškova, poput dosljednosti čitanja i ostalih zaštitnih mjera zajedničkih SQL bazama podataka. No, za mnoge aplikacije te mjere zaštite možda vrijedi trgovati za ono što nudi NoSQL.