Cos'è NoSQL? Database per un futuro su scala cloud

Una delle scelte fondamentali da fare durante lo sviluppo di un'applicazione è se utilizzare un database SQL o NoSQL per archiviare i dati. I database SQL convenzionali (ovvero relazionali) sono il prodotto di decenni di evoluzione tecnologica, buone pratiche e prove di stress nel mondo reale. Sono progettati per transazioni affidabili e query ad hoc, le basi delle applicazioni line of business. Ma sono anche gravati da restrizioni, come schemi rigidi, che li rendono meno adatti ad altri tipi di app.

I database NoSQL sono nati in risposta a queste limitazioni. I sistemi NoSQL archiviano e gestiscono i dati in modi che consentono un'elevata velocità operativa e una grande flessibilità da parte degli sviluppatori. Molti sono stati sviluppati da aziende come Google, Amazon, Yahoo e Facebook che cercavano modi migliori per archiviare contenuti o elaborare dati per siti Web di grandi dimensioni. A differenza dei database SQL, molti database NoSQL possono essere scalati orizzontalmente su centinaia o migliaia di server.

I vantaggi di NoSQL non sono però privi di costi. I sistemi NoSQL in genere non forniscono lo stesso livello di coerenza dei dati dei database SQL. Infatti, mentre i database SQL hanno tradizionalmente sacrificato le prestazioni e la scalabilità per le proprietà ACID dietro transazioni affidabili, i database NoSQL hanno ampiamente abbandonato quelle garanzie ACID per velocità e scalabilità.

In breve, i database SQL e NoSQL offrono diversi compromessi. Mentre possono competere nel contesto di uno specifico progetto, come in, quale scegliere per questa applicazione o che applicazioni sono complementari nel quadro più ampio. Ciascuno è adatto a diversi casi d'uso. La decisione non è tanto un caso di o / o quanto una questione di quale strumento è giusto per il lavoro.

NoSQL contro SQL

La differenza fondamentale tra SQL e NoSQL non è poi così complicata. Ognuno ha una filosofia diversa per la modalità di archiviazione e recupero dei dati.

Con i database SQL, tutti i dati hanno una struttura intrinseca. Un database convenzionale come Microsoft SQL Server, MySQL o Oracle Database utilizza uno schema : una definizione formale di come verranno composti i dati inseriti nel database. Ad esempio, una determinata colonna in una tabella può essere limitata solo a numeri interi. Di conseguenza, i dati registrati nella colonna avranno un alto grado di normalizzazione. Lo schema rigido di un database SQL rende anche relativamente facile eseguire aggregazioni sui dati, ad esempio tramite JOIN.

Con NoSQL, i dati possono essere archiviati in modalità senza schema o in formato libero. Tutti i dati possono essere memorizzati in qualsiasi record. Tra i database NoSQL, troverai quattro modelli comuni per l'archiviazione dei dati, che portano a quattro tipi comuni di sistemi NoSQL:

  1. Database di documenti (ad esempio CouchDB, MongoDB). I dati inseriti vengono archiviati sotto forma di strutture JSON in formato libero o "documenti", in cui i dati possono essere qualsiasi cosa, da numeri interi a stringhe a testo in formato libero. Non vi è alcuna necessità intrinseca di specificare quali campi, se presenti, conterrà un documento.
  2. Archivi chiave-valore (ad esempio Redis, Riak). I valori in formato libero, da semplici interi o stringhe a complessi documenti JSON, sono accessibili nel database tramite chiavi.
  3. Grandi magazzini di colonne (es. HBase, Cassandra). I dati vengono archiviati in colonne anziché in righe come in un sistema SQL convenzionale. Qualsiasi numero di colonne (e quindi molti diversi tipi di dati) può essere raggruppato o aggregato secondo necessità per query o visualizzazioni dati.
  4. Database grafici (es. Neo4j). I dati sono rappresentati come una rete o un grafico di entità e le loro relazioni, con ogni nodo nel grafico un blocco di dati in formato libero.

L'archiviazione dei dati senza schema è utile nei seguenti scenari:

  1. Desideri un accesso rapido ai dati e sei più interessato alla velocità e alla semplicità di accesso che alle transazioni affidabili o alla coerenza.
  2. Stai archiviando un grande volume di dati e non vuoi bloccarti in uno schema, poiché modificare lo schema in un secondo momento potrebbe essere lento e doloroso.
  3. Stai acquisendo dati non strutturati da una o più origini che li producono e desideri mantenere i dati nella loro forma originale per la massima flessibilità.
  4. Si desidera archiviare i dati in una struttura gerarchica, ma si desidera che tali gerarchie siano descritte dai dati stessi, non da uno schema esterno. NoSQL consente ai dati di essere casualmente autoreferenziali in modi che sono più complessi da emulare per i database SQL.

Interrogazione di database NoSQL

Il linguaggio di query strutturato utilizzato dai database tradizionali fornisce un modo uniforme per comunicare con il server durante l'archiviazione e il recupero dei dati. La sintassi SQL è altamente standardizzata, quindi mentre i singoli database possono gestire determinate operazioni in modo diverso (ad esempio, le funzioni della finestra), le basi rimangono le stesse.

Al contrario, ogni database NoSQL tende ad avere la propria sintassi per l'interrogazione e la gestione dei dati. CouchDB, ad esempio, utilizza le richieste sotto forma di JSON, inviate tramite HTTP, per creare o recuperare documenti dal proprio database. MongoDB invia oggetti JSON tramite un protocollo binario, tramite un'interfaccia a riga di comando o una libreria di lingue.

Alcuni prodotti NoSQL possono utilizzare la sintassi simile a SQL per lavorare con i dati, ma solo in misura limitata. Ad esempio, Apache Cassandra, un database di archivio di colonne, dispone di un proprio linguaggio simile a SQL, il Cassandra Query Language o CQL. Alcune delle sintassi CQL provengono direttamente dal playbook SQL, come le parole chiave SELECT o INSERT. Ma non è possibile eseguire un JOIN o una sottoquery in Cassandra, quindi le parole chiave correlate non esistono in CQL.

Architettura del nulla condiviso

Una scelta di progettazione comune ai sistemi NoSQL è un'architettura "non condivisa". In una progettazione con niente condiviso, ogni nodo del server nel cluster opera indipendentemente da ogni altro nodo. Il sistema non deve ottenere il consenso da ogni singolo nodo per restituire un dato a un client. Le query sono veloci perché possono essere restituite dal nodo più vicino o più conveniente.

Un altro vantaggio del nulla condiviso è la resilienza e la scalabilità orizzontale. Scalare il cluster è facile come avviare nuovi nodi nel cluster e attendere che si sincronizzino con gli altri. Se un nodo NoSQL si interrompe, gli altri server nel cluster continueranno ad andare avanti. Tutti i dati rimangono disponibili, anche se sono disponibili meno nodi per servire le richieste.

Si noti che un design non condiviso non è esclusivo dei database NoSQL. Molti sistemi SQL convenzionali possono essere configurati in modo non condiviso, sebbene ciò implichi in genere il sacrificio della coerenza nel cluster per le prestazioni.

Limitazioni NoSQL

Se NoSQL offre così tanta libertà e flessibilità, perché non abbandonare completamente SQL? La risposta semplice: molte applicazioni richiedono ancora i tipi di vincoli, coerenza e protezioni forniti dai database SQL. In questi casi, alcuni "vantaggi" di NoSQL possono trasformarsi in svantaggi. Altre limitazioni derivano dal fatto che i sistemi NoSQL sono relativamente nuovi. 

Nessuno schema

Anche se stai acquisendo dati in formato libero, devi quasi sempre imporgli dei vincoli per renderlo utile. Con NoSQL, l'imposizione di vincoli implica lo spostamento della responsabilità dal database allo sviluppatore dell'applicazione. Ad esempio, lo sviluppatore potrebbe imporre la struttura tramite un sistema di mappatura relazionale degli oggetti o ORM. Ma se vuoi che lo schema viva con i dati stessi , NoSQL in genere non lo fa.

Alcune soluzioni NoSQL forniscono la tipizzazione dei dati e meccanismi di convalida opzionali per i dati. Apache Cassandra, ad esempio, ha una sfilza di tipi di dati nativi che ricordano quelli presenti nell'SQL convenzionale.

Eventuale consistenza

I sistemi NoSQL scambiano una coerenza forte o immediata per una migliore disponibilità e prestazioni. I database convenzionali garantiscono che le operazioni siano atomiche (tutte le parti di una transazione hanno esito positivo o nessuna), coerenti (tutti gli utenti hanno la stessa visualizzazione dei dati), isolate (le transazioni non competono) e durevoli (una volta completate sopravviveranno un errore del server).

Queste quattro proprietà, denominate collettivamente ACID, vengono gestite in modo diverso nella maggior parte dei sistemi NoSQL. Invece di coerenza immediata nel cluster, avete eventuale consistenza, a causa del tempo necessario per copiare gli aggiornamenti di altri nodi del cluster. I dati inseriti nel cluster sono eventualmente disponibili ovunque, ma non puoi garantire quando.

La semantica della transazione, che in un sistema SQL garantisce che tutti i passaggi di una transazione (ad esempio l'esecuzione di una vendita e la riduzione dell'inventario) siano completati o annullati, non sono generalmente disponibili in NoSQL. Per qualsiasi sistema in cui deve esserci una "singola fonte di verità", come una banca, l'approccio NoSQL non funzionerà bene. Non vuoi che il tuo conto in banca sia diverso a seconda del bancomat in cui ti rechi; vuoi che sia segnalato come la stessa cosa ovunque.

Alcuni database NoSQL hanno meccanismi parziali per aggirare questo problema. Ad esempio, MongoDB ha garanzie di coerenza per singole operazioni, ma non per il database nel suo insieme. Microsoft Azure CosmosDB ti consente di selezionare un livello di coerenza per richiesta, in modo da poter scegliere il comportamento adatto al tuo caso d'uso. Ma con NoSQL, aspettati una consistenza finale come comportamento predefinito.

Blocco NoSQL

La maggior parte dei sistemi NoSQL sono concettualmente simili, ma sono implementati in modo molto diverso. Ciascuno tende ad avere le proprie metafore e meccanismi per il modo in cui i dati vengono interrogati e gestiti.

Un effetto collaterale di ciò è un grado potenzialmente elevato di accoppiamento tra la logica dell'applicazione e il database. Non è così male se scegli un sistema NoSQL e lo segui, ma può diventare un ostacolo se cambi sistema lungo la strada.

Se esegui la migrazione, ad esempio, da MongoDB a CouchDB (o viceversa), devi fare di più che migrare i dati. È inoltre necessario esplorare le differenze nell'accesso ai dati e nelle metafore programmatiche: in altre parole, è necessario riscrivere le parti dell'applicazione che accedono al database.

Competenze NoSQL

Un altro aspetto negativo di NoSQL è la relativa mancanza di esperienza. Laddove il mercato del talento SQL convenzionale è ancora piuttosto ampio, il mercato delle competenze NoSQL è nascente.

Per riferimento, Indeed.com segnala che alla fine del 2017, il volume degli annunci di lavoro per i database SQL convenzionali (MySQL, Microsoft SQL Server, Oracle Database e così via) rimane più alto negli ultimi tre anni rispetto al volume dei lavori per MongoDB, Couchbase e Cassandra. La richiesta di competenze NoSQL è in crescita, ma è ancora una frazione del mercato per SQL convenzionale.

Unione di SQL e NoSQL

Possiamo aspettarci che alcune delle differenze tra i sistemi SQL e NoSQL scompaiano nel tempo. Già molti database SQL ora accettano documenti JSON come tipo di dati nativo e possono eseguire query su tali dati. Alcuni hanno anche modi nativi per imporre vincoli ai dati JSON, in modo che vengano gestiti con gli stessi rigori dei dati tradizionali di riga e colonna.

Il rovescio della medaglia, i database NoSQL non solo aggiungono linguaggi di query simili a SQL, ma altre funzionalità dei database SQL tradizionali. Ad esempio, almeno due database di documenti - MarkLogic e RavenDB - promettono di essere conformi ad ACID.

Qua e là ci sono segni che le future generazioni di database saranno a cavallo dei paradigmi e offriranno funzionalità sia NoSQL che SQL. Azure Cosmos DB di Microsoft, ad esempio, utilizza una serie di primitive nascoste per riprodurre in modo intercambiabile i comportamenti di entrambi i tipi di sistemi. Google Cloud Spanner è un database SQL che combina una forte coerenza con la scalabilità orizzontale dei sistemi NoSQL.

Tuttavia, i sistemi SQL puri e NoSQL puri avranno il loro posto per molti anni a venire. Cerca NoSQL per un accesso veloce e altamente scalabile ai dati in formato libero. Ciò comporta pochi costi, come la coerenza delle letture e altre protezioni comuni ai database SQL. Ma per molte applicazioni, queste protezioni potrebbero valere la pena scambiare per ciò che offre NoSQL.