Hvilken DB skal du vælge til din specifikke datatype i dit softwareprojekt?

Typen af din database er ikke det eneste, du skal overveje. Der er mange andre ting at tænke på, f.eks. hvor mange aktive brugere applikationen kan have? Har du brug for stærk konsistens overalt? Vil den eventuelle konsistens være tilstrækkelig i nogle tilfælde? Der er så mange spørgsmål uden entydige svar, for "jo mere man sætter sig ind i det, jo mere kompliceret bliver det". Så vær opmærksom på, at denne artikel kun fokuserer på databasetyper.

Tag en kop kaffe og nyd denne læsning.

Generel databaseklassifikation

Til at begynde med er det godt at vide, at der er to hovedtyper af databaser: relationelle (SQL) og ikke-relationelle (NoSQL).

• SQL-databaser er struktureret på en relationel måde, hvilket betyder, at man gemmer data i tabeller og opretholder relationer mellem dem.
• NoSQL-databaserne (ikke kun SQL) er i modsætning til de relationelle databaser ikke velstrukturerede og giver derfor mulighed for større tilpasningsevne og fleksibilitet.

Der findes endnu en type ud over de to ovennævnte, nemlig en in-memory-database. Den kan ikke klassificeres som hverken relationel eller ikke-relationel, fordi det handler om, hvor dataene fysisk er gemt. Alle databaser kan gemmes på en disk eller i hukommelsen.

Typer af databaser

1. Relationel

Efter min mening er det den mest populære type database. Den fungerer godt med strukturelle data, hvor man ønsker at bevare relationerne mellem posterne. Databasestrukturen er beskrevet i et skema.

De største fordele vedrører transaktioner (de hjælper med at sikre dataintegritet og følger ACID-reglerne) og evnen til at håndtere mange komplekse forespørgsler.

Hvornår skal man vælge det?

Det er nyttigt til at opbevare data, der ikke ændrer sig strukturelt særlig ofte, og som du f.eks. har brug for at gemme permanent:

• CRM (Customer Relationship Management),
• Styring af ordrer,
• ERP (Virksomhed Ressourceplanlægning),
• data warehousing eller lagerstyring,
• regnskab eller økonomi.

Eksempler:

Amazon Aurora, Microsoft Azure SQL-database, PostgreSQL, MySQL.

Relationsdatabaser er utilstrækkelige til mange nye applikationer, og man er nødt til at have mere end én database. I næste del af artiklen vil jeg fokusere på de ikke-relationelle databaser.

2. Nøgle-værdi

Den gemmer hver dataværdi med en unik nøgle. Det betyder, at data tilgås med en enkelt nøgle, ligesom det gøres i et hashkort. I modsætning til relationsdatabaser håndhæver den hverken skemaet eller relationerne mellem poster. De fleste af disse databaser understøtter normalt ikke opdateringsoperationer. Hvis man vil ændre data, skal man overskrive hele det eksisterende sæt.

Hvornår skal man vælge det?

Det er nyttigt til data, som du vil læse/skrive hurtigt (men ikke opdatere særlig ofte):

• budgivning i realtid, annoncevisning,
• caching af data,
• sessionsstyring,
• indkøbskurve,
• kundepræferencer eller profilstyring.

Eksempler:

Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.

3. Dokument

Den gemmer samlinger af dokumenter. Hvert dokument indeholder felter med data, som kan være simple værdier eller komplekse elementer som lister eller underordnede samlinger. Det er vigtigt at vide, at hvert dokument kan have en forskellig struktur, selv om de repræsenterer det samme (hvert dokument er unikt og udvikler sig over tid). For eksempel indeholder det første kundedokument mindre information end det andet:

{
 "Fornavn": "John",
 "Efternavn": "Fake",
 "Motorcykler:" [
  {
    "Model": "BMW",
    "Year": 2020
  }
 ]
}

{
 "Fornavn": "Alex",
 "Efternavn": "Nolastname",
 "Alder": 15,
 "Adresse": {
    "Land": "Polen",
    "By": "Et eller andet sted"
  },
 "Motorcykler:" [
  {
    "Model": "BMW",
    "Year": 2020
  }
 ]
}

Hvornår skal man vælge det?

Det er nyttigt til data, der kræver et fleksibelt skema til hurtig behandling:

• produkt kataloger,
• CMS (content management system),
• brugerprofiler og personalisering.

Eksempler:

Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.

4. Graf

Den bruger en grafstruktur og er opbygget af to elementer: noder og kanter. Noder svarer til tabelrækker eller JSON-dokumenter. Kanter er relationer mellem noderne - de er lige så vigtige som noderne. Begge kan have egenskaber. Desuden kan kanter have en defineret retning for et forhold.

Hvornår skal man vælge det?

Det er nyttigt, når dine data ligner en graf, dvs. at relationerne mellem dataelementer er dynamiske og ændrer sig over tid. Desuden er det et godt valg, når en forretningsmæssig eller teknisk hold har brug for at forstå sammenhænge i deres data. Nogle fremtrædende eksempler omfatter:

• organisationsdiagrammer,
• opdagelse af svindel,
• sociale grafer/netværk,
• anbefalinger motorer,
• vidensgrafer.

Eksempler:

Amazon Neptune, Neo4j, ArangoDB, Titan.

5. Tidsserier

Den gemmer data organiseret efter tid. Typisk akkumulerer den enorme mængder data i realtid. Det bruges oftest til at gemme data, selvom opdatering er meget sjælden. Generelt bruges et tidsstempel som primær nøgle og/eller til at sortere data. Nogle databaser giver mulighed for at inkludere definerende tags som yderligere information, f.eks. dataoprindelse eller -type.

Hvornår skal man vælge det?

Det er nyttigt at gemme små mængder data i kronologisk rækkefølge, f.eks. i:

• DevOps,
• overvågning af applikationer,
• overvågning og telemetri af hændelser,
• IoT applikationer (som dataindsamling fra enhedens sensorer).

Eksempler:

Azure Time Series Insights, Amazon Timestream, InfluxDB.

6. Hovedbog

Det er en uforanderlig, transparent og kryptografisk verificerbar transaktionslog, der ejes af en central myndighed. - Oversigt over Amazons QLDB

Lad os kort forklare hvert enkelt nøgleord i ovenstående citat:

• uforanderlig - betyder, at en post, der er oprettet i denne database, ikke kan slettes, ændres eller endda overskrives,
• gennemsigtig - den sporer og opbevarer en sekvensregistrering af hver ændring i dine data,
• kryptografisk verificerbar - data, der oprettes i denne database, verificeres ved hjælp af kryptografiske hash-teknikker i lighed med blockchains (ved hjælp af SHA-256-hash-funktionen).

Hvornår skal man vælge det?

Det er nyttigt at gemme nøjagtig historik, f.eks. ved at logge sekventiel indtastning af hver dataændring, som i:

• økonomi (historik over debet- eller kredittransaktioner),
• fremstilling (track where parts were sourced),
• forsikring,
• HR og løn,
• detailhandel,
• forsyningskæder.

Eksempler:

Amazon QLDB

Konklusioner

Der er ikke noget enkelt svar på det spørgsmål, der stilles i titlen på denne artikel. Den eneste måde at vælge den rigtige database på er ved at lære mere om dine data. Svar på spørgsmålet: "Hvilken slags data genererer din applikation?", og så kan du træffe de rigtige valg.

Desuden skal du kende forretningskravene og applikationsdomænet meget godt. Du skal vide, hvordan du vil bruge dataene, hvilke forespørgsler du vil sende til databasen, og hvor mange gange du vil opbevare, læse, opdatere eller slette dine data. Alle disse ting er vigtige, men ikke alle udviklere er tilstrækkeligt opmærksomme på disse områder.

Tænk på dine data i den applikation, du udvikler, for at forbedre/skabe bedre software. Alt i alt håber jeg, at du vil lære dine data at kende godt nok til at opbevare dem et sted, hvor de bliver glade.

Læs mere om det:

Et par tricks til at gøre din JavaScript-applikation hurtigere

Måder at øge din Rails-performance på

Fakta og myter om at samarbejde med en ekstern softwareudviklingspartner