Vilken DB ska du välja för din specifika datatyp i ditt programvaruprojekt?

Typen av databas är inte det enda man bör tänka på. Det finns många andra frågor att fundera över, t.ex. hur många aktiva användare applikationen kan ha? Behöver du stark konsistens överallt? Räcker det med en viss konsistens i vissa fall? Det finns så många frågor utan enkla svar, eftersom "ju mer man sätter sig in i det, desto mer komplicerat blir det". Så notera att den här artikeln endast är inriktad på databastyper.

Ta en kopp kaffe och njut av den här läsningen.

Allmän klassificering av databaser

I början är det bra att veta att det finns två huvudtyper av databaser: relationella (SQL) och icke-relationella (NoSQL).

• SQL-databaserna är uppbyggda på ett relationellt sätt, vilket innebär att du lagrar data i tabeller och upprätthåller relationer mellan dem.
• NoSQL-databaserna (Not only SQL), till skillnad från relationsdatabaserna, är inte välstrukturerade och tillåter därmed mer anpassningsförmåga och flexibilitet.

Det finns ytterligare en typ förutom de två som nämns ovan, nämligen en databas med minneslagring (in-memory database). Den kan inte klassificeras som vare sig relationell eller icke-relationell eftersom det handlar om var data lagras fysiskt. Alla databaser kan lagras på en disk eller i minnet.

Olika typer av databaser

1. Relationell

Enligt min mening är det den mest populära typen av databas. Den fungerar bra med strukturella data där man vill behålla relationerna mellan posterna. Databasstrukturen beskrivs i ett schema.

De främsta fördelarna gäller transaktioner (de bidrar till att säkerställa dataintegritet och följer ACID-reglerna) och förmågan att hantera många komplexa frågor.

När ska man välja det?

Det är användbart för att lagra data som inte ändras strukturellt särskilt ofta och som du behöver lagra permanent, till exempel:

• CRM (Customer Relationship Management, hantering av kundrelationer),
• Orderhantering,
• ERP (Företag Resursplanering),
• datalagring eller lagerhantering,
• redovisning eller finans.

Exempel på detta:

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

Relationsdatabaser är otillräckliga för många nya applikationer och du behöver ha mer än en databas. I nästa del av artikeln kommer jag att fokusera på de icke-relationella databaserna.

2. Nyckel-värde

Den lagrar varje datavärde med en unik nyckel. Det innebär att data kan nås med en enda nyckel, precis som i en hashkarta. I motsats till relationsdatabaser upprätthåller den varken schemat eller relationerna mellan posterna. De flesta av dessa databaser stöder normalt inte uppdateringsoperationer. Om man vill ändra data måste man skriva över hela den befintliga uppsättningen.

När ska man välja det?

Det är användbart för data som du vill läsa/skriva snabbt (men som inte uppdateras särskilt ofta):

• realtidsbudgivning, annonsering,
• cachelagring av data,
• sessionshantering,
• kundvagnar,
• kundpreferenser eller profilhantering.

Exempel på detta:

Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.

3. Dokument

Den lagrar samlingar av dokument. Varje dokument innehåller fält med data, som kan vara enkla värden eller komplexa element, som listor eller barnsamlingar. Det är viktigt att veta att varje dokument kan ha olika struktur, även om de representerar samma sak (varje dokument är unikt och utvecklas över tid). Det första kunddokumentet innehåller t.ex. mindre information än det andra:

{
 "Förnamn": "John",
 "Efternamn": "Fake",
 "Motorcyklar:" [
  {
    "Modell": "BMW",
    "År": 2020
  }
 ]
}

{
 "Förnamn": "Alex",
 "Efternamn": "Nolastnamn",
 "Ålder": 15,
 "Adress": {
    "Land": "Polen",
    "Stad": "Någonstans"
  },
 "Motorcyklar:" [
  {
    "Modell": "BMW",
    "År": 2020
  }
 ]
}

När ska man välja det?

Det är användbart för data som kräver ett flexibelt schema för snabb bearbetning:

• Produkt kataloger,
• CMS (system för innehållshantering),
• användarprofiler och personalisering.

Exempel på detta:

Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.

4. Graf

Den använder en grafstruktur och är uppbyggd av två element: noder och kanter. Noder motsvarar rader i tabeller eller JSON-dokument. Kanterna är relationer mellan noderna - de är lika viktiga som noderna. Båda kan ha egenskaper. Dessutom kan kanter ha en definierad riktning för en relation.

När ska man välja det?

Det är användbart när dina data liknar ett diagram, dvs. när relationerna mellan dataobjekt är dynamiska och förändras över tid. Dessutom är det ett bra val när en affärsmässig eller teknisk Team behöver förstå relationer inom sina data. Några framträdande exempel inkluderar:

• organisationsscheman,
• Upptäckt av bedrägerier,
• sociala grafer/nätverk,
• rekommendationer motorer,
• kunskapsgrafer.

Exempel på detta:

Amazon Neptune, Neo4j, ArangoDB, Titan.

5. Tidsserier

Den lagrar data som är organiserade efter tid. Vanligtvis ackumuleras enorma mängder data i realtid. Den används oftast för att spara data, även om uppdatering är mycket sällsynt. I allmänhet används en tidsstämpel som primär nyckel och/eller för sortering av data. Vissa databaser tillåter att definierande taggar inkluderas som ytterligare information, t.ex. dataursprung eller datatyp.

När ska man välja det?

Det är användbart att lagra små mängder data som bifogas sekventiellt i kronologisk ordning, t.ex. i:

• DevOps,
• övervakning av applikationer,
• övervakning och händelsetelemetri,
• IoT tillämpningar (t.ex. insamling av data från sensorer).

Exempel på detta:

Azure Time Series Insights, Amazon Timestream, InfluxDB.

6. Huvudbok

Den tillhandahåller en oföränderlig, transparent och kryptografiskt verifierbar transaktionslogg som ägs av en central myndighet. - Amazons QLDB-översikt

Låt oss kortfattat förklara varje nyckelord i ovanstående citat:

• oföränderlig - innebär att en post som skapats i den här databasen inte kan raderas, ändras eller ens skrivas över,
• transparent - det spårar och håller en sekvensregistrering av varje förändring i dina data,
• kryptografiskt verifierbar - data som skapas i denna databas verifieras med kryptografiska hashtekniker, liknande blockkedjor (med hjälp av hashfunktionen SHA-256).

När ska man välja det?

Det är användbart att lagra korrekt historik, t.ex. genom att logga sekventiell inmatning av varje dataändring, som i:

• ekonomi (historik över debet- eller kredittransaktioner),
• tillverkning (spår där delar anskaffades),
• försäkring,
• HR och löner,
• detaljhandel,
• leveranskedjor.

Exempel på detta:

Amazon QLDB

Slutsatser

Det finns inget enkelt svar på den fråga som ställs i rubriken till den här artikeln. Det enda sättet att välja rätt databas är att lära sig mer om dina data. Svara på frågan: "Vilken typ av data genererar din applikation?", så kommer du att kunna göra rätt val.

Dessutom bör du känna till affärskraven och applikationsdomänen mycket väl. Du måste veta hur du kommer att använda data, vilka frågor du kommer att skicka till databasen, hur många gånger du kommer att behålla, läsa, uppdatera eller radera dina data. Alla dessa saker spelar roll, men inte alla utvecklare ägnar tillräcklig uppmärksamhet åt dessa områden.

Tänk på dina data i den applikation du utvecklar för att förbättra/skapa bättre programvara. Sammantaget hoppas jag att du kommer att lära känna dina data tillräckligt väl för att lagra dem på en plats där de kommer att trivas.

Läs mer om detta:

Några knep för att påskynda din JavaScript-ansökan

Sätt att öka din Rails-prestanda

Fakta och myter om att samarbeta med en extern partner för mjukvaruutveckling