Hvilken DB skal du velge for den spesifikke datatypen i programvareprosjektet ditt?

Databasetypen er ikke det eneste du må ta hensyn til. Det er mange andre ting å tenke på, f.eks. hvor mange aktive brukere applikasjonen har? Trenger du sterk konsistens overalt? Er det tilstrekkelig med eventuell konsistens i noen tilfeller? Det er så mange spørsmål uten enkle svar, for "jo mer du setter deg inn i det, jo mer komplisert blir det". Så vær oppmerksom på at denne artikkelen kun fokuserer på databasetyper.

Ta en kopp kaffe og nyt denne lesningen.

Generell databaseklassifisering

Innledningsvis er det greit å vite at det finnes to hovedtyper av databaser: relasjonelle (SQL) og ikke-relasjonelle (NoSQL).

• SQL-databasene er strukturert på en relasjonell måte, noe som betyr at du lagrer data i tabeller og opprettholder relasjoner mellom dem.
• NoSQL-databasene (ikke bare SQL) er, i motsetning til relasjonsdatabasene, ikke velstrukturerte og gir dermed større tilpasningsevne og fleksibilitet.

Det finnes en annen type enn de to som er nevnt ovenfor, nemlig en in-memory-database. Den kan ikke klassifiseres som verken relasjonell eller ikke-relasjonell, fordi den er knyttet til hvor dataene fysisk er lagret. Alle databaser kan være lagret på en disk eller i minnet.

Typer databaser

1. Relasjonelle

Etter min mening er det den mest populære databasetypen. Den fungerer godt med strukturelle data der du ønsker å bevare relasjoner mellom postene. Databasestrukturen beskrives i et skjema.

De viktigste fordelene er transaksjoner (de bidrar til å sikre dataintegritet og følger ACID-reglene) og muligheten til å håndtere mange komplekse spørringer.

Når skal man velge det?

Det er nyttig for å lagre data som ikke endres strukturelt så ofte, og som du for eksempel trenger å lagre permanent:

• CRM (Customer Relationship Management),
• Ordrehåndtering,
• ERP (Enterprise Ressursplanlegging),
• datalagring eller lagerstyring,
• regnskap eller finans.

Eksempler:

Amazon Aurora, Microsoft Azure SQL Database, PostgreSQL, MySQL.

Relasjonsdatabaser er utilstrekkelige for mange nye applikasjoner, og du må ha mer enn én database. I neste del av artikkelen vil jeg fokusere på ikke-relasjonelle databaser.

2. Nøkkelverdi

Den lagrer hver dataverdi med en unik nøkkel. Det betyr at data er tilgjengelige via en enkelt nøkkel, akkurat som i et hash-kart. I motsetning til relasjonsdatabaser håndhever den verken ordningen eller relasjonene mellom poster. De fleste av disse databasene støtter vanligvis ikke oppdateringsoperasjoner. Hvis du vil endre data, må du overskrive hele det eksisterende settet.

Når skal man velge det?

Det er nyttig for data som du ønsker å lese/skrive raskt (men som ikke oppdateres så ofte):

• sanntidsbudgivning, annonsevisning,
• caching av data,
• øktadministrasjon,
• handlekurver,
• kundepreferanser eller profilstyring.

Eksempler:

Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.

3. Dokument

Den lagrer samlinger av dokumenter. Hvert dokument inneholder felt med data, som kan være enkle verdier eller komplekse elementer, som lister eller underordnede samlinger. Det er viktig å være klar over at hvert dokument kan ha ulik struktur, selv om de representerer det samme (hvert dokument er unikt og utvikler seg over tid). Det første kundedokumentet inneholder for eksempel mindre informasjon enn det andre:

{
 "FirstName": "John",
 "Etternavn": "Fake",
 "Motorsykler:" [
  {
    "Model": "BMW",
    "Year": 2020
  }
 ]
}

{
 "FirstName": "Alex",
 "Etternavn": "Etternavn",
 "Alder": 15,
 "Adresse": {
    "Land": "Polen",
    "By": "Et sted"
  },
 "Motorsykler:" [
  {
    "Model": "BMW",
    "Year": 2020
  }
 ]
}

Når skal man velge det?

Det er nyttig for data som krever et fleksibelt skjema for rask behandling:

• produkt kataloger,
• CMS (innholdsstyringssystem),
• brukerprofiler og personalisering.

Eksempler:

Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.

4. Graf

Den bruker en grafstruktur og er bygget opp av to elementer: noder og kanter. Noder kan sammenlignes med tabellrader eller JSON-dokumenter. Kanter er relasjoner mellom nodene - de er like viktige som nodene. Begge kan ha egenskaper. Dessuten kan kanter ha en definert retning for en relasjon.

Når skal man velge det?

Det er nyttig når dataene dine ligner på en graf, det vil si at relasjonene mellom dataelementene er dynamiske og endrer seg over tid. Videre er det et godt valg når en forretnings- eller teknisk team trenger å forstå sammenhenger i dataene sine. Noen fremtredende eksempler inkluderer:

• organisasjonskart,
• oppdagelse av svindel,
• sosiale grafer/nettverk,
• anbefalinger motorer,
• kunnskapsgrafer.

Eksempler:

Amazon Neptune, Neo4j, ArangoDB, Titan.

5. Tidsserier

Den lagrer data organisert etter tid. Vanligvis akkumuleres enorme mengder data i sanntid. Den brukes oftest til å lagre data, selv om oppdatering er svært sjelden. Vanligvis brukes et tidsstempel som primærnøkkel og/eller til sortering av data. Noen databaser tillater at man legger til definerende tagger som tilleggsinformasjon, for eksempel dataopprinnelse eller -type.

Når skal man velge det?

Det er nyttig å lagre små datamengder i kronologisk rekkefølge, for eksempel i:

• DevOps,
• applikasjonsovervåking,
• overvåking og telemetri av hendelser,
• IoT applikasjoner (som datainnsamlinger fra sensorer).

Eksempler:

Azure Time Series Insights, Amazon Timestream, InfluxDB.

6. Hovedbok

Den tilbyr en uforanderlig, transparent og kryptografisk verifiserbar transaksjonslogg som eies av en sentral autoritet. - Oversikt over Amazons QLDB

La oss kort forklare hvert nøkkelord i sitatet ovenfor:

• uforanderlig - betyr at en post som er opprettet i denne databasen, ikke kan slettes, endres eller overskrives,
• gjennomsiktig - den sporer og lagrer en sekvensregistrering av hver endring i dataene dine,
• kryptografisk verifiserbar - data som opprettes i denne databasen, verifiseres ved hjelp av kryptografiske hash-teknikker, på samme måte som blokkjeder (ved hjelp av hash-funksjonen SHA-256).

Når skal man velge det?

Det er nyttig å lagre nøyaktig historikk, f.eks. ved å logge sekvensiell registrering av hver dataendring, som i:

• økonomi (historikk over debet- eller kredittransaksjoner),
• produksjon (spore hvor delene ble hentet fra),
• forsikring,
• HR og lønn,
• detaljhandel,
• forsyningskjeder.

Eksempler:

Amazon QLDB

Konklusjoner

Det finnes ikke noe enkelt svar på spørsmålet i tittelen på denne artikkelen. Den eneste måten å velge riktig database på, er å lære mer om dataene dine. Svar på spørsmålet: "Hva slags data genererer applikasjonen din?", og du vil være i stand til å ta de riktige valgene.

I tillegg bør du kjenne forretningskravene og applikasjonsdomenet svært godt. Du må vite hvordan du skal bruke dataene, hvilke spørringer du skal sende til databasen, hvor mange ganger du skal oppbevare, lese, oppdatere eller slette dataene. Alle disse tingene er viktige, men ikke alle utviklere er oppmerksomme nok på disse områdene.

Tenk på dataene dine i applikasjonen du utvikler for å forbedre/skape bedre programvare. Alt i alt håper jeg at du blir godt nok kjent med dataene dine til å lagre dem på et sted der de vil trives.

Les mer om dette:

Noen triks for å få fart på JavaScript-applikasjonen

Måter å øke Rails-ytelsen på

Fakta og myter om samarbeid med en ekstern programvareutviklingspartner