SQL eller NoSQL for systemet deres?
Velg en relasjonsdatabase (SQL) som standard, og bytt til NoSQL først når et konkret behov tilsier det. SQL gir deg transaksjoner, konsistens og frie ad hoc-spørringer gratis. NoSQL vinner ved enorme datamengder, fleksible skjemaer eller enkel nøkkel-verdi-lagring. De fleste systemer passer best i en relasjonsdatabase.
Valget mellom SQL og NoSQL høres ut som en teknisk detalj, men det former hvordan systemet ditt oppfører seg i mange år. Det er også et valg der trender og entusiasme ofte fører deg på villspor. Her er beslutningen på paradigmenivå, med en praktisk grunnregel du kan støtte deg på.
Hva relasjonsmodellen gir deg gratis
En relasjonsdatabase (SQL) lagrer data i tabeller med et fast skjema og tydelige relasjoner mellom dem. Den strukturen kan føles stiv, men den gir deg tre ting uten at du trenger å bygge dem selv.
- Transaksjoner. Flere endringer skjer helt eller ikke i det hele tatt. Et beløp trekkes fra én konto og havner på en annen i samme operasjon, aldri halvveis. Så snart penger, lager eller reservasjoner er involvert, er dette uvurderlig.
- Konsistens. Databasen passer på at dataene henger sammen. En ordre kan ikke peke på en kunde som ikke finnes hvis du har satt opp databasen til å håndheve det.
- Ad hoc-spørringer. Du kan stille spørsmål du ikke tenkte på da du bygde systemet, for eksempel «hvor mange kunder i en bestemt by bestilte mer enn tre ganger forrige kvartal», uten å ha forberedt akkurat den visningen. Det er enormt verdifullt når rapporteringsbehov dukker opp, og det gjør de alltid.
Det du betaler, er et skjema du må holde deg til, og litt mer omtanke i starten. For de aller fleste systemer er det verdt det.
Når NoSQL faktisk vinner
NoSQL er en paraplybetegnelse for databaser som bevisst avviker fra relasjonsmodellen. De løser reelle, men avgrensede problemer.
En dokumentdatabase lagrer hele objekter (for eksempel et produkt med alle variantene) som ett dokument. Det passer når data naturlig henger sammen i klumper og sjelden må sammenstilles med andre data, eller når strukturen varierer kraftig mellom postene.
En nøkkel-verdi-database er i bunn og grunn et gigantisk oppslagsverk: Gi en nøkkel, få en verdi, lynraskt. Perfekt for sesjoner, cache og enkel lagring i stor skala.
Den felles gevinsten er skala og fleksibilitet. NoSQL-databaser er bygget for å spres over mange servere og sluke enorme datamengder, og de tvinger deg ikke inn i et fast skjema. Prisen er at du ofte må gi opp frie spørringer og sterke transaksjonsgarantier: nøyaktig det relasjonsmodellen ga deg gratis.
Tommelfingerregelen: relasjonsdatabase til det motsatte er bevist
Hvis du er usikker, velg SQL. Det er grunnregelen erfarne team ender opp med, og årsaken er enkel: Relasjonsdatabasen er tilgivende. Den takler en uventet rapport, en ny relasjon og et voksende krav uten at du må bygge om. En moderne relasjonsdatabase skalerer dessuten langt: De fleste systemer når aldri det volumet der SQL blir flaskehalsen.
Bytt til NoSQL når du har et konkret, bevist behov: datamengder som én enkelt relasjonsdatabase ikke lenger håndterer, en ren nøkkel-verdi-last eller data med en struktur som varierer så mye at et skjema blir en tvangstrøye. Merk ordet bevist. «Vi må kanskje skalere som en global gigant» er sjelden et reelt behov for en virksomhet som ennå ikke har lansert.
NoSQL-valgene mange angrer på
Den typiske feilen ser lik ut gang på gang. Et team velger en dokumentdatabase tidlig, ofte fordi den føltes moderne og rask å komme i gang med. Alt går bra helt til virkeligheten tar dem igjen.
Først vil noen ha en rapport som kombinerer data på en ny måte. I en relasjonsdatabase ville det ha vært én spørring. Nå blir det et utviklingsprosjekt, for databasen er ikke laget for å koble sammen ting på den måten. Så vokser relasjonene frem likevel: Ordren må vite hvilken kunde den tilhører, og kunden må kjenne fakturaene sine. Man begynner å bygge relasjoner for hånd oppå en database som ble valgt nettopp for å slippe dem.
Slutten blir ofte en dyr migrering tilbake til SQL, eller en lappeløsning der forretningslogikk som databasen burde ha tatt seg av, lekker inn i applikasjonskoden. Det betyr ikke at NoSQL er dårlig. Det ble bare brukt til et problem det ikke var laget for.
Vurder derfor valget ut fra hva systemet faktisk skal gjøre. Trenger dere hjelp til å finne ut hvor systemet deres er på vei, ser vi i Weapp gjerne på datamodellen sammen med dere og drøfter valget før det setter seg i koden.
Ofte stilte spørsmål
Hva er den viktigste forskjellen på SQL og NoSQL?
SQL-databaser lagrer data i tabeller med et fast skjema og relasjoner mellom dem. NoSQL er en samlebetegnelse på databaser som avviker fra den modellen (dokumenter, nøkkel-verdi, grafer), ofte med løsere struktur. Den praktiske forskjellen er at SQL gir deg konsistens og frie spørringer gratis, mens NoSQL bytter bort noe av dette mot fleksibilitet og skala.
Er NoSQL raskere enn SQL?
Ikke generelt. NoSQL kan være raskere for bestemte mønstre, som å slå opp et dokument på nøkkel eller spre enorme datamengder over mange servere. Men for de fleste systemer med normale datamengder er en godt indeksert relasjonsdatabase minst like rask og betydelig mer tilgivende når spørringene endrer seg over tid.
Hva menes med transaksjoner, og hvorfor betyr de noe?
En transaksjon garanterer at flere endringer skjer helt eller ikke i det hele tatt: Et beløp trekkes fra én konto og settes inn på en annen i samme operasjon, aldri bare det ene. Relasjonsdatabaser gir dette som standard. I mange NoSQL-databaser er garantiene svakere eller begrensede, noe som blir et problem så snart penger, lager eller reservasjoner er involvert.
Kan man bruke både SQL og NoSQL i samme system?
Ja, og det er vanlig. En relasjonsdatabase kan romme forretningsdata og kjernelogikk mens en nøkkel-verdi-database håndterer sesjoner eller cache, og en søkeindeks tar seg av fritekstsøk. Poenget er å velge riktig verktøy for hvert behov, ikke at ett paradigme må vinne i hele systemet.
Hva er enklest når det gjelder rekruttering og vedlikehold?
SQL har et forsprang. Relasjonsdatabaser har eksistert i flere tiår, kompetansen er bred, og verktøyene er modne. NoSQL-kompetanse finnes, men er mer nisjepreget per produkt. For et lite team uten spesielle grunner er en relasjonsdatabase som regel billigst både å bemanne og å drifte over tid.