Welke DB kiezen voor je specifieke gegevenstype in je softwareproject

Het type database is niet het enige onderwerp om rekening mee te houden. Er zijn veel andere zaken om over na te denken, bijvoorbeeld hoeveel actieve gebruikers de applicatie kan hebben? Heb je overal sterke consistentie nodig? Zal de uiteindelijke consistentie in sommige gevallen voldoende zijn? Er zijn zoveel vragen zonder eenduidig antwoord, want "hoe meer je je erin verdiept, hoe ingewikkelder het wordt". Houd er dus rekening mee dat dit artikel alleen gericht is op databasetypen.

Neem een kop koffie en geniet van deze lezing.

Algemene databaseclassificatie

Om te beginnen is het goed om te weten dat er twee hoofdtypen databases zijn: relationele (SQL) en niet-rationele (NoSQL).

• De SQL-databases zijn relationeel gestructureerd, wat betekent dat je gegevens opslaat in tabellen en daar relaties tussen onderhoudt.
• De NoSQL (Not only SQL) databases zijn, in tegenstelling tot de relationele, niet goed gestructureerd en bieden dus meer aanpassingsvermogen en flexibiliteit.

Er is nog een ander type dan de twee hierboven genoemde, namelijk een in-memory database. Deze kan niet worden geclassificeerd als relationeel of niet-rationeel omdat het te maken heeft met waar de gegevens fysiek worden opgeslagen. Elke database kan worden opgeslagen op een schijf of in het geheugen.

Soorten databases

1. Relationeel

Naar mijn mening is dit het populairste type database. Het werkt goed met structurele gegevens waarbij je relaties tussen de records wilt bijhouden. De databasestructuur wordt beschreven in een schema.

De belangrijkste voordelen hebben betrekking op transacties (ze helpen om gegevensintegriteit te garanderen en volgen de ACID regels) en de mogelijkheid om veel complexe queries te verwerken.

Wanneer kiezen?

Het is handig voor het bewaren van gegevens die structureel niet vaak veranderen en die je bijvoorbeeld permanent moet bewaren:

• CRM (Customer Relationship Management),
• Orderbeheer,
• ERP (Onderneming Resource Planning),
• gegevensopslag of voorraadbeheer,
• boekhouding of financiën.

Voorbeelden:

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

Relationele databases zijn voor veel nieuwe toepassingen ontoereikend en je hebt meer dan één database nodig. In het volgende deel van het artikel zal ik me richten op de niet-relationele databases.

2. Key-value

Het slaat elke gegevenswaarde op met een unieke sleutel. Dit betekent dat gegevens toegankelijk zijn via een enkele sleutel, net zoals dat gebeurt in een hash map. In tegenstelling tot relationele databases wordt er geen schema of relaties tussen records afgedwongen. De meeste van deze databases ondersteunen gewoonlijk geen update operaties. Om gegevens te wijzigen, moet je de hele bestaande set overschrijven.

Wanneer kiezen?

Het is handig voor gegevens die je snel wilt lezen/schrijven (maar niet vaak wilt bijwerken):

• real-time bieden, ad serving,
• gegevenscaching,
• sessiebeheer,
• winkelwagentjes,
• klantenvoorkeuren of profielbeheer.

Voorbeelden:

Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.

3. Document

Het slaat verzamelingen van documenten op. Elk document bevat velden met gegevens, die eenvoudige waarden of complexe elementen kunnen zijn, zoals lijsten of kindverzamelingen. Het is belangrijk om te weten dat elk document een andere structuur kan hebben, zelfs als ze hetzelfde voorstellen (elk document is uniek en evolueert in de tijd). Het eerste klantendocument bevat bijvoorbeeld minder informatie dan het tweede:

{
 "Voornaam": "John",
 "LastName": "Fake",
 "Motoren": [
  {
    "Model": "BMW",
    "Jaar": 2020
  }
 ]
}

{
 "Voornaam": "Alex",
 {"LastName": "Nolastname",
 "Leeftijd: 15,
 "Address": {
    "Land": "Polen",
    "Stad": "Somewhere"
  },
 "Motoren": [
  {
    "Model": "BMW",
    "Jaar": 2020
  }
 ]
}

Wanneer kiezen?

Het is handig voor gegevens die een flexibel schema nodig hebben voor snelle verwerking:

• product catalogi,
• CMS (content management systeem),
• gebruikersprofielen en personalisatie.

Voorbeelden:

Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.

4. Grafiek

Het maakt gebruik van een grafiekstructuur en is opgebouwd uit twee elementen: knooppunten en randen. Knooppunten zijn analoog aan tabelrijen of JSON-documenten. Edges zijn relaties tussen de nodes - ze zijn even belangrijk als nodes. Beide kunnen eigenschappen hebben. Bovendien kunnen edges een bepaalde richting van een relatie hebben.

Wanneer kiezen?

Het is nuttig wanneer je gegevens lijken op een grafiek, d.w.z. relaties tussen gegevensitems zijn dynamisch en veranderen in de loop van de tijd. Bovendien is het een goede keuze wanneer een zakelijke of technische team relaties binnen hun gegevens moeten begrijpen. Enkele prominente voorbeelden zijn:

• organisatieschema's,
• fraudedetectie,
• sociale grafieken/netwerken,
• aanbevelingen motoren,
• kennisgrafieken.

Voorbeelden:

Amazon Neptune, Neo4j, ArangoDB, Titan.

5. Tijdreeksen

Het slaat gegevens georganiseerd per tijd op. Typisch verzamelt het enorme hoeveelheden gegevens in realtime. Het wordt meestal gebruikt om gegevens op te slaan, hoewel updaten zeer zeldzaam is. Over het algemeen wordt een tijdstempel gebruikt als primaire sleutel en/of om gegevens te sorteren. In sommige databases kunnen tags worden gedefinieerd als aanvullende informatie, zoals de herkomst of het type van de gegevens.

Wanneer kiezen?

Het is handig om kleine hoeveelheden gegevens op chronologische volgorde op te slaan, bijvoorbeeld in:

• DevOps,
• applicatiebewaking,
• bewaking en gebeurtenistelemetrie,
• IoT toepassingen (zoals gegevensverzamelingen van apparaatsensoren).

Voorbeelden:

Azure Time Series Insights, Amazon Timestream, InfluxDB.

6. Grootboek

Het biedt een onveranderlijk, transparant en cryptografisch verifieerbaar transactielogboek dat eigendom is van een centrale autoriteit. - Overzicht QLDB van Amazon

Laten we kort elk sleutelwoord in het bovenstaande citaat uitleggen:

• onveranderlijk - betekent dat een record die in deze database is aangemaakt niet kan worden verwijderd, gewijzigd of zelfs overschreven,
• transparant - het volgt en houdt een sequentie bij van elke verandering in je gegevens,
• cryptografisch verifieerbaar - gegevens in deze database worden geverifieerd met cryptografische hashingtechnieken, vergelijkbaar met blockchains (met de SHA-256 hashingfunctie).

Wanneer kiezen?

Het is nuttig om een nauwkeurige geschiedenis op te slaan, bijv. door het loggen van opeenvolgende invoer van elke gegevenswijziging, zoals in:

• financiën (geschiedenis van debet- of credittransacties),
• productie (bijhouden waar onderdelen vandaan komen),
• verzekering,
• HR en salarisadministratie,
• detailhandel,
• toeleveringsketens.

Voorbeelden:

Amazon QLDB

Conclusies

Er is geen eenvoudig antwoord op de vraag die in de titel van dit artikel wordt gesteld. De enige manier om de juiste database te kiezen is door meer te weten te komen over je gegevens. Beantwoord de vraag: "Wat voor soort gegevens genereert uw toepassing?", en u zult de juiste keuzes kunnen maken.

Verder moet je de bedrijfsvereisten en het toepassingsdomein heel goed kennen. Je moet weten hoe je de gegevens gaat gebruiken, welke queries je naar de database gaat sturen, hoe vaak je gegevens gaat bewaren, lezen, bijwerken of verwijderen. Al deze dingen zijn belangrijk, maar niet alle ontwikkelaars besteden voldoende aandacht aan deze gebieden.

Denk alsjeblieft na over je gegevens in de applicatie die je ontwikkelt om betere software te maken/verbeteren. Over het algemeen hoop ik dat je je gegevens goed genoeg leert kennen om ze op te slaan op een plek waar ze gelukkig zullen zijn.

Lees meer:

Een paar trucjes om je JavaScript-toepassing te versnellen

Manieren om je Rails prestaties te verhogen

Feiten en fabels over samenwerken met externe partner voor softwareontwikkeling