Una guida a NoSQL per gli sviluppatori

Se hai seguito le tendenze nello sviluppo backend e nei Big Data, probabilmente hai già notato il brusio attorno ai database NoSQL negli ultimi anni. Alcune persone si ispirano a questo approccio al database, mentre altri pensano che ci sia qualche trucco nascosto in esso: i modelli di dati in essi contenuti non sono gli stessi dei soliti database relazionali, le interfacce di programmazione delle applicazioni sono insolite e il le applicazioni sono spesso incomprensibili. In questo articolo ti dirò perché sono stati creati in primo luogo questi database NoSQL, quali problemi risolvono e perché improvvisamente sono necessari così tanti database diversi. Se sei nuovo a NoSQL, potresti essere particolarmente interessato all'ultima parte dell'articolo, che elenca i tipi di database NoSQL che ritengo valga la pena esplorare prima per acquisire una conoscenza approfondita del campo.

Perché improvvisamente abbiamo bisogno di un nuovo database?

Potresti essere perplesso nel chiederti: cosa c'è di sbagliato nei database relazionali? Il punto è che hanno funzionato davvero bene per molti anni, ma ora c’è un problema che non riescono più a gestire. Secondo alcune previsioni, nel 2018 l’umanità genererà 50.000 gigabyte di dati al secondo. Si tratta di una quantità colossale di dati! Il suo stoccaggio e la sua movimentazione rappresentano una seria sfida ingegneristica. Ciò che è ancora peggio è che questo volume è in costante crescita. A quanto pare, i database relazionali sono poco adatti a lavorare con volumi di dati molto grandi. Sono progettati per funzionare su una singola macchina e, se desideri gestire più richieste, l'unica opzione è acquistare un computer con più RAM e un processore più potente. Sfortunatamente, il numero di query che una macchina può gestire è limitato e per il lavoro distribuito su più macchine abbiamo bisogno di una tecnologia di database diversa. Naturalmente, alcuni lettori a questo punto ridaccheranno e diranno che esistono due metodi diffusi per utilizzare più macchine nel caso di un database relazionale: replica e sharding. E’ vero, ma questi metodi non sono sufficienti per far fronte ai nostri compiti. La replica di lettura è una tecnica in cui ogni aggiornamento del database viene propagato ad altre macchine che possono gestire solo richieste di lettura. In questo caso, tutte le modifiche vengono eseguite da un server, chiamato nodo master, mentre gli altri server, chiamati repliche di lettura, mantengono solo copie dei dati. L'utente può leggere da qualsiasi macchina, ma modificare i dati solo tramite il nodo master. Questo è un metodo comodo e molto diffuso, ma consente solo di elaborare più richieste di lettura e non risolve in alcun modo il problema dell'elaborazione dei volumi di dati richiesti. Lo sharding è un altro approccio popolare che utilizza più istanze di un database relazionale. Ciascuno di essi gestisce le operazioni di scrittura e lettura per una parte dei dati. Se un database memorizza informazioni sui clienti, ad esempio utilizzando lo sharding, una macchina può gestire tutte le richieste per i clienti i cui nomi iniziano con A, un'altra macchina può memorizzare tutti i dati per i clienti i cui nomi iniziano con B e così via. Sebbene lo sharding ti permetta di registrare più dati, gestire un database del genere è un vero incubo: devi allineare i dati tra le macchine e scalare il cluster in entrambe le direzioni secondo necessità. Anche se in teoria sembra semplice, farlo bene è piuttosto impegnativo.

È possibile migliorare i database relazionali?

Penso che tu sia già arrivato a credere che i database relazionali non siano i più adatti al volume di dati generati nel mondo moderno. Tuttavia, potresti ancora chiederti perché nessuno ha ancora creato un database relazionale "migliore" che possa essere eseguito in modo efficiente su più macchine. Può sembrare che questa tecnologia semplicemente non sia stata ancora sviluppata e che i database relazionali distribuiti appariranno molto presto. Ahimè, questo non accadrà. Questo è matematicamente impossibile e non si può fare nulla al riguardo. Per capire perché è così, è necessario considerare il cosiddetto teorema CAP (noto anche come teorema di Brewer). È stato dimostrato nel 1999 e afferma che un database distribuito in esecuzione su più macchine può avere le seguenti tre proprietà: Coerenza : qualsiasi operazione di lettura restituisce i risultati dell'ultima operazione di scrittura corrispondente. Se il sistema è coerente, dopo aver scritto nuovi dati, è impossibile leggere i vecchi dati già sovrascritti. Disponibilità ( A disponibilità): un sistema distribuito può soddisfare una richiesta in arrivo in qualsiasi momento e restituire una risposta priva di errori. Tolleranza della partizione : il database continua a rispondere alle richieste di lettura e scrittura anche quando alcuni dei suoi server non sono temporaneamente in grado di comunicare tra loro. Questo guasto temporaneo è chiamato guasto di connettività di rete e può essere causato da una serie di fattori, che vanno dai problemi fisici della rete dovuti a un server lento ai danni fisici alle apparecchiature di rete. Tutte queste proprietà sono sicuramente utili e ci piacerebbe davvero un database per combinarle tutte. Nessuno sviluppatore sano di mente vorrebbe rinunciare, ad esempio, all’accessibilità senza ottenere nulla in cambio. Sfortunatamente, il teorema CAP afferma anche che è impossibile che tutte e tre le proprietà siano valide contemporaneamente. Realizzarlo potrebbe non essere facile, ma è possibile. Innanzitutto, se abbiamo bisogno di un database distribuito, deve essere “tollerante alla disconnessione”. Di questo non si discute nemmeno. Le disconnessioni si verificano continuamente e il nostro database deve funzionare nonostante ciò. Ora capiamo perché non riusciamo a raggiungere sia la coerenza che la disponibilità. Immaginiamo di avere un semplice database in esecuzione su due macchine: A e B. Qualsiasi utente può scrivere su entrambe le macchine, dopodiché i dati vengono copiati sull'altra. Ora immagina che queste macchine non siano temporaneamente in grado di comunicare tra loro e che la macchina B non sia in grado di inviare o ricevere dati dalla macchina A. Se durante questo periodo di tempo la macchina B riceve una richiesta di lettura da un client, ha due opzioni:

1. Recupera i tuoi dati locali, anche se non sono gli ultimi. In questo caso si privilegia la disponibilità (per restituire almeno alcuni dati, anche quelli non aggiornati).
2. Errore di restituzione. In questo caso è preferibile la coerenza: il client non riceverà dati obsoleti, ma non riceverà alcun dato.

I database relazionali si sforzano di incorporare simultaneamente le proprietà di "coerenza" e "disponibilità" e pertanto non possono funzionare in un ambiente distribuito. Cercare di implementare tutte le funzionalità di un database relazionale in un sistema distribuito sarà irrealistico o semplicemente irrealizzabile . D’altro canto, i database NoSQL privilegiano la scalabilità e le prestazioni. Di solito mancano capacità “di base” come connessioni e transazioni, e il modello di dati risulta essere completamente diverso, forse addirittura limitante in qualche modo. Tutto ciò consente di archiviare volumi di dati più grandi ed elaborare un numero di query mai raggiunto prima.

In che modo i database NoSQL bilanciano coerenza e disponibilità?

Potrebbe sembrarti che se scegli un database NoSQL, riceverai sempre dei dati obsoleti o un errore in caso di guasto. In pratica, disponibilità e coerenza non sono affatto le uniche opzioni disponibili. C'è una vasta gamma di opzioni disponibili tra cui scegliere. I database relazionali non dispongono di queste opzioni, ma NoSQL consente di controllare l'esecuzione delle query in modo simile. In un modo o nell'altro, consentono di impostare due parametri quando si eseguono operazioni di scrittura o lettura in un database NoSQL: W - quante macchine nel cluster devono confermare il salvataggio dei dati quando si esegue un'operazione di scrittura . Maggiore è il numero di macchine su cui scrivi i tuoi dati, più facile sarà leggere i dati più recenti alla successiva operazione di lettura, ma anche più tempo sarà necessario. R – da quante macchine vorresti leggere i dati . In un sistema distribuito, la distribuzione dei dati a tutte le macchine in un cluster può richiedere del tempo, quindi alcuni server avranno i dati più recenti mentre altri saranno in ritardo. Maggiore è il numero di macchine da cui vengono letti i dati, maggiori sono le possibilità di leggere i dati attuali. Diamo un'occhiata a un esempio pratico. Se nel cluster sono presenti cinque computer e si decide di scrivere i dati su uno solo e quindi di leggere i dati da un computer selezionato casualmente, esiste una probabilità dell'80% di leggere dati non aggiornati. D’altro canto, ciò utilizzerà un minimo di risorse. Quindi, se per te i dati legacy vanno bene, non è una cattiva opzione. In questo caso i parametri W e R sono uguali a 1. D'altra parte, se scrivi dati su tutte e cinque le macchine in un database NoSQL, puoi leggere i dati da qualsiasi macchina ed avere la garanzia di ottenere dati aggiornati ogni volta. Eseguire la stessa operazione su un numero maggiore di macchine richiederà più tempo, ma se per te sono importanti i dati aggiornati, puoi scegliere questa opzione. In questo caso, W = R = 5. Qual è il numero minimo di letture e scritture richieste per la coerenza del database? Ecco una formula semplice: R + W ≥ N + 1 , dove N è il numero di macchine nel cluster. Ciò significa che con cinque server è possibile scegliere R = 2 e W = 4, oppure R = 3 e W = 3, oppure R = 4 e W = 2. In questo caso, non importa su quali macchine vengono trasmessi i dati viene scritto, la lettura verrà sempre eseguita da almeno una macchina con dati aggiornati. Altri database, come DynamoDB, hanno restrizioni diverse e consentono solo scritture coerenti. Ogni dato viene archiviato su tre server e, quando viene scritto, un dato viene scritto su due delle tre macchine. Ma durante la lettura dei dati, puoi scegliere una delle due opzioni:

1. Lettura strettamente coerente, in cui i dati vengono letti da due macchine su tre e restituisce sempre l'ultimo dato scritto.
2. Un'eventuale lettura coerente, in cui viene selezionata casualmente una macchina da cui leggere i dati. Tuttavia, ciò potrebbe restituire temporaneamente dati obsoleti.

Perché ci sono così tanti database NoSQL?

Se segui le ultime novità nel campo dello sviluppo software, probabilmente hai sentito parlare di molti database NoSQL diversi, come MongoDB, DynamoDB, Cassandra, Redis e molti altri. Forse ti starai chiedendo: perché abbiamo bisogno di così tanti database NoSQL diversi? Il motivo è semplice: diversi database NoSQL sono progettati per risolvere problemi diversi. Questo è il motivo per cui il numero di database concorrenti è così ampio. I database NoSQL rientrano in quattro categorie principali:

Banche dati orientate ai documenti

Questi database offrono la possibilità di archiviare documenti nidificati complessi, mentre la maggior parte dei database relazionali supporta solo righe unidimensionali. Questa funzionalità può essere utile in molti casi, ad esempio quando è necessario memorizzare nel sistema informazioni su un utente con più indirizzi. Quando si utilizza un database orientato ai documenti, in questo caso è sufficiente memorizzare un oggetto complesso che include un array di indirizzi, mentre in un database relazionale bisognerebbe creare due tabelle: una per le informazioni sugli utenti e una per gli indirizzi. I database orientati ai documenti colmano il divario tra il modello a oggetti e il modello dei dati. Alcuni database relazionali, come PostgreSQL, ora supportano anche l'archiviazione orientata ai documenti, ma la maggior parte dei database relazionali non dispone ancora di questa funzionalità.

Database chiave/valore

I database chiave/valore in genere implementano il modello NoSQL più semplice. In sostanza, ti forniscono una tabella hash distribuita , che ti consente di scrivere dati su una determinata chiave e rileggerli utilizzandola. I database chiave/valore sono altamente scalabili e hanno una latenza significativamente inferiore rispetto ad altri database.

Database grafici

Molte aree tematiche, ad esempio i social network o le informazioni su film e attori, possono essere rappresentate come grafici. Sebbene il grafico possa essere rappresentato utilizzando un database relazionale, è difficile e scomodo. Se sono necessari dati di grafici, è meglio utilizzare un database di grafici specializzato, che può archiviare informazioni sul grafico in un cluster distribuito e consente di implementare in modo efficiente algoritmi sui grafici.

Database colonnari

La differenza principale tra i database a colonne e gli altri tipi di database è il modo in cui i dati vengono archiviati su disco. I database relazionali creano un file per ogni tabella e memorizzano i valori per tutte le righe in sequenza. I database a colonne creano un file per ogni colonna nelle tabelle. Questa struttura consente di aggregare dati ed eseguire determinate query in modo più efficiente, ma è necessario assicurarsi che i dati rispettino le limitazioni di tali database.

Quale banca dati scegliere?

La scelta di un database è solitamente un problema frustrante e, con così tante opzioni disponibili, può sembrare un compito arduo. La buona notizia è che non è necessario sceglierne solo uno. Invece di creare un'unica applicazione monolitica che implementa tutte le funzionalità e ha accesso a tutti i dati di sistema, è possibile utilizzare un altro modello moderno chiamato microservizi : suddividere l'applicazione in un insieme di servizi indipendenti. Ogni servizio risolve il proprio problema ristretto e utilizza solo il proprio database, che è più adatto a risolvere questo problema.

Come dovresti imparare tutto questo?

Con così tanti database , impararli tutti può sembrare un compito impossibile. Buone notizie: non sei obbligato a farlo. Esistono solo alcuni tipi base di database NoSQL e se capisci come funzionano, gli altri saranno molto più facili da capire. Inoltre, alcuni database NoSQL vengono utilizzati molto più spesso di altri, quindi è meglio concentrare i propri sforzi sulle soluzioni più popolari. Ecco un elenco dei database NoSQL più comunemente utilizzati a cui penso dovresti dare un'occhiata:

1. MongoDB . Probabilmente il database NoSQL più popolare sul mercato. Se un'azienda non utilizza un database relazionale come archivio dati primario, probabilmente utilizza MongoDB. Si tratta di un'archiviazione di documenti flessibile con un buon set di strumenti. All'inizio della sua carriera, MongoDB aveva una cattiva reputazione per la perdita di dati in alcuni casi , ma da allora la sua stabilità e affidabilità sono migliorate notevolmente. Dai un'occhiata a questo corso MongoDB se vuoi saperne di più.


2. DynamoDB . Se utilizzi Amazon Web Services (AWS), faresti meglio a saperne di più su DynamoDB. È un database estremamente affidabile, scalabile e a bassa latenza con un ricco set di funzionalità e integrazione con molti altri servizi AWS. La parte migliore è che non devi distribuirlo da solo. La configurazione di un cluster DynamoDB scalabile in grado di gestire migliaia di query è a portata di clic. Se questo ti interessa, puoi dare un'occhiata a questo corso .


3. Neo4j . Il database grafico più comune. Questa è una soluzione scalabile e stabile adatta a coloro che desiderano utilizzare un modello di dati grafici. Se vuoi saperne di più, inizia con questo corso .


4. Redi . Mentre gli altri database qui descritti vengono utilizzati per archiviare i dati principali dell'applicazione, Redis viene utilizzato principalmente per implementare cache e archiviare dati ausiliari. In molti casi, uno dei database sopra menzionati viene utilizzato insieme a Redis. Per saperne di più, dai un'occhiata a questo corso.

Nel 2018 con NoSQL

I database NoSQL sono un campo vasto e in rapida crescita. Ti consentono di archiviare ed elaborare quantità di dati precedentemente inimmaginabili, ma questo ha un prezzo. Questi database non dispongono di molte delle funzionalità con cui hai familiarità nei database relazionali e può essere difficile configurarsi per utilizzarli. Ma una volta padroneggiati, è possibile creare database scalabili e distribuiti in grado di gestire volumi sorprendenti di richieste di lettura e scrittura, il che può essere estremamente importante quando vengono generati volumi di dati sempre più grandi. Originale: https://simpleprogrammer.com/guide-nosql-software-developers/