Det er hundrevis av tekniske tunge databasevurderinger der ute, men de gir ikke alltid klare retningslinjer for det første trinnet i å velge en database: velge den beste generelle typen for en bestemt applikasjon. Alle databaser er ikke opprettet like. Hver har spesifikke styrker og svakheter. Selv om det er sant at det finnes løsninger for å få en favorittdatabase til å fungere for de fleste prosjekter, gir bruk av disse triks unødvendig kompleksitet.
Før du vurderer en spesifikk database, bør du ta deg tid til å tenke på hvilken type som best støtter prosjektet. Spørsmålet går dypere enn "SQL vs. NoSQL." Les videre for en oversikt over de vanligste databasetypene, de relative fordelene til hver, og hvordan du kan fortelle hvilken som passer best.
Relasjonelle databasesystemer (Oracle, MySQL, MS Server, PostgreSQL)
Relasjonsdatabaser ble utviklet på 1970-tallet for å håndtere den økende flommen av data som produseres. De har en solid grunnleggende teori og har påvirket nesten alle databasesystemer som er i bruk i dag.
Relasjonsdatabaser lagrer datasett som “relasjoner”: tabeller med rader og kolonner der all informasjon er lagret som en verdi av en bestemt celle. Data i en RDBMS administreres ved hjelp av SQL. Selv om det er forskjellige implementeringer, er SQL standardisert og gir et nivå av forutsigbarhet og nytte.
Etter at en tidlig flom av leverandører prøvde å dra nytte av systemets popularitet med ikke helt relasjonelle produkter, skaper skaper E.F. Codd et sett med regler som må følges av alle relasjonelle databasestyringssystemer. Codds 12 regler dreier seg om å innføre strenge interne strukturprotokoller, og sørge for at søk pålitelig returnerer forespurte data, og forhindrer strukturelle endringer (i det minste av brukere). Rammeverket sørget for at relasjonsdatabaser er konsistente og pålitelige den dag i dag.
Styrker
Relasjonsdatabaser utmerker seg ved å håndtere høyt strukturerte data og gir støtte for ACID (Atomicity, Consistency, Isolation, and Durability) transaksjoner. Data lagres enkelt og hentes ved hjelp av SQL-spørringer. Strukturen kan raskt skaleres opp fordi det er enkelt å legge til data uten å endre eksisterende data.
Å lage grenser for hva bestemte brukertyper kan få tilgang til eller endre er innebygd i strukturen til en RDBMS. På grunn av dette er relasjonsdatabaser godt egnet for applikasjoner som krever trinnvis tilgang. For eksempel kan kunder se kontoene sine mens agenter både kan se og gjøre nødvendige endringer.
Svakheter
Den største svakheten ved relasjonsdatabaser er speilet av deres største styrke. Så gode som de er til å håndtere strukturerte data, har de det vanskelig med ustrukturerte data. Å representere enheter i den virkelige verden i sammenheng er vanskelig innenfor grensene til en RDBMS. "Skivede" data må settes sammen fra tabeller til noe mer leselig, og hastigheten kan påvirkes negativt. Det faste skjemaet reagerer heller ikke bra på endringer.
Kostnad er en vurdering med relasjonsdatabaser. De pleier å være dyrere å sette opp og vokse. Horisontal skalering, eller skalering ved å legge til flere servere, er vanligvis både raskere og mer økonomisk enn vertikal skalering, noe som innebærer å legge til flere ressurser til en server. Imidlertid kompliserer strukturen i relasjonsdatabaser prosessen. Sharding (der data er horisontalt partisjonert og distribuert over en samling maskiner) er nødvendig for å skalere ut en relasjonsdatabase. Å splitte relasjonsdatabaser mens du opprettholder ACID-samsvar, kan være en utfordring.
Bruk en relasjonsdatabase for:
- Situasjoner der dataintegritet er helt avgjørende (dvs. for økonomiske applikasjoner, forsvar og sikkerhet og privat helseinformasjon)
- Svært strukturerte data
- Automatisering av interne prosesser
Dokumentbutikk (MongoDB, Couchbase)
En dokumentbutikk er en ikke-relasjonell database som lagrer data i JSON-, BSON- eller XML-dokumenter. De har et fleksibelt skjema. I motsetning til SQL-databaser, der brukere må erklære skjemaet til en tabell før de setter inn data, håndhever ikke dokumentlagre dokumentstrukturen. Dokumenter kan inneholde alle ønskede data. De har nøkkelverdipar, men legger også inn attributtmetadata for å gjøre spørringen lettere.
Styrker
Dokumentforretninger er veldig fleksible. De håndterer semistrukturerte og ustrukturerte data godt. Brukerne trenger ikke å vite under konfigureringen hvilke typer data som skal lagres, så dette er et godt valg når det ikke er klart på forhånd hvilken type data som kommer inn.
Brukere kan opprette ønsket struktur i et bestemt dokument uten å påvirke alle dokumenter. Skjema kan endres uten å forårsake nedetid, noe som fører til høy tilgjengelighet. Skrivehastighet er generelt også rask.
I tillegg til fleksibilitet, liker utviklere dokumentbutikker fordi de er enkle å skalere horisontalt. Skjæringen som er nødvendig for horisontal skalering er mye mer intuitiv enn med relasjonsdatabaser, så dokumentbutikker skaleres raskt og effektivt ut.
Svakheter
Dokumentdatabaser ofrer ACID-samsvar for fleksibilitet. Selv om spørring kan gjøres i et dokument, er det ikke mulig på tvers av dokumenter.
Bruk en dokumentdatabase til:
- Ustrukturerte eller semistrukturerte data
- Filbehandling
- Grundig dataanalyse
- Hurtig prototyping
Nøkkelverdibutikk (Redis, Memcached)
En nøkkelverdilager er en type ikke-relasjonell database der hver verdi er knyttet til en bestemt nøkkel. Det er også kjent som et assosiativt utvalg.
"Nøkkelen" er en unik identifikator som bare er knyttet til verdien. Nøkler kan være hva som helst som tillates av DBMS. I Redis, for eksempel, er nøklene en hvilken som helst binær sekvens opp til 512 MB.
"Verdier" lagres som klatter og trenger ikke forhåndsdefinert skjema. De kan ha nesten hvilken som helst form: tall, strenger, tellere, JSON, XML, HTML, PHP, binære filer, bilder, korte videoer, lister og til og med et annet nøkkelverdipar som er innkapslet i et objekt. Noen DBMS-er tillater at datatypen spesifiseres, men det er ikke obligatorisk.
Styrker
Denne databasestilen har mange positive. Den er utrolig fleksibel, i stand til å håndtere et veldig bredt utvalg av datatyper enkelt. Taster brukes til å gå direkte til verdien uten å søke etter indeks eller bli med, så ytelsen er høy. Bærbarhet er en annen fordel: nøkkelverdibutikker kan flyttes fra ett system til et annet uten omskriving av kode. Til slutt er de svært horisontalt skalerbare og har generelt lavere driftskostnader.
Svakheter
Fleksibilitet har en pris. Det er umulig å spørre om verdier, fordi de er lagret som en blob og kan bare returneres som sådan. Dette gjør det vanskelig å rapportere eller redigere deler av verdier. Det er heller ikke alle objekter som er enkle å modellere som nøkkelverdipar.
Bruk en nøkkelverdilager for:
- Anbefalinger
- Brukerprofiler og innstillinger
- Ustrukturerte data som produktanmeldelser eller bloggkommentarer
- Øktledelse i stor skala
- Data som blir brukt ofte, men ikke ofte oppdatert
Bredkolonnebutikk (Cassandra, HBase)
Store kolonnebutikker, også kalt kolonnebutikker eller utvidbare platebutikker, er dynamiske kolonneorienterte ikke-relaterte databaser. Noen ganger blir de sett på som en type nøkkelverdibutikk, men har også attributter fra tradisjonelle relasjonsdatabaser.
Store kolonnebutikker bruker begrepet nøkkelplass i stedet for skjemaer. Et nøkkelområde omfatter kolonnefamilier (ligner på tabeller, men mer fleksible i strukturen), som hver inneholder flere rader med forskjellige kolonner. Hver rad trenger ikke å ha samme antall eller type kolonne. En tidsstempel bestemmer den nyeste versjonen av data.
Styrker
Denne typen databaser har noen fordeler med både relasjonelle og ikke-relaterte databaser. Den håndterer bedre både strukturerte og semistrukturerte data enn andre ikke-relaterte databaser, og det er lettere å oppdatere. Sammenlignet med relasjonsdatabaser er den mer horisontalt skalerbar og raskere i skala.
Søyledatabaser komprimerer bedre enn radbaserte systemer. Også store datasett er enkle å utforske. Store kolonnebutikker er for eksempel spesielt gode til aggregeringsspørsmål.
Svakheter
Skrift er dyrt i det minste. Selv om det er enkelt å gjøre oppdatering i bulk, er det vanskelig å laste opp og oppdatere individuelle poster. I tillegg er butikker med brede kolonner langsommere enn relasjonsdatabaser når de håndterer transaksjoner.
Bruk en butikk med store kolonner for:
- Big data-analyse der hastighet er viktig
- Datalagring på big data
- Storskalaprosjekter (denne databasestilen er ikke et godt verktøy for gjennomsnittlige transaksjonelle applikasjoner)
Søkemotor (Elasticsearch)
Det kan virke rart å inkludere søkemotorer i en artikkel om databasetyper. Elasticsearch har imidlertid sett økt popularitet i denne sfæren ettersom utviklere ser etter innovative måter å redusere søkeforsinkelsen. Elastisearch er en ikke-relasjonell, dokumentbasert datalagrings- og henteløsning som er spesielt arrangert og optimalisert for lagring og rask henting av data.
Styrker
Elastisearch er veldig skalerbart. Den har fleksibelt skjema og rask henting av poster, med avanserte søkealternativer, inkludert fulltekstsøk, forslag og komplekse søkeuttrykk.
En av de mest interessante søkefunksjonene stammer. Stemming analyserer rotformen til et ord for å finne relevante poster selv når en annen form brukes. For eksempel vil en bruker som søker i en sysselsettingsdatabase etter "betalende jobber" også finne stillinger merket som "betalt" og "lønn."
Svakheter
Elastisearch brukes mer som en mellomledd eller tilleggsbutikk enn en primær database. Den har lav holdbarhet og dårlig sikkerhet. Det er ingen medfødt godkjenning eller tilgangskontroll. Elastisearch støtter heller ikke transaksjoner.
Bruk en søkemotor som Elastisearch for:
- Forbedrer brukeropplevelsen med raskere søkeresultater
- Hogst
Avsluttende hensyn
Noen applikasjoner passer pent til styrkene til en bestemt databasetype, men for de fleste prosjekter er det overlapping mellom to eller flere. I slike tilfeller kan det være nyttig å se på hvilke spesifikke databaser i de stilte stilene som er gode kandidater. Leverandører tilbyr et bredt spekter av funksjoner for å skreddersy databasen til individuelle standarder. Noen av disse kan bidra til å løse usikkerhet om faktorer som sikkerhet, skalerbarhet og kostnad.
