Yksi tärkeimmistä valinnoista sovellusta kehitettäessä on, käytetäänkö SQL- vai NoSQL-tietokantaa tietojen tallentamiseen. Tavanomaiset SQL-tietokannat (eli relaatiotietokannat) ovat vuosikymmenien tekniikan kehityksen, hyvien käytäntöjen ja todellisen stressitestin tulos. Ne on suunniteltu luotettaviin tapahtumiin ja tapauskohtaisiin kyselyihin, jotka ovat liiketoimintasovellusten katkoksia. Mutta heitä rasittaa myös rajoitukset - kuten jäykkä skeema - jotka tekevät niistä vähemmän sopivia muun tyyppisiin sovelluksiin.
NoSQL-tietokannat syntyivät vastauksena näihin rajoituksiin. NoSQL-järjestelmät tallentavat ja hallitsevat tietoja tavoilla, jotka mahdollistavat kehittäjien nopean toimintanopeuden ja suuren joustavuuden. Monet on kehittänyt yritykset, kuten Google, Amazon, Yahoo ja Facebook, jotka etsivät parempia tapoja tallentaa sisältöä tai käsitellä tietoja massiivisille verkkosivustoille. Toisin kuin SQL-tietokannoissa, monet NoSQL-tietokannat voidaan skaalata vaakasuunnassa satojen tai tuhansien palvelimien kesken.
NoSQL: n edut eivät kuitenkaan tule ilman kustannuksia. NoSQL-järjestelmät eivät yleensä tarjoa samaa tasoa tietojen johdonmukaisuutta kuin SQL-tietokannat. Itse asiassa, kun SQL-tietokannat ovat perinteisesti uhranneet suorituskyvyn ja skaalautuvuuden luotettavien tapahtumien takana oleville ACID-ominaisuuksille, NoSQL-tietokannat ovat suurelta osin ohittaneet nämä ACID-takuut nopeudelle ja skaalautuvuudelle.
Lyhyesti sanottuna SQL- ja NoSQL-tietokannat tarjoavat erilaisia kompromisseja. Vaikka he voivat kilpailla tietyn projektin yhteydessä - kuten missä, mihin valita Tämä sovellus tai että sovellus - ne täydentävät toisiaan laajemmassa kuvassa. Jokainen sopii erilaisiin käyttötapauksiin. Päätös ei ole niinkään jommankumman / tai tapaus, vaan kysymys siitä, mikä työkalu sopii työhön.
NoSQL vs. SQL
Perusero SQL: n ja NoSQL: n välillä ei ole niin monimutkainen. Jokaisella on erilainen filosofia siitä, miten tietoja tulisi tallentaa ja noutaa.
SQL-tietokannoissa kaikilla tiedoilla on luontainen rakenne. Perinteinen tietokanta, kuten Microsoft SQL Server, MySQL tai Oracle Database, käyttää a skeema- muodollinen määritelmä siitä, miten tietokantaan lisättävät tiedot muodostetaan. Esimerkiksi taulukon tietty sarake voidaan rajoittaa vain kokonaislukuihin. Tämän seurauksena sarakkeeseen tallennetuilla tiedoilla on korkea normalisoitumisaste. SQL-tietokannan jäykän skeeman avulla on myös suhteellisen helppoa suorittaa aggregaatit tiedoille esimerkiksi JOIN-tiedostojen avulla.
NoSQL: n avulla tietoja voidaan tallentaa skeemattomasti tai vapaamuotoisesti. Kaikki tiedot voidaan tallentaa mihin tahansa tietueeseen. NoSQL-tietokannoista löydät neljä yleistä mallia tietojen tallentamiseen, jotka johtavat neljään yleiseen NoSQL-järjestelmätyyppiin:
- Asiakirjatietokannat (esim. CouchDB, MongoDB). Lisätyt tiedot tallennetaan vapaamuotoisina JSON-rakenteina tai "asiakirjoina", joissa data voi olla mitä tahansa kokonaislukuista merkkijonoihin vapaamuotoiseen tekstiin. Ei ole luontaista tarvetta määrittää, mitä kenttiä asiakirjassa mahdollisesti on.
- Avainarvomyymälät (esim. Redis, Riak). Vapaamuotoisiin arvoihin - yksinkertaisista kokonaisluvuista tai merkkijonoista monimutkaisiin JSON-asiakirjoihin - pääsee tietokannassa avaimilla.
- Laaja sarakekauppa (esim. HBase, Cassandra). Tiedot tallennetaan sarakkeisiin rivien sijaan kuten tavanomaisessa SQL-järjestelmässä. Mikä tahansa määrä sarakkeita (ja siksi monia erityyppisiä tietoja) voidaan ryhmitellä tai koota kyselyihin tai tietonäkymiin tarpeen mukaan.
- Kuvaajatietokannat (esim. Neo4j). Tiedot esitetään verkostona tai kaaviona entiteeteistä ja niiden suhteista, jolloin kaavion kukin solmu on vapaamuotoinen tietopala.
Skeematon tiedonsiirto on hyödyllistä seuraavissa tilanteissa:
- Haluat nopean pääsyn tietoihin ja olet enemmän huolissasi pääsyn nopeudesta ja yksinkertaisuudesta kuin luotettavista tapahtumista tai johdonmukaisuudesta.
- Tallennat suuren määrän dataa, etkä halua lukita itseäsi malliin, koska mallin muuttaminen myöhemmin voi olla hidasta ja tuskallista.
- Otat rakentamattomia tietoja yhdestä tai useammasta lähteestä, jotka tuottavat sen, ja haluat säilyttää tiedot alkuperäisessä muodossaan mahdollisimman joustavan.
- Haluat tallentaa tietoja hierarkkiseen rakenteeseen, mutta haluat, että nämä hierarkiat kuvataan itse tiedoissa, ei ulkoisissa kaavioissa. NoSQL sallii datan olla rennosti itseviittaavaa tavoilla, joita SQL-tietokantojen jäljitteleminen on monimutkaisempaa.
NoSQL-tietokantojen kysely
Perinteisten tietokantojen käyttämä strukturoitu kyselykieli tarjoaa yhtenäisen tavan kommunikoida palvelimen kanssa tallennettaessa ja noudettaessa tietoja. SQL-syntakse on erittäin standardoitu, joten vaikka yksittäiset tietokannat saattavat käsitellä tiettyjä toimintoja eri tavoin (esim. Ikkunatoiminnot), perusasiat pysyvät samana.
Sitä vastoin jokaisella NoSQL-tietokannalla on yleensä oma syntaksinsa tietojen kyselyyn ja hallintaan. Esimerkiksi CouchDB käyttää HTTP: n kautta lähetettyjä JSON-muodossa olevia pyyntöjä asiakirjojen luomiseen tai hakemiseen tietokannastaan. MongoDB lähettää JSON-objektit binaariprotokollan kautta komentoriviliittymän tai kielikirjaston avulla.
Jotkut NoSQL-tuotteet voi käytä SQL-tyyppistä syntaksia tietojen käsittelyyn, mutta vain rajoitetusti. Esimerkiksi sarakemyymälätietokannalla Apache Cassandralla on oma SQL-tyyppinen kielensä, Cassandra Query Language tai CQL. Osa CQL-syntaksista on suoraan ulos SQL-pelikirjasta, kuten SELECT- tai INSERT-avainsanat. JOIN tai alikysely ei kuitenkaan ole mahdollista suorittaa Cassandrassa, joten CQL: ssä ei ole siihen liittyviä avainsanoja.
Jaettu-ei-arkkitehtuuri
NoSQL-järjestelmille yhteinen suunnitteluvalinta on "jaettu ei mitään" -arkkitehtuuri. Jaetussa ei mitään -rakenteessa kukin klusterin palvelinsolmu toimii itsenäisesti kaikista muista solmuista. Järjestelmän ei tarvitse saada yksimielisyyttä jokaisesta solmusta palauttaakseen datan asiakkaalle. Kyselyt ovat nopeita, koska ne voidaan palauttaa mistä tahansa solmusta, joka on lähin tai kätevin.
Toinen jaetun ei-edun etu on joustavuus ja laajentaminen. Klusterin laajentaminen on yhtä helppoa kuin uusien ryhmiä solmimalla ja odottamalla niiden synkronoitumista muiden kanssa. Jos NoSQL-solmu menee alas, klusterin muut palvelimet jatkavat jatkamista. Kaikki tiedot ovat käytettävissä, vaikka pyyntöjen palvelemiseen olisi käytettävissä vähemmän solmuja.
Huomaa, että jaetun ei mitään -muotoilu ei ole yksinomainen NoSQL-tietokantoihin. Monet tavanomaiset SQL-järjestelmät voidaan asentaa jaetulla ei-tavalla-muodolla, vaikkakin tähän liittyy yleensä yhdenmukaisuuden uhraaminen koko klusterissa suorituskyvyn puolesta.
NoSQL-rajoitukset
Jos NoSQL tarjoaa niin paljon vapautta ja joustavuutta, miksi ei hylätä SQL: ää kokonaan? Yksinkertainen vastaus: Monet sovellukset vaativat edelleen SQL-tietokantojen tarjoamia rajoituksia, johdonmukaisuutta ja suojaa. Tällöin jotkut NoSQL: n "edut" saattavat muuttua haitoiksi. Muut rajoitukset johtuvat siitä, että NoSQL-järjestelmät ovat suhteellisen uusia.
Ei kaavaa
Vaikka ottaisit vapaamuotoisia tietoja, sinun on melkein aina asetettava sille rajoituksia, jotta niistä olisi hyötyä. NoSQL: n avulla rajoitusten asettaminen tarkoittaa vastuun siirtämistä tietokannasta sovelluskehittäjälle. Kehittäjä voi esimerkiksi asettaa rakenteen objektin relaatiokartoitusjärjestelmän tai ORM: n avulla. Mutta jos haluat, että skeema elää itse tietojen kanssa, NoSQL ei yleensä tee sitä.
Jotkut NoSQL-ratkaisut tarjoavat valinnaisia tietojen kirjoitus- ja validointimekanismeja. Esimerkiksi Apache Cassandralla on joukko alkuperäisiä tietotyyppejä, jotka muistuttavat perinteisessä SQL: ssä olevia.
Lopulta johdonmukaisuus
NoSQL-järjestelmät käyvät kauppaa vahvalla tai välittömällä johdonmukaisuudella paremman saatavuuden ja suorituskyvyn saavuttamiseksi. Tavanomaiset tietokannat varmistavat toiminnan olevan atomi- (kaikki liiketoimen osat onnistuvat tai kukaan ei onnistu), johdonmukainen (kaikilla käyttäjillä on sama näkymä tiedoista), eristetty (liiketoimet eivät kilpaile) ja kestävä (valmistuttuaan ne selviävät palvelinvirheestä).
Näitä neljää ominaisuutta, joita kutsutaan yhdessä ACIDiksi, käsitellään eri tavoin useimmissa NoSQL-järjestelmissä. Klusterin välisen välittömän yhtenäisyyden sijasta sinulla on lopulta johdonmukaisuus päivien kopioimiseksi klusterin muihin solmuihin. Klusteriin lisätty data on lopulta saatavilla kaikkialla, mutta et voi taata, milloin.
Tapahtumien semantiikka, joka SQL-järjestelmässä takaa, että kaikki tapahtuman vaiheet (esim. Myynnin suorittaminen) ja vähentävät varastot) ovat joko valmiita tai palautettuja, eivät yleensä ole saatavana NoSQL: ssä. Kaikissa järjestelmissä, joissa on oltava "yksi totuuden lähde", kuten pankki, NoSQL-lähestymistapa ei toimi hyvin. Et halua, että pankkitilisi on erilainen riippuen mistä pankkiautomaatista menet; haluat, että siitä raportoidaan samalla tavalla kaikkialla.
Joissakin NoSQL-tietokannoissa on osittaiset mekanismit tämän ratkaisemiseksi. Esimerkiksi MongoDB: llä on johdonmukaisuustakuut yksittäisille toiminnoille, mutta ei koko tietokannalle. Microsoft Azure CosmosDB: n avulla voit valita yhdenmukaisuuden tason pyyntöä kohden, jotta voit valita käyttäytymisen, joka sopii käyttötapaukseesi. NoSQL: n kanssa oletetaan kuitenkin, että oletuskäyttäytyminen on mahdollista.
NoSQL-lukitus
Useimmat NoSQL-järjestelmät ovat käsitteellisesti samanlaisia, mutta ovat toteutettu aivan eri tavalla. Jokaisella on yleensä omat metaforansa ja mekanisminsa tietojen kyselyyn ja hallintaan.
Yksi sivuvaikutus on mahdollisesti suuri yhteys sovelluslogiikan ja tietokannan välillä. Tämä ei ole niin paha, jos valitset NoSQL-järjestelmän ja pidät siitä kiinni, mutta siitä voi tulla kompastuskivi, jos vaihdat järjestelmää tiellä.
Jos siirryt esimerkiksi MongoDB: stä CouchDB: hen (tai päinvastoin), sinun on tehtävä muutakin kuin vain siirrettävä data. Sinun on myös navigoitava tietojen käyttöoikeuksien ja ohjelmallisten metaforojen erojen suhteen - toisin sanoen sinun on kirjoitettava uudelleen sovelluksen osat, jotka käyttävät tietokantaa.
NoSQL-taidot
Toinen NoSQL: n haittapuoli on suhteellinen asiantuntemuksen puute. Jos perinteisten SQL-kykyjen markkinat ovat edelleen melko suuret, NoSQL-taitojen markkinat ovat syntymässä.
Indeed.com kertoo, että vuoden 2017 lopusta lähtien perinteisten SQL-tietokantojen - MySQL, Microsoft SQL Server, Oracle Database ja niin edelleen - työluetteloiden määrä pysyy viimeisten kolmen vuoden aikana korkeampi kuin työpaikkojen määrä MongoDB, Couchbase ja Cassandra. NoSQL-asiantuntemuksen kysyntä kasvaa, mutta se on silti murto-osa perinteisen SQL: n markkinoista.
SQL: n ja NoSQL: n yhdistäminen
Voimme odottaa, että osa SQL- ja NoSQL-järjestelmien eroista häviää ajan myötä. Jo monet SQL-tietokannat hyväksyvät nyt JSON-asiakirjat natiiviksi tietotyypiksi ja voivat suorittaa kyselyjä kyseisiä tietoja vastaan. Joillakin on jopa alkuperäisiä tapoja asettaa rajoituksia JSON-tiedoille niin, että niitä käsitellään samalla tavoin kuin tavanomaisia rivi- ja saraketietoja.
Kääntöpuolella NoSQL-tietokannat lisäävät paitsi SQL-tyyppisiä kyselykieliä myös muita perinteisten SQL-tietokantojen ominaisuuksia. Esimerkiksi ainakin kaksi asiakirjatietokantaa - MarkLogic ja RavenDB - lupaavat olevan ACID-yhteensopivia.
Tässä ja on merkkejä siitä, että tulevien tietokantojen sukupolvet kulkevat paradigmojen välillä ja tarjoavat sekä NoSQL- että SQL-toiminnallisuutta. Esimerkiksi Microsoftin Azure Cosmos DB käyttää konepellin alla olevaa primitiivisarjaa toistamaan molempien järjestelmien käyttäytymisen vaihdettavasti. Google Cloud Spanner on SQL-tietokanta, joka yhdistää vahvan johdonmukaisuuden NoSQL-järjestelmien horisontaaliseen skaalautuvuuteen.
Silti puhtaalla SQL: llä ja puhtailla NoSQL-järjestelmillä on paikkansa tulevina vuosina. NoSQL: ltä saat nopean, skaalautuvan pääsyn vapaamuotoiseen dataan. Tähän liittyy muutamia kustannuksia, kuten lukujen johdonmukaisuus ja muut SQL-tietokannoille yhteiset suojatoimet. Mutta monissa sovelluksissa nämä suojatoimet saattavat olla kaupankäynnin arvoisia NoSQL: n tarjoamille tuotteille.
