Quale DB scegliere per un tipo di dati specifico nel vostro progetto software?

Il tipo di database non è l'unico argomento da considerare. Ci sono molti altri aspetti da considerare, ad esempio: quanti utenti attivi può avere l'applicazione? Avete bisogno di una forte coerenza ovunque? La consistenza eventuale sarà sufficiente in alcuni casi? Ci sono così tante domande che non hanno una risposta diretta, perché "più ci si addentra nella questione, più diventa complicata". Per questo motivo, vi ricordiamo che questo articolo si concentra solo sui tipi di database.

Prendete una tazza di caffè e godetevi questa lettura.

Classificazione generale del database

All'inizio è bene sapere che esistono due tipi principali di database: relazionali (SQL) e non relazionali (NoSQL).

• I database SQL sono strutturati in maniera relazionale, il che significa che si memorizza dati in tabelle e mantenere le relazioni tra di esse.
• I database NoSQL (Not only SQL), a differenza di quelli relazionali, non sono ben strutturati e, quindi, consentono una maggiore adattabilità e flessibilità.

Esiste un altro tipo di database, oltre ai due già citati: il database in-memory. Non può essere classificato né come relazionale né come non relazionale perché si riferisce al luogo in cui i dati sono fisicamente memorizzati. Ogni database può essere memorizzato su disco o in memoria.

Tipi di database

1. Relazionale

A mio parere, è il tipo di database più diffuso. Funziona bene con dati strutturali in cui si desidera mantenere relazioni tra i record. La struttura del database è descritta in uno schema.

I principali vantaggi riguardano le transazioni (aiutano a garantire l'integrità dei dati e a seguire le regole ACID) e la capacità di gestire molte query complesse.

Quando sceglierlo?

È utile per conservare i dati che non cambiano strutturalmente molto spesso e che devono essere memorizzati in modo permanente, ad esempio:

• CRM (Customer Relationship Management),
• Gestione degli ordini,
• ERP (Impresa Pianificazione delle risorse),
• data warehousing o gestione dell'inventario,
• contabilità o finanza.

Esempi:

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

I database relazionali sono insufficienti per molte nuove applicazioni ed è necessario avere più di un database. Nella prossima parte dell'articolo, mi concentrerò sui database non relazionali.

2. Valore-chiave

Memorizza ogni valore di dati con una chiave unica. Significa che si accede ai dati tramite una singola chiave, proprio come si fa in un file hash mappa. A differenza dei database relazionali, non applica lo schema né le relazioni tra i record. La maggior parte di questi database non supporta normalmente le operazioni di aggiornamento. Per modificare i dati, è necessario sovrascrivere l'intero insieme esistente.

Quando sceglierlo?

È utile per i dati che si desidera leggere/scrivere velocemente (ma che non vengono aggiornati molto spesso):

• offerte in tempo reale, ad serving,
• caching dei dati,
• gestione delle sessioni,
• carrelli della spesa,
• preferenze dei clienti o gestione dei profili.

Esempi:

Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.

3. Documento

Memorizza collezioni di documenti. Ogni documento contiene campi con dati, che possono essere semplici valori o elementi complessi, come elenchi o collezioni di figli. È importante sapere che ogni documento può avere una struttura diversa, anche se rappresenta la stessa cosa (ogni documento è unico e si evolve nel tempo). Ad esempio, il primo documento del cliente contiene meno informazioni del secondo:

{
 "Nome": "John",
 "Cognome": "Fake",
 "Moto:" [
  {
    "Modello": "BMW",
    "Anno": 2020
  }
 ]
}

{
 "Nome": "Alex",
 "Cognome": "Nolastname",
 "Età": 15,
 "Indirizzo": {
    "Paese": "Polonia",
    "Città": "Somewhere"
  },
 "Moto:" [
  {
    "Modello": "BMW",
    "Anno": 2020
  }
 ]
}

Quando sceglierlo?

È utile per i dati che richiedono uno schema flessibile per un'elaborazione rapida:

• prodotto cataloghi,
• CMS (sistema di gestione dei contenuti),
• profili utente e personalizzazione.

Esempi:

Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.

4. Grafico

Utilizza una struttura a grafo ed è costituita da due elementi: nodi e bordi. I nodi sono analoghi alle righe delle tabelle o ai documenti JSON. Gli edge sono relazioni tra i nodi e sono importanti quanto i nodi. Entrambi possono avere proprietà. Inoltre, i bordi possono avere una direzione definita di una relazione.

Quando sceglierlo?

È utile quando i dati sono simili a un grafico, cioè le relazioni tra i dati sono dinamiche e cambiano nel tempo. Inoltre, è una buona scelta quando un'azienda o un tecnico squadra necessità di comprendere le relazioni all'interno dei propri dati. Alcuni esempi importanti sono:

• organigrammi,
• rilevamento delle frodi,
• grafici sociali/networking,
• motori di raccomandazione,
• grafi di conoscenza.

Esempi:

Amazon Neptune, Neo4j, ArangoDB, Titan.

5. Serie temporali

Memorizza i dati organizzati per tempo. In genere, accumula enormi quantità di dati in tempo reale. Viene utilizzato soprattutto per salvare i dati, anche se l'aggiornamento è molto raro. In genere, un timestamp viene utilizzato come chiave primaria e/o per ordinare i dati. Alcuni database consentono di includere tag di definizione come informazioni aggiuntive, come l'origine o il tipo di dati.

Quando sceglierlo?

È utile memorizzare piccole quantità di dati allegati in sequenza in ordine cronologico, ad esempio in:

• DevOps,
• monitoraggio delle applicazioni,
• monitoraggio e telemetria degli eventi,
• IoT applicazioni (come la raccolta di dati dai sensori del dispositivo).

Esempi:

Azure Time Series Insights, Amazon Timestream, InfluxDB.

6. Libro mastro

Fornisce un registro delle transazioni immutabile, trasparente e crittograficamente verificabile, di proprietà di un'autorità centrale. - Panoramica di QLDB di Amazon

Spieghiamo brevemente ogni parola chiave della citazione precedente:

• immutabile - significa che un record creato in questo database non può essere cancellato, modificato o sovrascritto,
• trasparente: tiene traccia e registra in sequenza ogni modifica dei dati,
• verificabile crittograficamente - i dati creati in questo database sono verificati con tecniche di hashing crittografico, simili a quelle delle blockchain (utilizzando la funzione hash SHA-256).

Quando sceglierlo?

È utile memorizzare una cronologia accurata, ad esempio registrando l'inserimento in sequenza di ogni modifica dei dati, come nel caso di:

• finanze (storico delle transazioni di debito o credito),
• produzione (tracciare la provenienza dei componenti),
• assicurazione,
• Risorse umane e buste paga,
• vendita al dettaglio,
• catene di approvvigionamento.

Esempi:

Amazon QLDB

Conclusioni

Non esiste una risposta semplice alla domanda posta nel titolo di questo articolo. L'unico modo per scegliere il database giusto è conoscere meglio i propri dati. Rispondete alla domanda: "Che tipo di dati genera la vostra applicazione?", e sarete in grado di fare le scelte giuste.

Inoltre, è necessario conoscere molto bene i requisiti aziendali e il dominio dell'applicazione. Dovete sapere come utilizzerete i dati, quali query invierete al database, quante volte conserverete, leggerete, aggiornerete o cancellerete i dati. Tutti questi aspetti sono importanti, ma non tutti gli sviluppatori prestano sufficiente attenzione a queste aree.

Pensate ai vostri dati nell'applicazione che sviluppate per migliorare/creare un software migliore. In generale, spero che conoscerete i vostri dati abbastanza bene da memorizzarli in un luogo dove saranno felici.

Per saperne di più:

Alcuni trucchi per velocizzare l'applicazione JavaScript

Modi per aumentare le prestazioni di Rails

Fatti e miti sulla collaborazione con un partner esterno per lo sviluppo del software