Come scegliere il giusto tipo di database per la tua azienda

Esistono centinaia di revisioni di database ad alto contenuto tecnologico, ma non sempre forniscono indicazioni chiare sul primo passaggio nella selezione di un database: la scelta del miglior tipo generale per un'applicazione specifica. Tutti i database non sono creati uguali. Ciascuno ha punti di forza e di debolezza specifici. Sebbene sia vero che esistono soluzioni alternative per far funzionare un database preferito per la maggior parte dei progetti, l'utilizzo di questi trucchi aggiunge complessità non necessaria.

Prima di considerare un database specifico, prenditi del tempo per pensare a quale tipo sarebbe meglio supportare il progetto in questione. La domanda va più in profondità di "SQL vs NoSQL". Continua a leggere per una carrellata dei tipi di database più comuni, i relativi meriti di ciascuno e come stabilire qual è la soluzione migliore.

Sistemi di gestione di database relazionali (Oracle, MySQL, MS Server, PostgreSQL)

I database relazionali sono stati sviluppati negli anni '70 per gestire il crescente flusso di dati prodotti. Hanno una solida teoria di base e hanno influenzato quasi tutti i sistemi di database in uso oggi.

I database relazionali memorizzano i set di dati come "relazioni": tabelle con righe e colonne in cui tutte le informazioni sono memorizzate come valore di una cella specifica. I dati in un RDBMS vengono gestiti utilizzando SQL. Sebbene ci siano diverse implementazioni, SQL è standardizzato e fornisce un livello di prevedibilità e utilità.

Dopo che un primo flusso di fornitori ha cercato di trarre vantaggio dalla popolarità del sistema con prodotti non proprio relazionali, il creatore EF Codd ha delineato una serie di regole che devono essere seguite da tutti i sistemi di gestione di database relazionali. Le 12 regole di Codd ruotano attorno all'imposizione di rigidi protocolli di struttura interna, assicurandosi che le ricerche restituiscano in modo affidabile i dati richiesti e prevenendo alterazioni strutturali (almeno da parte degli utenti). Il framework ha garantito che i database relazionali siano coerenti e affidabili fino ad oggi.

Punti di forza

I database relazionali eccellono nella gestione di dati altamente strutturati e forniscono supporto per transazioni ACID (Atomicity, Consistency, Isolation, and Durability). I dati vengono facilmente archiviati e recuperati utilizzando query SQL. La struttura può essere scalata rapidamente perché l'aggiunta di dati senza modificare i dati esistenti è semplice.

La creazione di limiti su ciò che determinati tipi di utente possono accedere o modificare è incorporata nella struttura di un RDBMS. Per questo motivo, i database relazionali sono adatti alle applicazioni che richiedono un accesso a più livelli. Ad esempio, i clienti possono visualizzare i propri account mentre gli agenti possono visualizzare e apportare le modifiche necessarie.

Debolezze

La più grande debolezza dei database relazionali è lo specchio della loro più grande forza. Per quanto bravi a gestire i dati strutturati, hanno difficoltà con i dati non strutturati. Rappresentare entità del mondo reale nel contesto è difficile nei limiti di un RDBMS. I dati "suddivisi" devono essere riassemblati dalle tabelle in qualcosa di più leggibile e la velocità può essere influenzata negativamente. Anche lo schema fisso non reagisce bene al cambiamento.

Il costo è una considerazione con i database relazionali. Tendono ad essere più costosi da installare e crescere. Il ridimensionamento orizzontale, o il ridimensionamento mediante l'aggiunta di più server, è generalmente più veloce ed economico del ridimensionamento verticale, che implica l'aggiunta di più risorse a un server. Tuttavia, la struttura dei database relazionali complica il processo. Lo sharding (dove i dati sono partizionati orizzontalmente e distribuiti su una raccolta di macchine) è necessario per scalare un database relazionale. La condivisione dei database relazionali mantenendo la conformità ACID può essere una sfida.

Utilizza un database relazionale per:

  • Situazioni in cui l'integrità dei dati è assolutamente fondamentale (ad esempio, per applicazioni finanziarie, difesa e sicurezza e informazioni sulla salute privata)
  • Dati altamente strutturati
  • Automazione dei processi interni

Archivio documenti (MongoDB, Couchbase)

Un archivio di documenti è un database non relazionale che archivia i dati in documenti JSON, BSON o XML. Presentano uno schema flessibile. A differenza dei database SQL, in cui gli utenti devono dichiarare lo schema di una tabella prima di inserire i dati, gli archivi di documenti non applicano la struttura del documento. I documenti possono contenere tutti i dati desiderati. Hanno coppie chiave-valore ma incorporano anche metadati degli attributi per semplificare le query.

Punti di forza

Gli archivi di documenti sono molto flessibili. Gestiscono bene i dati semistrutturati e non strutturati. Gli utenti non hanno bisogno di sapere durante la configurazione quali tipi di dati verranno memorizzati, quindi questa è una buona scelta quando non è chiaro in anticipo quale tipo di dati saranno in arrivo.

Gli utenti possono creare la struttura desiderata in un particolare documento senza influire su tutti i documenti. Lo schema può essere modificato senza causare tempi di inattività, il che porta a un'elevata disponibilità. Anche la velocità di scrittura è generalmente elevata.

Oltre alla flessibilità, agli sviluppatori piacciono gli archivi di documenti perché sono facili da ridimensionare in orizzontale. Il partizionamento orizzontale necessario per il ridimensionamento orizzontale è molto più intuitivo rispetto ai database relazionali, quindi gli archivi di documenti vengono scalati in modo rapido ed efficiente.

Debolezze

I database dei documenti sacrificano la conformità ACID per la flessibilità. Inoltre, sebbene sia possibile eseguire query in un documento, non è possibile tra i documenti.

Usa un database di documenti per:

  • Dati non strutturati o semistrutturati
  • Gestione dei contenuti
  • Analisi approfondita dei dati
  • Prototipazione rapida

Archivio valore-chiave (Redis, Memcached)

Un archivio chiave-valore è un tipo di database non relazionale in cui ogni valore è associato a una chiave specifica. È anche noto come array associativo.

La "chiave" è un identificatore univoco associato solo al valore. Le chiavi possono essere qualsiasi cosa consentita dal DBMS. In Redis, ad esempio, le chiavi man possono essere qualsiasi sequenza binaria fino a 512 MB.

I "valori" vengono archiviati come BLOB e non richiedono uno schema predefinito. Possono assumere quasi tutte le forme: numeri, stringhe, contatori, JSON, XML, HTML, PHP, binari, immagini, brevi video, elenchi e persino un'altra coppia chiave-valore incapsulata in un oggetto. Alcuni DBMS consentono di specificare il tipo di dati, ma non è obbligatorio.

Punti di forza

Questo stile di database ha molti aspetti positivi. È incredibilmente flessibile, in grado di gestire facilmente un'ampia gamma di tipi di dati. Le chiavi vengono utilizzate per andare direttamente al valore senza ricerca di indice o join, quindi le prestazioni sono elevate. La portabilità è un altro vantaggio: gli archivi di valori-chiave possono essere spostati da un sistema a un altro senza riscrivere il codice. Infine, sono altamente scalabili orizzontalmente e hanno costi operativi inferiori complessivamente.

Debolezze

La flessibilità ha un prezzo. È impossibile eseguire query sui valori, perché sono archiviati come BLOB e possono essere restituiti solo come tali. Ciò rende difficile creare rapporti o modificare parti di valori. Non tutti gli oggetti sono nemmeno facili da modellare come coppie chiave-valore.

Utilizza un archivio di valori-chiave per:

  • Raccomandazioni
  • Profili utente e impostazioni
  • Dati non strutturati come recensioni di prodotti o commenti sul blog
  • Gestione delle sessioni su larga scala
  • Dati a cui si accederà frequentemente ma non spesso aggiornati

Magazzino a colonne larghe (Cassandra, HBase)

Gli archivi a colonne larghe, chiamati anche archivi di colonne o archivi di record estensibili, sono database dinamici non relazionali orientati alle colonne. A volte sono visti come un tipo di archivio di valori-chiave, ma hanno anche attributi dei database relazionali tradizionali.

Gli archivi a colonne larghe utilizzano il concetto di spazio delle chiavi invece di schemi. Uno spazio chiavi comprende famiglie di colonne (simili alle tabelle ma più flessibili nella struttura), ognuna delle quali contiene più righe con colonne distinte. Ogni riga non deve avere lo stesso numero o tipo di colonna. Un timestamp determina la versione più recente dei dati.

Punti di forza

Questo tipo di database presenta alcuni vantaggi dei database relazionali e non relazionali. Gestisce meglio i dati strutturati e semistrutturati rispetto ad altri database non relazionali ed è più facile da aggiornare. Rispetto ai database relazionali, è più scalabile orizzontalmente e più veloce su larga scala.

I database a colonne si comprimono meglio dei sistemi basati su righe. Inoltre, i set di dati di grandi dimensioni sono semplici da esplorare. Ad esempio, gli archivi a colonne larghe sono particolarmente adatti alle query di aggregazione.

Debolezze

Le scritture sono costose nel piccolo. Sebbene l'aggiornamento sia facile da eseguire in blocco, caricare e aggiornare i singoli record è difficile. Inoltre, gli archivi a colonne larghe sono più lenti dei database relazionali durante la gestione delle transazioni.

Utilizza un archivio a colonne larghe per:

  • Analisi dei big data in cui la velocità è importante
  • Data warehousing su big data
  • Progetti su larga scala (questo stile di database non è un buon strumento per applicazioni transazionali medie)

Motore di ricerca (Elasticsearch)

Può sembrare strano includere i motori di ricerca in un articolo sui tipi di database. Tuttavia, Elasticsearch ha riscontrato una maggiore popolarità in questa sfera poiché gli sviluppatori cercano modi innovativi per ridurre il ritardo di ricerca. Elastisearch è una soluzione per l'archiviazione e il recupero dei dati non relazionale, basata su documenti, specificatamente organizzata e ottimizzata per l'archiviazione e il recupero rapido dei dati.

Punti di forza

Elastisearch è molto scalabile. È dotato di uno schema flessibile e di un rapido recupero dei record, con opzioni di ricerca avanzate tra cui ricerca di testo completo, suggerimenti ed espressioni di ricerca complesse.

Una delle funzionalità di ricerca più interessanti è lo stemming. Lo stemming analizza la forma radice di una parola per trovare record rilevanti anche quando viene utilizzata un'altra forma. Ad esempio, un utente che cerca in un database di lavoro "lavori pagati" troverà anche posizioni contrassegnate come "retribuite" e "retribuite".

Debolezze

Elastisearch viene utilizzato più come archivio intermedio o supplementare che come database primario. Ha una bassa durata e una scarsa sicurezza. Non c'è autenticazione innata o controllo degli accessi. Inoltre, Elastisearch non supporta le transazioni.

Utilizza un motore di ricerca come Elastisearch per:

  • Miglioramento dell'esperienza utente con risultati di ricerca più rapidi
  • Registrazione

Considerazioni finali

Alcune applicazioni si adattano perfettamente ai punti di forza di un tipo di database specifico, ma per la maggior parte dei progetti c'è una sovrapposizione tra due o più. In questi casi, può essere utile esaminare quali database specifici negli stili contesi sono buoni candidati. I fornitori offrono un ampio spettro di funzionalità per adattare il proprio database a standard individuali. Alcuni di questi possono aiutare a risolvere l'incertezza su fattori come sicurezza, scalabilità e costi.