Et av de mest grunnleggende valgene du skal ta når du utvikler et program, er om du skal bruke en SQL- eller NoSQL-database for å lagre dataene. Konvensjonelle SQL (dvs. relasjonelle) databaser er produktet av flere tiår med teknologiutvikling, god praksis og stresstesting fra den virkelige verden. De er designet for pålitelige transaksjoner og ad hoc-spørsmål, stifter av forretningsapplikasjoner. Men de blir også tynget av begrensninger - for eksempel stivt skjema - som gjør dem mindre egnet for andre typer apper.
NoSQL-databaser oppsto som svar på disse begrensningene. NoSQL-systemer lagrer og administrerer data på måter som gir høy driftshastighet og stor fleksibilitet hos utviklerne. Mange ble utviklet av selskaper som Google, Amazon, Yahoo og Facebook som søkte bedre måter å lagre innhold eller behandle data på massive nettsteder. I motsetning til SQL-databaser kan mange NoSQL-databaser skaleres horisontalt over hundrevis eller tusenvis av servere.
Fordelene med NoSQL kommer ikke uten kostnad. NoSQL-systemer gir vanligvis ikke samme konsistensnivå som SQL-databaser. Faktisk, mens SQL-databaser tradisjonelt har ofret ytelse og skalerbarhet for ACID-egenskapene bak pålitelige transaksjoner, har NoSQL-databaser i stor grad fjernet de ACID-garantiene for hastighet og skalerbarhet.
Kort sagt, SQL- og NoSQL-databaser tilbyr forskjellige kompromisser. Mens de kan konkurrere i sammenheng med et bestemt prosjekt - som i, hva de skal velge dette søknad eller at applikasjon - de er komplementære i det større bildet. Hver er egnet for forskjellige bruksområder. Avgjørelsen er ikke så mye et tilfelle av enten / eller som det er et spørsmål om hvilket verktøy som er riktig for jobben.
NoSQL vs. SQL
Den grunnleggende forskjellen mellom SQL og NoSQL er ikke så komplisert. Hver har en annen filosofi for hvordan data skal lagres og hentes.
Med SQL-databaser har alle data en iboende struktur. En konvensjonell database som Microsoft SQL Server, MySQL eller Oracle Database bruker en skjema—En formell definisjon av hvordan data som settes inn i databasen vil bli sammensatt. For eksempel kan en gitt kolonne i en tabell være begrenset til heltall. Som et resultat vil dataene som er registrert i kolonnen ha en høy grad av normalisering. En SQL-databases stive skjema gjør det også relativt enkelt å utføre aggregeringer på dataene, for eksempel ved hjelp av JOINs.
Med NoSQL kan data lagres på en skjemafri eller fri form. Alle data kan lagres i alle poster. Blant NoSQL-databasene finner du fire vanlige modeller for lagring av data, som fører til fire vanlige typer NoSQL-systemer:
- Dokumentdatabaser (f.eks. CouchDB, MongoDB). Innsatte data lagres i form av friformede JSON-strukturer eller "dokumenter", der dataene kan være alt fra heltall til strenger til friformet tekst. Det er ikke noe iboende behov for å spesifisere hvilke felt, hvis noen, et dokument vil inneholde.
- Nøkkelverdibutikker (f.eks. Redis, Riak). Friformverdier - fra enkle heltall eller strenger til komplekse JSON-dokumenter - er tilgjengelige i databasen ved hjelp av nøkler.
- Brede kolonnebutikker (f.eks. HBase, Cassandra). Data lagres i kolonner i stedet for rader som i et vanlig SQL-system. Et hvilket som helst antall kolonner (og derfor mange forskjellige typer data) kan grupperes eller samles etter behov for spørsmål eller datavisninger.
- Grafdatabaser (f.eks. Neo4j). Data er representert som et nettverk eller en graf av enheter og deres forhold, med hver node i grafen et fritt stykke data.
Skjemafri datalagring er nyttig i følgende scenarier:
- Du vil ha rask tilgang til dataene, og du er mer opptatt av hastighet og enkel tilgang enn pålitelige transaksjoner eller konsistens.
- Du lagrer et stort datamengde, og du vil ikke låse deg selv inn i et skjema, ettersom endring av skjemaet senere kan være tregt og smertefullt.
- Du tar inn ustrukturerte data fra en eller flere kilder som produserer dem, og du vil beholde dataene i sin opprinnelige form for maksimal fleksibilitet.
- Du vil lagre data i en hierarkisk struktur, men du vil at disse hierarkiene skal beskrives av selve dataene, ikke et eksternt skjema. NoSQL tillater at data blir tilfeldig selvhenvisende på måter som er mer komplekse for SQL-databaser å etterligne.
Spørring av NoSQL-databaser
Structured Query Language som brukes av tradisjonelle databaser, gir en enhetlig måte å kommunisere med serveren når du lagrer og henter data. SQL-syntaks er høyst standardisert, så selv om individuelle databaser kan håndtere visse operasjoner forskjellig (f.eks. Vindusfunksjoner), forblir det grunnleggende det samme.
Derimot har hver NoSQL-database en tendens til å ha sin egen syntaks for spørring og administrering av dataene. CouchDB, for eksempel, bruker forespørsler i form av JSON, sendt via HTTP, for å opprette eller hente dokumenter fra databasen. MongoDB sender JSON-objekter over en binær protokoll, ved hjelp av et kommandolinjegrensesnitt eller et språkbibliotek.
Noen NoSQL-produkter kan bruke SQL-lignende syntaks til å jobbe med data, men bare i begrenset grad. For eksempel har Apache Cassandra, en kolonnelagerdatabase, sitt eget SQL-lignende språk, Cassandra Query Language eller CQL. Noe av CQL-syntaksen er rett ut av SQL-spillboken, som SELECT- eller INSERT-nøkkelordene. Men det er ingen måte å utføre et JOIN eller underforespørsel i Cassandra, og dermed eksisterer ikke de relaterte nøkkelordene i CQL.
Delt-ingenting-arkitektur
Et designvalg som er felles for NoSQL-systemer, er en "delt ingenting" -arkitektur. I en delt-ingenting-design fungerer hver servernode i klyngen uavhengig av hver annen node. Systemet trenger ikke å få konsensus fra hver enkelt node for å returnere et stykke data til en klient. Spørringene er raske fordi de kan returneres fra hvilken node som er nærmest eller mest praktisk.
En annen fordel med delt ingenting er elastisitet og utskalering. Å skalere ut klyngen er like enkelt som å spinne opp nye noder i klyngen og vente på at de skal synkroniseres med de andre. Hvis en NoSQL-node går ned, vil de andre serverne i klyngen fortsette å tulle sammen. All data forblir tilgjengelig, selv om færre noder er tilgjengelige for å betjene forespørsler.
Merk at et delt-ingenting-design ikke er det eksklusiv til NoSQL-databaser. Mange konvensjonelle SQL-systemer kan settes opp på en delt-ingenting måte, selv om det vanligvis innebærer å ofre konsistens over hele klyngen for ytelse.
NoSQL begrensninger
Hvis NoSQL gir så mye frihet og fleksibilitet, hvorfor ikke forlate SQL helt? Det enkle svaret: Mange applikasjoner krever fortsatt de slags begrensninger, konsistens og garantier som SQL-databaser gir. I slike tilfeller kan noen "fordeler" med NoSQL bli ulemper. Andre begrensninger stammer fra det faktum at NoSQL-systemer er relativt nye.
Ingen skjema
Selv om du tar inn data i fritt skjema, må du nesten alltid pålegge dem begrensninger for å gjøre det nyttig. Med NoSQL innebærer innføring av begrensninger å flytte ansvaret fra databasen til applikasjonsutvikleren. For eksempel kan utvikleren pålegge struktur gjennom et objektrelasjonskartleggingssystem, eller ORM. Men hvis du vil at skjemaet skal leve med selve dataene, NoSQL gjør det vanligvis ikke.
Noen NoSQL-løsninger gir valgfri datatyping og valideringsmekanismer for data. Apache Cassandra, for eksempel, har en rekke innfødte datatyper som minner om de som finnes i konvensjonell SQL.
Eventuell konsistens
NoSQL-systemer handler sterk eller umiddelbar konsistens for bedre tilgjengelighet og ytelse. Konvensjonelle databaser sørger for at operasjoner er atomisk (alle deler av en transaksjon lykkes, eller ingen gjør det), konsistent (alle brukere har samme visning av dataene), isolert (transaksjoner konkurrerer ikke), og varig (når de er fullført, vil de overleve en serverfeil).
Disse fire egenskapene, samlet kalt ACID, håndteres forskjellig i de fleste NoSQL-systemer. I stedet for umiddelbar konsistens på tvers av klyngen, har du det endelig konsistens, på grunn av tiden det tar å kopiere oppdateringer til andre noder i klyngen. Data satt inn i klyngen er til slutt tilgjengelig overalt, men du kan ikke garantere når.
Transaksjonssemantikk, som i et SQL-system garanterer at alle trinn i en transaksjon (for eksempel å utføre et salg og reduserende beholdning) er enten fullført eller tilbakevendende, er vanligvis ikke tilgjengelig i NoSQL. For ethvert system der det må være en "eneste kilde til sannhet", for eksempel en bank, fungerer NoSQL-tilnærmingen ikke bra. Du vil ikke at banksaldoen skal være forskjellig, avhengig av hvilken minibank du går til. du vil at det skal rapporteres som det samme overalt.
Noen NoSQL-databaser har delvise mekanismer for å omgå dette. For eksempel har MongoDB konsistensgarantier for individuelle operasjoner, men ikke for databasen som helhet. Microsoft Azure CosmosDB lar deg velge et konsistensnivå per forespørsel, slik at du kan velge atferden som passer din brukstilfelle. Men med NoSQL, forvent eventuell konsistens som standardadferd.
NoSQL-innlåsing
De fleste NoSQL-systemer er konseptuelt like, men er implementert veldig annerledes. Hver har en tendens til å ha sine egne metaforer og mekanismer for hvordan data blir spurt og administrert.
En bivirkning av det er en potensielt høy grad av kobling mellom applikasjonslogikken og databasen. Dette er ikke så ille hvis du velger et NoSQL-system og holder deg med det, men det kan bli en snublestein hvis du bytter system nedover veien.
Hvis du migrerer fra for eksempel MongoDB til CouchDB (eller omvendt), må du gjøre mer enn bare å migrere data. Du må også navigere i forskjellene i datatilgang og programmatiske metaforer - med andre ord, du må omskrive delene av applikasjonen din som får tilgang til databasen.
NoSQL ferdigheter
En annen ulempe med NoSQL er den relative mangelen på kompetanse. Der markedet for konvensjonelt SQL-talent fremdeles er ganske stort, er markedet for NoSQL-ferdigheter begynnende.
Som referanse rapporterer Indeed.com at fra slutten av 2017 forblir volumet på stillingsoppføringer for konvensjonelle SQL-databaser - MySQL, Microsoft SQL Server, Oracle Database og så videre - de siste tre årene enn volumet av jobber for MongoDB, Couchbase og Cassandra. Etterspørselen etter NoSQL-ekspertise øker, men det er fortsatt en brøkdel av markedet for konvensjonell SQL.
Slå sammen SQL og NoSQL
Vi kan forvente at noen av forskjellene mellom SQL- og NoSQL-systemer forsvinner over tid. Allerede mange SQL-databaser godtar nå JSON-dokumenter som en innfødt datatype, og kan utføre spørsmål mot disse dataene. Noen har til og med innfødte måter å pålegge begrensninger på JSON-data, slik at de håndteres med samme strenghet som konvensjonelle rad- og kolonnedata.
På baksiden legger NoSQL-databaser ikke bare til SQL-lignende spørringsspråk, men andre funksjoner i tradisjonelle SQL-databaser. For eksempel lover minst to dokumentdatabaser - MarkLogic og RavenDB - å være ACID-kompatible.
Her og der er tegn på at fremtidige generasjoner av databaser vil sprenge paradigmene og tilby både NoSQL- og SQL-funksjonalitet. Microsofts Azure Cosmos DB, for eksempel, bruker et sett med primitiver under panseret for å reprodusere oppførselen til begge typer systemer. Google Cloud Spanner er en SQL-database som kombinerer sterk konsistens med den horisontale skalerbarheten til NoSQL-systemer.
Likevel vil rene SQL og rene NoSQL-systemer ha sin plass i mange år fremover. Se til NoSQL for rask, meget skalerbar tilgang til data i fritt format. Dette kommer med noen få kostnader, som konsistens av lesing og andre sikkerhetsforanstaltninger som er vanlige for SQL-databaser. Men for mange applikasjoner kan disse garantiene være verdt å bytte for det NoSQL tilbyr.
