Viena no būtiskākajām izvēlēm, kas jāizdara, izstrādājot lietojumprogrammu, ir tas, vai datu glabāšanai izmantot SQL vai NoSQL datu bāzi. Parastās SQL (t.i., relāciju) datu bāzes ir gadu desmitiem ilgas tehnoloģiju attīstības, labās prakses un reālās pasaules stresa testēšanas rezultāts. Tie ir paredzēti uzticamiem darījumiem un ad hoc vaicājumiem - biznesa lietojumprogrammu pamatprincipiem. Bet viņiem ir arī noteikti ierobežojumi, piemēram, stingra shēma, kas padara tos mazāk piemērotus cita veida lietotnēm.
NoSQL datubāzes radās, reaģējot uz šiem ierobežojumiem. NoSQL sistēmas glabā un pārvalda datus tādā veidā, kas ļauj izstrādātājiem nodrošināt lielu darbības ātrumu un lielu elastību. Daudzus izstrādāja tādi uzņēmumi kā Google, Amazon, Yahoo un Facebook, kas meklēja labākus veidus, kā uzglabāt saturu vai apstrādāt datus masveida vietnēm. Atšķirībā no SQL datu bāzēm, daudzas NoSQL datubāzes var horizontāli mērogot simtiem vai tūkstošiem serveru.
NoSQL priekšrocības tomēr nenāk bez maksas. NoSQL sistēmas parasti nenodrošina tādu pašu datu konsekvences līmeni kā SQL datu bāzes. Patiesībā, lai gan SQL datu bāzes tradicionāli ir upurējušas veiktspēju un mērogojamību ACID īpašībām aiz uzticamiem darījumiem, NoSQL datubāzes lielā mērā ir atcēlušas šīs ACID ātruma un mērogojamības garantijas.
Īsāk sakot, SQL un NoSQL datubāzes piedāvā dažādus kompromisus. Kaut arī viņi var sacensties kāda konkrēta projekta kontekstā, piemēram, kurā izvēlēties šo pieteikums vai to pielietojums - tie ir papildinoši plašākā attēlā. Katrs no tiem ir piemērots dažādiem lietošanas gadījumiem. Lēmums nav tik daudz vai nu viens, vai arī jautājums, kurš rīks ir piemērots šim darbam.
NoSQL pret SQL
Būtiskā atšķirība starp SQL un NoSQL nav tik sarežģīta. Katram no tiem ir atšķirīga filozofija par to, kā dati jāuzglabā un jāatgūst.
Izmantojot SQL datu bāzes, visiem datiem ir raksturīga struktūra. Parastā datu bāzē, piemēram, Microsoft SQL Server, MySQL vai Oracle Database, tiek izmantots shēma—Formāla definīcija tam, kā tiks veidoti datu bāzē ievietotie dati. Piemēram, dotajā tabulas kolonnā var būt tikai veseli skaitļi. Rezultātā kolonnā ierakstītajiem datiem būs augsta normalizācijas pakāpe. Stingra SQL datu bāzes shēma arī ļauj salīdzinoši viegli veikt datu apkopošanu, piemēram, izmantojot JOIN.
Izmantojot NoSQL, datus var glabāt bez shēmas vai brīvā formā. Jebkurus datus var saglabāt jebkurā ierakstā. Starp NoSQL datu bāzēm jūs atradīsit četrus izplatītus datu glabāšanas modeļus, kas noved pie četriem izplatītākajiem NoSQL sistēmu veidiem:
- Dokumentu datu bāzes (piemēram, CouchDB, MongoDB). Ievietotie dati tiek glabāti brīvas formas JSON struktūru vai “dokumentu” veidā, kur dati var būt jebkas, sākot no veseliem skaitļiem līdz virknēm līdz brīvas formas tekstam. Nav raksturīgi norādīt, kādus laukus, ja tādi ir, dokumentā.
- Galveno vērtību veikali (piem., Redis, Riak). Brīvas formas vērtībām - sākot no vienkāršiem skaitļiem vai virknēm līdz sarežģītiem JSON dokumentiem - datu bāzē var piekļūt, izmantojot atslēgas.
- Plaši kolonnu veikali (piem., HBase, Kasandra). Dati tiek glabāti kolonnās, nevis rindās, kā parastajā SQL sistēmā. Jebkuru kolonnu skaitu (un līdz ar to daudz dažādu datu veidu) var grupēt vai apkopot pēc nepieciešamības vaicājumiem vai datu skatiem.
- Grafiku datu bāzes (piem., Neo4j). Dati tiek attēloti kā entītiju un to attiecību tīkls vai grafiks, un katrs diagrammas mezgls ir brīvas formas datu kopa.
Datu glabāšana bez shēmas ir noderīga šādos gadījumos:
- Jūs vēlaties ātri piekļūt datiem, un jūs vairāk uztrauc piekļuves ātrums un vienkāršība, nevis uzticami darījumi vai konsekvence.
- Jūs glabājat lielu datu apjomu un nevēlaties sevi ieslēgt shēmā, jo shēmas maiņa vēlāk varētu būt lēna un sāpīga.
- Jūs uzņemat nestrukturētus datus no viena vai vairākiem avotiem, kas tos rada, un vēlaties saglabāt datus sākotnējā formā, lai nodrošinātu maksimālu elastību.
- Jūs vēlaties saglabāt datus hierarhiskā struktūrā, taču vēlaties, lai šīs hierarhijas aprakstītu paši dati, nevis ārēja shēma. NoSQL ļauj nejauši atsaukties uz datiem tādos veidos, kādus SQL datu bāzēm ir sarežģītāk atdarināt.
NoSQL datu bāzu pieprasīšana
Strukturētā vaicājumu valoda, ko izmanto tradicionālās datu bāzes, nodrošina vienotu veidu, kā sazināties ar serveri, uzglabājot un izgūstot datus. SQL sintakse ir ļoti standartizēta, tāpēc, lai gan atsevišķas datu bāzes var apstrādāt noteiktas darbības atšķirīgi (piemēram, loga funkcijas), pamati paliek nemainīgi.
Turpretī katrai NoSQL datu bāzei mēdz būt sava sintakse datu vaicājumiem un pārvaldībai. Piemēram, CouchDB izmanto pieprasījumus JSON formā, kas nosūtīti caur HTTP, lai izveidotu vai izgūtu dokumentus no savas datu bāzes. MongoDB nosūta JSON objektus, izmantojot bināru protokolu, izmantojot komandrindas saskarni vai valodu bibliotēku.
Daži NoSQL produkti var darbam ar datiem izmantojiet SQL līdzīgu sintaksi, bet tikai ierobežotā apjomā. Piemēram, kolonnu krātuves datu bāzei Apache Cassandra ir sava SQL veida valoda - Cassandra Query Language vai CQL. Daļa no CQL sintakses ir tieši ārpus SQL atskaņošanas grāmatas, piemēram, SELECT vai INSERT atslēgvārdi. Bet Kasandrā nav iespējams veikt JOIN vai apakšvaicājumu, un tādējādi saistītie atslēgvārdi CQL nepastāv.
Shared-nothing arhitektūra
NoSQL sistēmām kopīga dizaina izvēle ir “koplietojama nekas” arhitektūra. Koplietojamā nekā noformējumā katrs klastera servera mezgls darbojas neatkarīgi no visiem citiem mezgliem. Sistēmai nav jāpanāk vienprātība no katra atsevišķa mezgla, lai klientam atgrieztu kādu datu daļu. Vaicājumi ir ātri, jo tos var atgriezt no tā, kurš mezgls ir vistuvākais vai ērtākais.
Vēl viena dalītā nekā priekšrocība ir elastība un paplašināšana. Klastera mērogošana ir tikpat vienkārša kā jaunu mezglu vērpšana un gaidīšana, kamēr tie sinhronizēsies ar citiem. Ja NoSQL mezgls iet uz leju, pārējie klastera serveri turpinās darboties. Visi dati paliek pieejami, pat ja pieprasījumu apkalpošanai ir pieejams mazāk mezglu.
Ņemiet vērā, ka kopīgota nekā noformējums nav ekskluzīvs uz NoSQL datu bāzēm. Daudzas parastās SQL sistēmas var izveidot koplietojamā veidā, lai gan tas parasti ietver konsekvences upurēšanu visā klasterī veiktspējas nodrošināšanai.
NoSQL ierobežojumi
Ja NoSQL nodrošina tik daudz brīvības un elastības, kāpēc gan pilnībā neatstāt SQL? Vienkārša atbilde: Daudzās lietojumprogrammās joprojām ir nepieciešami ierobežojumi, konsekvence un aizsardzības veidi, ko nodrošina SQL datu bāzes. Šādos gadījumos dažas NoSQL “priekšrocības” var kļūt par trūkumiem. Citi ierobežojumi izriet no fakta, ka NoSQL sistēmas ir salīdzinoši jaunas.
Nav shēmas
Pat ja jūs uzņemat brīvas formas datus, jums tas gandrīz vienmēr ir jānosaka ierobežojumi, lai tie būtu noderīgi. Izmantojot NoSQL, ierobežojumu uzlikšana ietver atbildības novirzīšanu no datu bāzes uz lietojumprogrammu izstrādātāju. Piemēram, izstrādātājs varētu uzlikt struktūru, izmantojot objektu relāciju kartēšanas sistēmu vai ORM. Bet, ja vēlaties, lai shēma darbotos ar pašiem datiem, NoSQL parasti to nedara.
Daži NoSQL risinājumi nodrošina izvēles datu tipēšanu un datu validācijas mehānismus. Piemēram, Apache Cassandra ir daudz vietējo datu tipu, kas atgādina tos, kas sastopami parastajā SQL.
Galīgā konsekvence
NoSQL sistēmu tirdzniecība ir spēcīga vai tūlītēja, lai nodrošinātu labāku pieejamību un veiktspēju. Parastās datu bāzes nodrošina, ka darbības tiek veiktas atomu (visas darījuma daļas izdodas vai neviena nedarbojas), konsekventi (visiem lietotājiem ir vienāds datu skatījums), izolēts (darījumi nekonkurē) un izturīgs (pēc pabeigšanas viņi pārdzīvos servera kļūmi).
Šīs četras īpašības, kuras kopā dēvē par ACID, lielākajā daļā NoSQL sistēmu tiek apstrādātas atšķirīgi. Tā vietā, lai visā klasterī būtu tūlītēja konsekvence, jums tas ir galu galā konsekvence, ņemot vērā laiku, kas nepieciešams kopiju atjauninājumu kopēšanai uz citiem klastera mezgliem. Kopā ievietotie dati galu galā ir pieejami visur, taču jūs nevarat garantēt, kad.
Darījumu semantika, kas SQL sistēmā garantē, ka visi darījuma soļi (piemēram, pārdošanas veikšana un samazinoši krājumi) ir vai nu pabeigti, vai atcelti, parasti nav pieejami NoSQL. Jebkurai sistēmai, kurā jābūt “vienotam patiesības avotam”, piemēram, bankai, NoSQL pieeja nedarbosies labi. Jūs nevēlaties, lai jūsu bankas atlikums būtu atšķirīgs atkarībā no tā, kuru bankomātu izmantojat; jūs vēlaties, lai par to visur ziņotu par vienu un to pašu.
Dažām NoSQL datu bāzēm ir daļēji mehānismi, kā to novērst. Piemēram, MongoDB ir konsekvences garantijas atsevišķām darbībām, bet ne visai datu bāzei kopumā. Microsoft Azure CosmosDB ļauj katram pieprasījumam izvēlēties konsekvences līmeni, lai jūs varētu izvēlēties uzvedību, kas atbilst jūsu lietošanas gadījumam. Bet, izmantojot NoSQL, sagaidiet iespējamo konsekvenci kā noklusējuma uzvedību.
NoSQL bloķēšana
Lielākā daļa NoSQL sistēmu ir konceptuāli līdzīgi, bet ir ieviesta ļoti atšķirīgi. Katram no tiem mēdz būt savas metaforas un mehānismi, kā dati tiek vaicāti un pārvaldīti.
Viena no blakusparādībām ir potenciāli augsta saikne starp lietojumprogrammu loģiku un datu bāzi. Tas nav tik slikti, ja izvēlaties NoSQL sistēmu un turaties pie tās, taču tas var kļūt par klupšanas akmeni, ja maināt sistēmu pa ceļu.
Ja migrējat no, teiksim, no MongoDB uz CouchDB (vai otrādi), jums ir jādara vairāk nekā tikai datu migrēšana. Jums arī jāpārvietojas uz atšķirībām, kas saistītas ar piekļuvi datiem un programmatiskajām metaforām - citiem vārdiem sakot, jāpārraksta tās lietojumprogrammas daļas, kuras piekļūst datu bāzei.
NoSQL prasmes
Vēl viens NoSQL trūkums ir relatīvais zināšanu trūkums. Kur tradicionālo SQL talantu tirgus joprojām ir diezgan liels, NoSQL prasmju tirgus ir topošs.
Uzziņai Indeed.com ziņo, ka no 2017. gada beigām parasto SQL datu bāzu - MySQL, Microsoft SQL Server, Oracle Database un tā tālāk - darba vietu skaits pēdējos trīs gados joprojām ir lielāks nekā darba vietu skaits MongoDB, Couchbase un Cassandra. Pieprasījums pēc NoSQL zināšanām pieaug, taču tā joprojām ir daļa no tradicionālās SQL tirgus.
SQL un NoSQL apvienošana
Mēs varam sagaidīt, ka dažas atšķirības starp SQL un NoSQL sistēmām laika gaitā izzudīs. Jau tagad daudzas SQL datu bāzes pieņem JSON dokumentus kā vietējo datu tipu un var veikt vaicājumus pret šiem datiem. Dažiem pat ir dabiski veidi, kā uzlikt ierobežojumus JSON datiem, lai tie tiktu apstrādāti ar tādu pašu stingrību kā parastie rindu un kolonnu dati.
NoSQL datu bāzes ne tikai pievieno SQL līdzīgas vaicājumu valodas, bet arī citas tradicionālo SQL datu bāzu iespējas. Piemēram, vismaz divas dokumentu datubāzes - MarkLogic un RavenDB - solās būt saderīgas ar ACID.
Šeit un ir pazīmes, ka nākamās paaudzes datubāzes šķērsos paradigmas un piedāvās gan NoSQL, gan SQL funkcionalitāti. Piemēram, Microsoft Azure Cosmos DB zem pārsega izmanto primitīvu kopu, lai savstarpēji atveidotu abu veidu sistēmu uzvedību. Google Cloud Spanner ir SQL datu bāze, kas apvieno spēcīgu konsekvenci ar NoSQL sistēmu horizontālo mērogojamību.
Tomēr tīrajai SQL un tīrām NoSQL sistēmām būs sava vieta daudzus gadus uz priekšu. Meklējiet NoSQL ātru, ļoti pielāgojamu piekļuvi brīvas formas datiem. Tam ir dažas izmaksas, piemēram, lasījumu konsekvence un citi SQL datu bāzēm kopīgi aizsardzības pasākumi. Bet daudzām lietojumprogrammām šie drošības pasākumi var būt vērts tirgoties par to, ko piedāvā NoSQL.
