I database relazionali sono nati nell'era dei mainframe e delle applicazioni aziendali - molto prima di Internet, del cloud, dei big data, dei dispositivi mobili e dell'impresa oggi fortemente interattiva. In effetti, la prima implementazione commerciale è stata rilasciata da Oracle nel 1979. Questi database sono stati progettati per funzionare su un singolo server: più grande è, meglio è. L'unico modo per aumentare la capacità di questi database era aggiornare i server - processori, memoria e archiviazione - per ridimensionarli.

I database NoSQL sono emersi a seguito della crescita esponenziale di Internet e dell'aumento delle applicazioni Web. Google ha pubblicato il documento di ricerca Bigtable nel 2006 e Amazon ha pubblicato il documento di ricerca Dynamo nel 2007. Questi database sono stati progettati per soddisfare una nuova generazione di requisiti aziendali:

Sviluppare con agilità

Per rimanere competitivi nell'odierna economia digitale incentrata sull'esperienza d'uso, le imprese devono innovare e devono farlo più velocemente che mai. E poiché questa innovazione è incentrata sullo sviluppo di moderne applicazioni Web, mobili e IoT, gli sviluppatori devono fornire applicazioni e servizi più rapidamente che mai. Velocità e agilità sono entrambi fondamentali perché queste applicazioni si evolvono molto più velocemente rispetto alle applicazioni legacy come gli ERP. I database relazionali sono un ostacolo importante perché non supportano molto bene lo sviluppo agile a causa del loro modello di dati fissi.

Adattarsi allo scopo, per supportare esigenze mutevoli

Un principio fondamentale dello sviluppo agile è quello di sapersi adattare ai requisiti applicativi in evoluzione: quando i requisiti cambiano, cambia anche il modello di dati. Questo è un problema per i database relazionali perché il modello di dati è fisso e definito da uno schema statico. Pertanto, per modificare il modello di dati, gli sviluppatori devono modificare lo schema o, peggio ancora, richiedere una "modifica dello schema" agli amministratori del database. Questo rallenta o interrompe lo sviluppo, non solo perché è un processo manuale che richiede tempo, ma anche perché influisce su altre applicazioni e servizi.

Flessibilità, per sviluppare velocemente

In confronto, un database di documenti NoSQL supporta pienamente lo sviluppo agile, perché è privo di schemi e non definisce staticamente come i dati devono essere modellati. Con NoSQL, il modello di dati è definito dal modello dell'applicazione. Applicazioni e servizi modellano i dati come oggetti.

Semplicità, per uno sviluppo più facile

Applicazioni e servizi modellano i dati come oggetti (ad es. Dipendent) e, dati multivalore come collezioni (ad es. Ruoli) e dati correlati come oggetti o collezioni nidificati (ad es. Manager). Invece, i database relazionali modellano i dati come tabelle di righe e colonne, i dati correlati come righe all'interno di tabelle diverse e i dati multivalore come righe all'interno della stessa tabella. Il problema con i database relazionali è che i dati vengono letti e scritti disassemblando, o "distruggendo" e riassemblando oggetti. Questa è la "mancata corrispondenza" del concetto relazionale con gli oggetti. Una soluzione alternativa potrebbero essere i framework di mappatura relazionali tra oggetti, ma nella migliore delle ipotesi sono inefficienti e nella peggiore assai problematici.

Ad esempio, prendiamo in considerazione un'applicazione per la gestione dei Curricula. Ogni Curriculum come oggetto, contiene:

1. l'oggetto utente;

2. un array per le competenze;

3. una collezione per le esperienze pregresse.

La scrittura di un Curriculum in un database relazionale richiede all'applicazione di “frammentare” l'oggetto utente.

La memorizzazione di questo Curriculum richiederebbe all'applicazione di inserire sei righe in tre tabelle:

Successivamente, la lettura di questo profilo richiederebbe all'applicazione di leggere sei righe da tre tabelle:

Al contrario, un database NoSQL orientato ai documenti legge e scrive i dati formattati in JSON, che è lo standard di fatto per il consumo e la produzione di dati per applicazioni Web, mobili e IoT. Non solo elimina la discrepanza di impedenza relazionale dell'oggetto, ma elimina anche il sovraccarico dei framework ORM e semplifica lo sviluppo dell'applicazione perché gli oggetti vengono letti e scritti senza "distruggerli" (ovvero, un singolo oggetto può essere letto o scritto come un singolo documento):

Che dire di query e SQL?

Sin dalla versione 4.0 (ottobre 2015), Couchbase Server ha introdotto N1QL, un potente linguaggio di query che estende SQL a JSON, consentendo agli sviluppatori di sfruttare sia la potenza di SQL che la flessibilità di JSON. Supporta non solo le istruzioni SELECT / FROM / WHERE standard, ma supporta anche l'aggregazione (GROUP BY), l'ordinamento (SORT BY), i join (LEFT OUTER / INNER), nonché l'interrogazione di matrici e collezioni nidificate. Inoltre, le prestazioni delle query possono essere migliorate con indici compositi, parziali, di copertura e altro ancora.

SQL

SELECT breweries.name AS brewery,
   count(*) AS cnt
FROM beers
INNER JOIN breweries
ON beer.brewery_id = breweries.id
WHERE beers.type = "beer" AND
   breweries.type = "brewery" AND
   beers.style = "American-Style Imperial Stout"
GROUP BY breweries.name
HAVING count(*) > 2
ORDER BY cnt DESC;

N1QL

SELECT breweries.name AS brewery,
   count(*) AS cnt
FROM `beer-sample` beers
INNER JOIN `beer-sample` breweries
ON KEYS beers.brewery_id
WHERE beers.type = "beer" AND
   breweries.type = "brewery" AND
   beers.style = "American-Style Imperial Stout"
GROUP BY breweries.name
HAVING count(*) > 2
ORDER BY cnt DESC;

Operare su qualsiasi scala

I database che supportano applicazioni Web, mobili e IoT devono essere in grado di funzionare su qualsiasi scala. Sebbene sia possibile ridimensionare un database relazionale come Oracle (utilizzando, ad esempio, Oracle RAC), farlo in genere è complesso, costoso e non completamente affidabile. Con Oracle, ad esempio, il ridimensionamento mediante la tecnologia RAC richiede numerosi componenti e crea un singolo punto di failure che mette a rischio la disponibilità. In confronto, un database distribuito NoSQL - progettato con un'architettura scalabile e nessun singolo punto di failure - offre inavvicinabili vantaggi operativi.

Elasticità per prestazioni su larga scala

Le applicazioni e i servizi devono supportare un numero sempre crescente di utenti e dati: da centinaia a migliaia a milioni di utenti e da gigabyte a terabyte di dati operativi. Allo stesso tempo, devono essere in grado di scalare per mantenere le prestazioni e devono farlo in modo efficiente.

Questo è un problema per i database relazionali che si limitano al ridimensionamento (ovvero, aggiungendo più processori, memoria e archiviazione a un singolo server fisico). Di conseguenza, la capacità di scalare in modo efficiente e su richiesta è un elemento di grande criticità. Diventa sempre più costoso perché le aziende devono acquistare server sempre più grandi per ospitare più utenti e più dati. Inoltre, può causare tempi di inattività se il database deve essere portato offline per eseguire aggiornamenti hardware.

Un database NoSQL distribuito, invece, sfrutta l'hardware a basso costo per scalare, ovvero aggiungere più risorse semplicemente aggiungendo più server. La capacità di ridimensionamento consente alle aziende di scalare in modo più efficiente:

1. distribuendo non più hardware di quanto sia necessario per soddisfare il carico corrente;

2. sfruttando l'infrastruttura hardware e/o cloud meno costosa;

3. ridimensionando su richiesta e senza tempi di inattività.

Oltre a poter scalare in modo efficace ed efficiente, i database distribuiti NoSQL sono facili da installare, configurare e ridimensionare. Sono stati progettati per distribuire letture, scritture e archiviazione tra i nodi disponibili, e sono stati progettati per funzionare su qualsiasi scala, da un singolo cluster di soli 3 nodi a molteplici cluster di centinaia di nodi, distribuiti geograficamente su più datacenter.

Disponibilita "sempre attiva", distribuzione globale

Dato che sempre più l'utilizzo dei clienti è online via web e app mobili, la disponibilità diventa un fattore importante, se non primario. Queste applicazioni mission-critical devono essere disponibili 24 ore al giorno, 7 giorni alla settimana, senza eccezioni. Fornire disponibilità 24x7 è una sfida per i database relazionali distribuiti su un singolo server fisico, o che si basano sul clustering con storage condiviso. Se distribuito come server singolo e ha un failure, oppure come cluster e lo storage condiviso ha un failure, il database diventa non disponibile.

Contrariamente alla tecnologia relazionale, un database NoSQL distribuito partiziona e distribuisce i dati a più istanze di database senza risorse condivise (come ad esempio lo storage). Inoltre, i dati possono essere replicati in una o più istanze per l'alta disponibilità (replica intercluster). Mentre i database relazionali come Oracle richiedono software separato per la replica (ad es. Oracle Active Data Guard), i database NoSQL non richiedono software aggiuntivi (minori costi di gestione) - la funzionalità è integrata ed è automatica. Inoltre, il failover automatico garantisce che, in caso di errore di un nodo, il database possa continuare a eseguire letture e scritture inviando le richieste ad un nodo diverso.

Man mano che aumenta il numero degli utenti (worldwide), diventa fondamentale la necessità di essere disponibili in più paesi e/o regioni. La distribuzione di un database su più datacenter aumenta la disponibilità e aiuta il ripristino di emergenza, ma ha anche il vantaggio di aumentare le prestazioni, poiché tutte le letture e le scritture possono essere eseguite sul datacenter più vicino, riducendo così la latenza .

Garantire la disponibilità globale per i database relazionali è difficile, in particolare nei casi in cui la necessità di componenti aggiuntivi separati aumenta la complessità (ad es. Oracle richiede Oracle GoldenGate per spostare i dati tra i database) - o quando la replica tra più data center può essere utilizzata solo per il failover, perché solo un datacenter è attivo alla volta. Inoltre, durante la replica tra datacenter, le applicazioni basate su database relazionali possono subire un deterioramento delle prestazioni o rilevare che i datacenter sono, fatto questo gravissimo, non sincronizzati.

Un database NoSQL distribuito include la replica integrata tra i datacenter - non è richiesto alcun software separato. Inoltre, alcuni includono sia la replica unidirezionale che bidirezionale che consente distribuzioni full active-active su più datacenter, che consentono di distribuire il database in più paesi e/o regioni e di fornire l'accesso ai dati dalla regione più prossima a dove si trova l'utente, o comunque dal datacenter con la minor latenza. Ciò non solo migliora le prestazioni, ma consente anche il failover immediato tramite router hardware: le applicazioni non devono attendere che il database rilevi l'errore ed esegua il proprio failover.

NoSQL si adatta meglio ai requisiti dell'economia digitale

Man mano che le aziende passano all'economia digitale, abilitata da cloud, dispositivi mobili, social media e tecnologie per i big data, gli sviluppatori e i team operativi devono creare e gestire applicazioni Web, mobili e Internet of Things (IoT) sempre più velocemente e su grande scala. NoSQL è sempre più la tecnologia di database preferita per alimentare le attuali applicazioni web, mobile e IoT.

Centinaia di aziende Global 2000, insieme a decine di migliaia di piccole imprese e startup, hanno adottato NoSQL. Per molti, l'uso di NoSQL è iniziato con una cache (messo davanti ad altri db per velocizzare l'ingestion), una prova di fattibilità o una piccola applicazione, poi si è esteso ad applicazioni mission-critical mirate, ed è ora la base per lo sviluppo di tutte le applicazioni.

Con NoSQL, le aziende sono in grado di svilupparsi con più agilità, operare su qualsiasi scala e fornire le prestazioni e la disponibilità necessarie per soddisfare le esigenze di business dell'economia digitale.