Volumi di dati senza precedenti stanno spingendo le imprese a cercare alternative alla tecnologia tradizionale, database relazionale che ci ha servito bene per oltre trent'anni . Collettivamente, queste alternative sono diventati noti come "database NoSQL".
Il problema fondamentale è che i database relazionali non sono in grado di gestire molti carichi di lavoro moderni. Ci sono tre aree specifiche problematiche: sealing out per set di dati come Digg ( 3 TB per badge verde ) o Facebook ( 50 TB per la casella di ricerca ) o di eBay ( 2 complessiva PB ), per le prestazioni del server , e la progettazione di schemi rigidi .
Le imprese, tra cui The Cloud Rackspace, hanno bisogno di trovare nuovi modi per archiviare e scalare grandi quantità di dati. Ci sono altri non-database relazionali che vengono chiamati il "movimento NoSQL".
Il termine "NoSQL" è stato coniato in realtà da un collega Racker, Eric Evans , quando Johan Oskarsson di Last.fm volle organizzare un evento per discutere di open source database distribuiti.
I principali metodi d’implementazione dei database NoSQL sono i seguenti:
Coloumnfamily: i dati sono organizzati in righe e colonne, ma le righe possono avere quante colonne si vogliono e non c’è bisogno di definire le colonne come prima cosa.
Document store: è l’evoluzione del metodo key/value, rispetto ai normali database relazionali invece che immagazzinare i dati in tabelle con dei campi fissi, questi vengono messi in un documento che può contenere illimitati campi di illimitata lunghezza, così se ad esempio di una persona conosciamo solo nome e cognome, ma magari di un’altra persona anche indirizzo, data di nascita e codice fiscale, si evita che per il primo nominativo ci siano campi inutilizzati che occupano inutilmente spazio.
Graph: i dati vengono immagazzinati sotto forma di strutture a grafi, rendendo più performante l’accesso a questi da applicativi orientati agli oggetti.
Key/Value: in questo caso i dati vengono immagazzinati in un elemento che contiene una chiave assieme ai dati veri e propri, questo metodo è il più semplice da implementare, ma anche il più inefficiente se la maggior parte delle operazioni riguardano soltanto una parte di un elemento.
NoSql Model
Vantaggi
- Dato che un elemento contiene tutte le informazioni necessarie non serve usare i dispendiosi (in termini di performance) JOIN come invece avviene per i database relazionali.
- La semplicità di questi database è uno degli elementi fondamentali, è proprio questo che permette di scalare in orizzontale in maniera così efficiente, molti NRDBMS, infatti, permettono di aggiungere nodi a caldo in maniera impercettibile dall’utente finale.
- Scegliendo un database adatto alla mappatura più diretta alle object classes del proprio applicativo si possono ridurre di molto i tempi dedicati allo sviluppo del metodo di scambio dati tra il database e l’applicativo stesso (il cosiddetto object-relational mapping che è invece necessario in presenza di database relazionali).
Svataggi
- La semplicità di questi database, però, porta anche alla mancanza dei controlli fondamentali sull’integrità dei dati, il compito ricade quindi totalmente sull’applicativo che dialoga col database che ovviamente dovrebbe essere testato in modo molto approfondito prima di essere messo in produzione. Per fare un esempio, se avessimo un database dei clienti coi relativi ordini effettuati immagazzinati in elementi diversi, anche se è possibile definire una relazione attraverso le chiavi, in un database non relazionale alla cancellazione di un cliente tutti gli ordini resterebbero comunque nel database, è quindi l’applicativo che una volta impartito il comando di cancellazione dell’utente X deve anche andare a cancellare tutti i relativi ordini, cosa che invece in un database relazionale è gestita direttamente dal database stesso.
- La mancanza di uno standard universale (come può essere l’SQL) è un’altra delle pecche di questi database non relazionali, ogni database ha infatti le proprie API e il suo metodo di storing e di accesso ai dati. Detto questo, risulta palese che se lo sviluppo del database sul quale abbiamo basato il nostro applicativo venisse interrotto, il passaggio ad un altro database non sarebbe sicuramente una cosa immediata, ma richiederebbe alcuni cambi più o meno radicali da apportare all’applicativo, è quindi bene tenere in considerazione la cosa al momento del brainstorming iniziale.
By ImaginSystems & Queen Gin