Programiranje

Kaj je NoSQL? Zbirke podatkov za prihodnost v oblaku

Ena najpomembnejših odločitev pri razvoju aplikacije je, ali za shranjevanje podatkov uporabiti bazo podatkov SQL ali NoSQL. Konvencionalne baze podatkov SQL (tj. Relacijske) so plod desetletij tehnološkega razvoja, dobrih praks in resničnih stresnih testov. Namenjeni so zanesljivim transakcijam in priložnostnim poizvedbam, sponkam linij poslovnih aplikacij. Obremenjeni pa so tudi z omejitvami, na primer s togo shemo, zaradi katerih so manj primerni za druge vrste aplikacij.

Kot odgovor na te omejitve so nastale zbirke podatkov NoSQL. Sistemi NoSQL shranjujejo in upravljajo podatke na načine, ki omogočajo visoko hitrost delovanja in veliko prilagodljivost razvijalcev. Mnoga so razvila podjetja, kot so Google, Amazon, Yahoo in Facebook, ki so iskala boljše načine za shranjevanje vsebine ali obdelavo podatkov za množična spletna mesta. V nasprotju s podatkovnimi bazami SQL je veliko baz podatkov NoSQL mogoče vodoravno prilagoditi na stotine ali tisoče strežnikov.

Prednosti NoSQL pa niso brez stroškov. Sistemi NoSQL običajno ne zagotavljajo enake ravni skladnosti podatkov kot baze podatkov SQL. Pravzaprav so baze podatkov SQL tradicionalno žrtvovale zmogljivost in razširljivost za lastnosti ACID, ki stojijo za zanesljivimi transakcijami, vendar so baze podatkov NoSQL v veliki meri odpovedale ta jamstva ACID za hitrost in razširljivost.

Skratka, zbirki podatkov SQL in NoSQL ponujata različne kompromise. Medtem ko lahko tekmujejo v okviru določenega projekta - kot v, za katerega naj se odločijo to prijava oz to aplikacije - v širši sliki se dopolnjujejo. Vsak je primeren za različne primere uporabe. Odločitev ne gre toliko za eno ali / ali kot za vprašanje, katero orodje je primerno za to delovno mesto.

NoSQL v primerjavi s SQL

Temeljna razlika med SQL in NoSQL ni tako zapletena. Vsak ima drugačno filozofijo, kako naj se podatki shranjujejo in pridobivajo.

Z bazami podatkov SQL imajo vsi podatki inherentno strukturo. Običajna baza podatkov, kot je Microsoft SQL Server, MySQL ali Oracle Database, uporablja shemo—Formalna opredelitev načina sestavljanja podatkov, vnesenih v bazo podatkov. Na primer, dani stolpec v tabeli je lahko omejen samo na cela števila. Posledično bodo podatki, zabeleženi v stolpcu, zelo normalizirani. Toga shema baze podatkov SQL omogoča tudi razmeroma enostavno izvajanje združevanja podatkov, na primer prek JOIN-ov.

Z NoSQL lahko podatke shranjujete brez sheme ali v prosti obliki. Vse podatke lahko shranite v kateri koli zapis. Med bazami podatkov NoSQL boste našli štiri pogoste modele za shranjevanje podatkov, ki vodijo do štirih pogostih vrst sistemov NoSQL:

  1. Podatkovne baze dokumentov (npr. CouchDB, MongoDB). Vstavljeni podatki so shranjeni v obliki struktur JSON v prosti obliki ali "dokumentov", kjer so lahko podatki od celoštevilskih števil do nizov do besedila proste oblike. Nobene lastne potrebe ni določiti, katera polja, če sploh, bo vseboval dokument.
  2. Shrambe ključnih vrednosti (npr. Redis, Riak). Vrednosti proste oblike - od enostavnih celih števil ali nizov do zapletenih dokumentov JSON - so dostopne v zbirki podatkov s pomočjo ključev.
  3. Široke prodajalne stolpcev (npr. HBase, Cassandra). Podatki so shranjeni v stolpcih namesto vrstic kot v običajnem sistemu SQL. Vsako število stolpcev (in s tem veliko različnih vrst podatkov) je mogoče razvrstiti v skupine ali združiti, če je to potrebno za poizvedbe ali poglede podatkov.
  4. Grafične zbirke podatkov (npr. Neo4j). Podatki so predstavljeni kot mreža ali graf entitet in njihovih razmerij, pri čemer je vsako vozlišče v grafu del podatkov v prosti obliki.

Shranjevanje podatkov brez sheme je koristno v naslednjih primerih:

  1. Želite hiter dostop do podatkov in vas bolj skrbijo hitrost in enostavnost dostopa kot zanesljive transakcije ali doslednost.
  2. Shranjujete velik obseg podatkov in se nočete zapreti v shemo, saj bi bila kasneje sprememba sheme lahko počasna in boleča.
  3. Vzamete nestrukturirane podatke iz enega ali več virov, ki jih proizvajajo, in želite ohraniti podatke v prvotni obliki za največjo prilagodljivost.
  4. Podatke želite shraniti v hierarhični strukturi, vendar želite, da te hierarhije opisujejo podatki sami, ne pa zunanja shema. NoSQL omogoča, da se podatki ležerno samo-referencirajo na načine, ki so bolj zapleteni za posnemanje baz podatkov SQL.

Poizvedovanje po zbirkah podatkov NoSQL

Strukturirani poizvedbeni jezik, ki ga uporabljajo tradicionalne zbirke podatkov, zagotavlja enoten način komunikacije s strežnikom pri shranjevanju in pridobivanju podatkov. Sintaksa SQL je zelo standardizirana, zato lahko posamezne zbirke podatkov nekatere operacije obravnavajo drugače (npr. Okenske funkcije), vendar osnove ostajajo enake.

Nasprotno pa ima vsaka baza podatkov NoSQL svojo sintakso za poizvedovanje in upravljanje podatkov. CouchDB, na primer, uporablja zahteve v obliki JSON, poslane prek HTTP, za ustvarjanje ali pridobivanje dokumentov iz svoje baze podatkov. MongoDB pošilja predmete JSON prek binarnega protokola prek vmesnika ukazne vrstice ali jezikovne knjižnice.

Nekateri izdelki NoSQL lahko za delo s podatki uporabite sintakso, podobno SQL-u, vendar le v omejenem obsegu. Na primer, Apache Cassandra, baza podatkov v stolpcih, ima svoj jezik, podoben SQL, jezik poizvedbe Cassandra ali CQL. Nekatere sintakse CQL so naravnost zunaj zbirke SQL, na primer ključne besede SELECT ali INSERT. Toda v Cassandri ni mogoče izvesti JOIN ali podpoizvedbe, zato povezane ključne besede v CQL ne obstajajo.

Arhitektura nič v skupni rabi

Izbira oblikovanja, ki je skupna sistemom NoSQL, je arhitektura »v skupnem ničemer«. V načrtu skupne ničesar vsako vozlišče strežnika v gruči deluje neodvisno od vsakega drugega vozlišča. Za vrnitev dela podatkov odjemalcu sistemu ni treba doseči soglasja vsakega posameznega vozlišča. Poizvedbe so hitre, saj jih je mogoče vrniti s katerega koli vozlišča, ki je najbližje ali najbolj priročno.

Druga prednost skupnega niča je prožnost in razširitev. Skaliranje gruče je tako enostavno kot predenje novih vozlišč v gruči in čakanje, da se sinhronizirajo z drugimi. Če vozlišče NoSQL propade, se bodo drugi strežniki v gruči še naprej pomešali. Vsi podatki ostanejo na voljo, tudi če je na voljo manj vozlišč za servisiranje zahtev.

Upoštevajte, da zasnova v skupni rabi ni izključno v zbirke podatkov NoSQL. Številne običajne sisteme SQL je mogoče nastaviti na način, ki ni v skupni rabi, čeprav to običajno vključuje žrtvovanje doslednosti v celotni gruči zaradi uspešnosti.

Omejitve NoSQL

Če NoSQL zagotavlja toliko svobode in prilagodljivosti, zakaj ne bi popolnoma opustili SQL? Preprost odgovor: Številne aplikacije še vedno zahtevajo vrste omejitev, doslednost in zaščite, ki jih nudijo podatkovne baze SQL. V teh primerih se lahko nekatere "prednosti" NoSQL spremenijo v slabosti. Druge omejitve izhajajo iz dejstva, da so sistemi NoSQL razmeroma novi.

Brez sheme

Tudi če jemljete podatke v prosti obliki, jim morate skoraj vedno naložiti omejitve, da bodo koristni. Z NoSQL nalaganje omejitev vključuje prenos odgovornosti z baze podatkov na razvijalca aplikacije. Na primer, razvijalec bi lahko naložil strukturo s sistemom relacijskega preslikavanja objektov ali ORM. Če pa želite, da shema živi s samimi podatki, NoSQL tega običajno ne počne.

Nekatere rešitve NoSQL ponujajo neobvezne mehanizme za tipkanje in preverjanje podatkov. Na primer, Apache Cassandra ima množico izvornih podatkovnih tipov, ki spominjajo na tiste, ki jih najdemo v običajnem SQL.

Morebitna doslednost

Sistemi NoSQL trgujejo z močno ali takojšnjo doslednostjo za boljšo razpoložljivost in zmogljivost. Konvencionalne zbirke podatkov zagotavljajo, da operacije potekajo atomska (vsi deli transakcije uspejo ali nobeni ne), dosledno (vsi uporabniki imajo enak pogled na podatke), izoliran (transakcije ne tekmujejo) in trajna (po zaključku bodo preživeli napako strežnika).

Te štiri lastnosti, skupaj imenovane ACID, se v večini sistemov NoSQL obravnavajo različno. Namesto takojšnje doslednosti v gruči imate morebitni doslednost zaradi časa, potrebnega za kopiranje posodobitev na druga vozlišča v gruči. Podatki, vstavljeni v gručo, so sčasoma na voljo povsod, vendar ne morete zagotoviti, kdaj.

Semantika transakcije, ki v sistemu SQL zagotavlja, da so vsi koraki v transakciji (npr. Izvedba prodaje in zmanjšanje zalog) bodisi dokončani bodisi znižani, običajno niso na voljo v NoSQL. Za vsak sistem, v katerem mora obstajati "en vir resnice", na primer banka, pristop NoSQL ne bo deloval dobro. Nočete, da je stanje na vašem bančnem računu drugačno, odvisno od tega, na kateri bankomat greste; želite, da se povsod poroča o isti stvari.

Nekatere zbirke podatkov NoSQL imajo delne mehanizme za to. MongoDB ima na primer zagotovila o skladnosti za posamezne operacije, ne pa tudi za zbirko podatkov kot celoto. Microsoft Azure CosmosDB vam omogoča, da izberete raven doslednosti na zahtevo, tako da lahko izberete vedenje, ki ustreza vašemu primeru uporabe. Toda pri NoSQL pričakujte morebitno doslednost kot privzeto vedenje.

NoSQL zaklepanje

Večina sistemov NoSQL je konceptualno podobni, vendar so izvedeno zelo različno. Vsak ima ponavadi svoje metafore in mehanizme za poizvedbo in upravljanje podatkov.

Eden od stranskih učinkov tega je potencialno visoka stopnja povezave med aplikacijsko logiko in bazo podatkov. To ni tako slabo, če izberete sistem NoSQL in se ga držite, vendar lahko postane kamen spotike, če sistem spremenite po cesti.

Če migrirate iz recimo MongoDB v CouchDB (ali obratno), morate narediti več kot le selitev podatkov. Prav tako morate krmariti po razlikah v dostopu do podatkov in programskih metaforah - z drugimi besedami, prepisati morate dele aplikacije, ki dostopajo do baze podatkov.

Spretnosti NoSQL

Druga slabost NoSQL je relativno pomanjkanje strokovnega znanja. Kjer je trg običajnih talentov za SQL še vedno precej velik, trg za spretnosti NoSQL šele nastaja.

Za referenco Indeed.com poroča, da je konec leta 2017 obseg seznamov opravil za običajne zbirke podatkov SQL - MySQL, Microsoft SQL Server, Oracle Database itd. - v zadnjih treh letih višji od obsega opravil. za MongoDB, Couchbase in Cassandra. Povpraševanje po strokovnem znanju NoSQL narašča, vendar je to še vedno del trga za običajni SQL.

Združevanje SQL in NoSQL

Pričakujemo lahko, da bodo nekatere razlike med sistemoma SQL in NoSQL sčasoma izginile. Številne zbirke podatkov SQL že sprejemajo dokumente JSON kot izvorni podatkovni tip in lahko izvajajo poizvedbe glede teh podatkov. Nekateri imajo celo izvorne načine za nalaganje omejitev podatkov JSON, tako da se z njimi ravna enako strogo kot običajni podatki vrstice in stolpca.

Na drugi strani pa zbirke podatkov NoSQL ne dodajajo samo poizvedbenih jezikov, podobnih SQL, temveč tudi druge zmogljivosti tradicionalnih baz podatkov SQL. Na primer, vsaj dve zbirki podatkov dokumentov - MarkLogic in RavenDB - obljubljata, da sta združljivi s standardom ACID.

Tu in tam se kažejo znaki, da bodo prihodnje generacije baz podatkov razširile paradigme in ponudile funkcije NoSQL in SQL. Microsoftov Azure Cosmos DB, na primer, uporablja nabor primitivov pod pokrovom za izmenično reprodukcijo vedenja obeh vrst sistemov. Google Cloud Spanner je baza podatkov SQL, ki združuje močno skladnost z vodoravno razširljivostjo sistemov NoSQL.

Kljub temu bodo čisti SQL in čisti NoSQL sistemi imeli svoje mesto še vrsto let. Poiščite NoSQL za hiter, zelo razširljiv dostop do podatkov v prosti obliki. To vključuje nekaj stroškov, na primer doslednost branja in druge zaščitne ukrepe, ki so skupni bazam podatkov SQL. Toda za številne aplikacije se morda s temi zaščitnimi ukrepi splača trgovati za tisto, kar ponuja NoSQL.

$config[zx-auto] not found$config[zx-overlay] not found