Vienas iš esminių pasirinkimų, kuriuos reikia padaryti kuriant programą, yra tai, ar duomenims saugoti naudoti SQL, ar NoSQL duomenų bazę. Įprastos SQL (t. Y. Reliacinės) duomenų bazės yra dešimtmečių technologijos evoliucijos, gerosios praktikos ir realaus pasaulio streso testų produktas. Jie skirti patikimoms operacijoms ir ad hoc užklausoms - verslo programų pagrindams. Tačiau jiems taip pat taikomi apribojimai, pvz., Griežta schema, dėl kurių jie mažiau tinka kitų rūšių programoms.
„NoSQL“ duomenų bazės atsirado atsižvelgiant į šiuos apribojimus. „NoSQL“ sistemos saugo ir valdo duomenis taip, kad kūrėjai galėtų veikti greitai ir labai lanksčiai. Daugelį jų sukūrė tokios kompanijos kaip „Google“, „Amazon“, „Yahoo“ ir „Facebook“, kurios ieškojo geresnių būdų saugoti turinį ar apdoroti duomenis didžiulėms svetainėms. Skirtingai nuo SQL duomenų bazių, daugelį NoSQL duomenų bazių galima horizontaliai keisti šimtais ar tūkstančiais serverių.
Vis dėlto „NoSQL“ pranašumai nėra nemokami. „NoSQL“ sistemos paprastai nepateikia tokio paties lygio duomenų kaip ir SQL duomenų bazės. Tiesą sakant, nors SQL duomenų bazės tradiciškai aukojo našumą ir mastelį dėl ACID savybių, susijusių su patikimomis operacijomis, „NoSQL“ duomenų bazės iš esmės atmetė tas ACID greičio ir mastelio garantijas.
Trumpai tariant, SQL ir NoSQL duomenų bazės siūlo skirtingus kompromisus. Nors jie gali konkuruoti konkretaus projekto kontekste - kaip ir kuriame pasirinkti tai taikymas arba kad taikymas - jie papildo didesnį vaizdą. Kiekvienas iš jų tinka skirtingiems naudojimo atvejams. Sprendimas susijęs ne tiek su vienu, tiek su tuo, kuris įrankis yra tinkamiausias darbui.
„NoSQL“ ir „SQL“
Esminis skirtumas tarp SQL ir NoSQL nėra toks sudėtingas. Kiekvienas iš jų turi skirtingą filosofiją, kaip duomenys turėtų būti saugomi ir gaunami.
Naudojant SQL duomenų bazes, visi duomenys turi būdingą struktūrą. Įprastoje duomenų bazėje, tokioje kaip „Microsoft SQL Server“, „MySQL“ ar „Oracle Database“, naudojama a schema- oficialus apibrėžimas, kaip bus sudaryti į duomenų bazę įtraukti duomenys. Pavyzdžiui, pateiktas lentelės stulpelis gali būti apribotas tik sveikaisiais skaičiais. Todėl stulpelyje įrašyti duomenys bus labai normalizuoti. Dėl griežtos SQL duomenų bazės schemos taip pat gana lengva atlikti duomenų kaupimą, pvz., JOIN.
Naudojant „NoSQL“, duomenys gali būti saugomi be schemų arba laisvos formos. Bet kokie duomenys gali būti saugomi bet kuriame įraše. Tarp „NoSQL“ duomenų bazių rasite keturis įprastus duomenų saugojimo modelius, kurie lemia keturis įprastus „NoSQL“ sistemų tipus:
- Dokumentų duomenų bazės (pvz., „CouchDB“, „MongoDB“). Įterpti duomenys saugomi laisvos formos JSON struktūrų arba „dokumentų“ pavidalu, kur duomenys gali būti įvairūs: nuo sveikųjų skaičių iki eilučių iki laisvos formos teksto. Nereikia nurodyti, kokius laukus, jei tokių yra, dokumente bus.
- Pagrindinės vertės parduotuvės (pvz. Redis, Riak). Laisvos formos reikšmės - nuo paprastų sveikų skaičių ar eilučių iki sudėtingų JSON dokumentų - prieinamos duomenų bazėje naudojant raktus.
- Plačios kolonų parduotuvės (pvz., HBase, Cassandra). Duomenys saugomi stulpeliuose, o ne eilutėse, kaip įprastoje SQL sistemoje. Bet kokį stulpelių skaičių (taigi ir daug skirtingų duomenų tipų) galima sugrupuoti arba sujungti, jei reikia užklausoms ar duomenų rodiniams.
- Grafikų duomenų bazės (pvz., Neo4j). Duomenys pateikiami kaip objektų ir jų sąsajų tinklas arba grafikas, o kiekvienas grafo mazgas yra laisvos formos duomenų dalis.
Duomenų saugojimas be schemos yra naudingas šiais atvejais:
- Norite greito prieigos prie duomenų ir labiau rūpinatės prieigos greičiu ir paprastumu nei patikimomis operacijomis ar nuoseklumu.
- Saugote daug duomenų ir nenorite užsisklęsti schemoje, nes vėliau schemos keitimas gali būti lėtas ir skausmingas.
- Imate nestruktūrizuotus duomenis iš vieno ar daugiau juos generuojančių šaltinių ir norite, kad duomenys būtų kuo originalesni, kad būtų maksimaliai lankstus.
- Norite saugoti duomenis hierarchinėje struktūroje, tačiau norite, kad tas hierarchijas apibūdintų patys duomenys, o ne išorinė schema. „NoSQL“ leidžia atsainiai remtis duomenimis atsitiktinai tais būdais, kuriuos SQL duomenų bazėms sekti yra sudėtingiau.
Užklausa NoSQL duomenų bazėms
Tradicinių duomenų bazių naudojama struktūrinė užklausų kalba suteikia vienodą būdą bendrauti su serveriu, kai saugomi ir gaunami duomenys. SQL sintaksė yra labai standartizuota, todėl nors atskiros duomenų bazės gali skirtingai tvarkyti tam tikras operacijas (pvz., Lango funkcijas), pagrindai lieka tie patys.
Priešingai, kiekviena „NoSQL“ duomenų bazė paprastai turi savo sintaksę užklausoms ir duomenų tvarkymui. Pavyzdžiui, „CouchDB“ naudoja JSON formos užklausas, siunčiamas per HTTP, kad sukurtų ar gautų dokumentus iš savo duomenų bazės. „MongoDB“ siunčia JSON objektus dvejetainiu protokolu naudodamas komandų eilutės sąsają arba kalbų biblioteką.
Kai kurie „NoSQL“ produktai gali naudokite SQL tipo sintaksę darbui su duomenimis, bet tik ribotai. Pavyzdžiui, „Apache Cassandra“, stulpelių saugyklos duomenų bazė, turi savo į SQL panašią kalbą - „Cassandra Query Language“ arba CQL. Kai kurios CQL sintaksės yra tiesiai iš SQL grojaraščio, pavyzdžiui, raktiniai žodžiai „SELECT“ arba „INSERT“. Bet Cassandra jokiu būdu negali atlikti JOIN ar subquery, todėl CQL nėra susijusių raktinių žodžių.
„Shared-nothing“ architektūra
„NoSQL“ sistemoms būdingas dizaino pasirinkimas yra „nieko bendro“ architektūra. Kuriant „nieko bendro“ dizainą, visi sankaupos serverio mazgai veikia nepriklausomai nuo kitų mazgų. Sistema neprivalo gauti bendro sutarimo iš kiekvieno mazgo, kad klientui grąžintų dalį duomenų. Užklausos yra greitos, nes jas galima grąžinti iš bet kurio mazgo, kuris yra arčiausiai ar patogiausias.
Kitas bendro nieko privalumas yra atsparumas ir išplėtimas. Klasterio išplėtimas yra toks pat paprastas, kaip sukti naujus klasterio mazgus ir laukti, kol jie sinchronizuosis su kitais. Jei „NoSQL“ mazgas neveikia, kiti klasterio serveriai toliau tęsis. Visi duomenys lieka prieinami, net jei užklausoms aptarnauti yra mažiau mazgų.
Atkreipkite dėmesį, kad „nieko bendro“ dizainas nėra išskirtinis į NoSQL duomenų bazes. Daugelis įprastų SQL sistemų gali būti sukurtos bendru nieku būdu, nors tai paprastai reiškia nuoseklumo aukojimą klasteryje dėl našumo.
NoSQL apribojimai
Jei „NoSQL“ suteikia tiek daug laisvės ir lankstumo, kodėl gi ne visiškai atsisakius SQL? Paprastas atsakymas: daugelyje programų vis dar reikalingi apribojimai, nuoseklumas ir apsaugos priemonės, kurias teikia SQL duomenų bazės. Tais atvejais kai kurie „NoSQL“ „pranašumai“ gali tapti trūkumais. Kiti apribojimai kyla dėl to, kad NoSQL sistemos yra palyginti naujos.
Nėra schemos
Net jei įvedate laisvos formos duomenis, beveik visada turite jiems nustatyti apribojimus, kad jie būtų naudingi. Naudojant „NoSQL“, apribojimų nustatymas reiškia atsakomybės perkėlimą iš duomenų bazės į programų kūrėją. Pvz., Kūrėjas gali primesti struktūrą naudodamasis objekto reliacinio atvaizdavimo sistema arba ORM. Bet jei norite, kad schema veiktų su pačiais duomenimis, „NoSQL“ paprastai to nedaro.
Kai kurie „NoSQL“ sprendimai suteikia pasirinktinius duomenų tipavimo ir duomenų patvirtinimo mechanizmus. Pavyzdžiui, „Apache Cassandra“ turi daugybę vietinių duomenų tipų, kurie primena tipinius SQL.
Galutinis nuoseklumas
„NoSQL“ sistemos parduoda tvirtą ar greitą nuoseklumą, kad būtų galima geriau naudotis ir našiau. Įprastos duomenų bazės užtikrina, kad operacijos yra atominis (visos operacijos dalys pavyksta arba nė viena nepavyksta), nuoseklus (visi vartotojai turi tą patį duomenų vaizdą), izoliuotas (sandoriai nekonkuruoja) ir patvarus (baigę jie išgyvens serverio gedimą).
Šios keturios savybės, bendrai vadinamos ACID, daugumoje NoSQL sistemų yra tvarkomos skirtingai. Vietoj to, kad klasteris būtų nedelsiant nuoseklus, jūs turite galiausiai nuoseklumas dėl laiko, reikalingo nukopijuoti naujinius į kitus sankaupos mazgus. Duomenys, įterpti į grupę, galiausiai yra prieinami visur, tačiau negalite garantuoti, kada.
Operacijų semantika, kuri SQL sistemoje garantuoja, kad visi operacijos veiksmai (pvz., Pardavimo vykdymas ir mažėjančios atsargos) yra baigtos arba sugrąžintos atgal, paprastai nėra „NoSQL“. Bet kuriai sistemai, kur turi būti „vienas tiesos šaltinis“, pavyzdžiui, bankui, „NoSQL“ metodas neveiks. Jūs nenorite, kad jūsų banko likutis skirtųsi priklausomai nuo to, kuriame bankomate einate; norite, kad visur būtų pranešama apie tą patį.
Kai kuriose „NoSQL“ duomenų bazėse yra daliniai mechanizmai, kaip tai išspręsti. Pavyzdžiui, „MongoDB“ garantuoja nuoseklumą atskiroms operacijoms, bet ne visai duomenų bazei. „Microsoft Azure CosmosDB“ leidžia pasirinkti kiekvienos užklausos nuoseklumo lygį, kad galėtumėte pasirinkti elgesį, kuris atitiktų jūsų naudojimo atvejį. Bet naudodamiesi „NoSQL“, numatytu elgesiu tikėkitės galimo nuoseklumo.
„NoSQL“ užraktas
Dauguma „NoSQL“ sistemų yra konceptualiai panašūs, bet yra įgyvendinta labai skirtingai. Kiekvienas iš jų linkęs turėti savo metaforas ir mechanizmus, kaip klausinėti ir tvarkyti duomenis.
Vienas šalutinis to poveikis yra potencialiai didelis programos logikos ir duomenų bazės susiejimo laipsnis. Tai nėra taip blogai, jei pasirinksite „NoSQL“ sistemą ir laikysitės jos, tačiau tai gali tapti kliūtimi, jei pakeisite sistemas kelyje.
Jei perkelsite iš, tarkime, „MongoDB“ į „CouchDB“ (arba atvirkščiai), turite atlikti ne tik duomenis. Taip pat turite naršyti duomenų prieigos ir programinių metaforų skirtumus - kitaip tariant, turite perrašyti tas programos dalis, kurios pasiekia duomenų bazę.
NoSQL įgūdžiai
Kitas „NoSQL“ trūkumas yra santykinis patirties trūkumas. Kur įprastų SQL talentų rinka vis dar yra gana didelė, „NoSQL“ įgūdžių rinka dar tik formuojasi.
Kaip nuorodą, „Indeed.com“ praneša, kad nuo 2017 m. Pabaigos įprastų SQL duomenų bazių - „MySQL“, „Microsoft SQL Server“, „Oracle Database“ ir kt. - darbų sąrašai per pastaruosius trejus metus išlieka didesni nei darbo vietų skaičius „MongoDB“, „Couchbase“ ir „Cassandra“. „NoSQL“ kompetencijos poreikis auga, tačiau tai vis dar yra tradicinės SQL rinkos dalis.
SQL ir NoSQL sujungimas
Galime tikėtis, kad laikui bėgant kai kurie skirtumai tarp SQL ir NoSQL sistemų išnyks. Jau dabar daugelis SQL duomenų bazių priima JSON dokumentus kaip vietinį duomenų tipą ir gali atlikti užklausas pagal tuos duomenis. Kai kurie netgi turi įprastus būdus nustatyti apribojimus JSON duomenims, kad jie būtų tvarkomi taip pat griežtai kaip ir įprasti eilutės ir stulpelio duomenys.
Kita vertus, NoSQL duomenų bazės ne tik prideda į SQL panašių užklausų kalbas, bet ir kitas tradicinių SQL duomenų bazių galimybes. Pavyzdžiui, mažiausiai dvi dokumentų duomenų bazės - „MarkLogic“ ir „RavenDB“ - žada atitikti ACID reikalavimus.
Čia ir yra ženklų, kad ateities kartos duomenų bazės peržengs paradigmas ir pasiūlys tiek NoSQL, tiek SQL funkcionalumą. Pavyzdžiui, „Microsoft“ „Azure Cosmos DB“ naudoja primityvų elementų rinkinį po gaubtu, kad būtų galima pakartoti abiejų tipų sistemų elgesį. „Google Cloud Spanner“ yra SQL duomenų bazė, sujungianti tvirtą nuoseklumą su horizontaliu „NoSQL“ sistemų masteliu.
Vis dėlto gryna SQL ir grynos NoSQL sistemos turės savo vietą daugeliui metų į priekį. Ieškokite „NoSQL“, kad gautumėte greitą, labai keičiamą prieigą prie laisvos formos duomenų. Tai reiškia keletą išlaidų, tokių kaip skaitymo nuoseklumas ir kitos SQL duomenų bazėms būdingos apsaugos priemonės. Tačiau daugeliu atvejų šiomis apsaugos priemonėmis verta prekiauti tuo, ką siūlo „NoSQL“.
