SQL è di gran lunga il linguaggio più utilizzato per interrogare i DB. Ed è anche relativamente facile da imparare e le strutture dei DB SQL sono conosciute un po a tutti. Ma i database tradizionali come Oracle o MariaDB (giusto per fare un paio di esempi) hanno una scalabilità relativamente limitata e consumano la maggior parte delle loro risorse a garantire la consistenza delle transazioni… cosa, che spesso è meno necessaria di quanto si creda.
Inoltre, questo lo dico sempre, la quantità di dati che stiamo generando è tale che, indipendentemente dal tipo di azienda/organizzazione, dobbiamo tutti pensare a dei nuovi sistemi per gestire i dati che siano più scalabili.
La consistenza dei dati
Per quanto per alcuni tipi di dati la consistenza della transazione (strong consistency) sia fondamentale (es. un ERP o DB che gestisce transazioni commerciali) esistono molte applicazioni che si possono accontentare di situazioni di eventual consistency.
Il termine eventual consistency lo si ritrova spesso nei sistemi distribuiti dove si privilegia l’alta affidabilità e la scalabilità rispetto alla consistenza della singola transazione. In pratica, semplificando al massimo, se aggiorno un dato più volte, e poi lo rileggo immediatamente, non posso essere sicuro di leggere l’ultimo update (almeno fino a quando l’update non è stato propagato/replicato correttamente ai vari nodi).
Un approccio a volte criticato perché può essere necessario scrivere applicazioni più complesse per gestire questo problema ma che comunque garantisce una velocità e una scalabilità decisamente superiore.
La scalabilità
Certo è che se si devono gestire una grande quantità di dati e questi vengono utilizzati principalmente in lettura (come un Data Warehouse per esempio), caricamenti e letture dei dati possono sicuramente essere fatti in parallelo e in molti casi la superiore velocità del DB permette di non dover fare particolari cicli di preparazione dei dati prima di interrogare il DB. Inoltre, siccome la maggior parte dei sistemi NoSQL sono distribuiti (cluster con più nodi), basta aggiungere ulteriori nodi se necessario.
Mille NoSQL
Al contrario di quello che succede nel mondo SQL, con un mercato già decisamente consolidato da anni, di DB NoSQL ce ne sono tantissimi e molti di questi hanno anche caratteristiche che sono difficili da confrontare con altri. Fortunatamente però molti di questi sono basati su prodotti open source e, in alcuni casi, utilizzabili anche senza dover acquistare licenze (e/o supporto).
Un esempio? Due settimane fa, ho incontrato Basho, azienda che ha un DB NoSQL chiamato Riak. Il loro mercato di riferimento è targettato abbastanza in alto come tipo di clienti ma hanno saputo mettere in piedi una comunità di sviluppatori molto ampia e il prodotto esiste sia in versione open source che a pagamento. Inoltre hanno appena annunciato una piattaforma basata sul loro prodotto per la gestione di grandi mole di dati (Big Data). Una soluzione interessante, probabilmente non proprio per tutti… ma interessante.
NoSQL piace
Per quanto sia un’altra cosa da imparare (e comunque chi non continua ad imparare nel nostro settore può solo andare indietro…), NoSQL piace a tutti quelli che ci si avvicinano. Gli sviluppatori sono attratti dalla semplicità con cui possono scrivere il codice e dalla libertà di organizzare i dati mentre i sistemisti sono molto attratti da architetture innovative che gli permettono di garantire up-time molto elevati, cicli di upgrade rapidi e prestazioni elevate con meno hardware di quello che è necessario per soluzioni simili basate su DB tradizionali.
Certo, è tutto troppo “facile” e quindi è facile anche fare i danni… ma qui, come al solito, è l’esperienza e il training che fa la differenza.
Nota finale
Come al solito il mio consiglio è quello di investire. A tutti i livelli, come sviluppatori, come SysAdmin, come aziende. La quantità e la qualità di applicazioni possibili è in costante aumento e i dati da gestire sono sempre di più. Anche se non è per oggi, farsi trovare pronti quando sarà necessario farà la differenza e ripagherà gli investimenti.
Basho, ad esempio, ha un sacco di documentazione gratuita sui propri siti e, in questo caso, l’investimento è più in termini di tempo che di denaro. Se poi è necessario installare un cluster per far le prove basta istanziare un po di VM in un cloud pubblico a scelta (io uso Digital Ocean per queste cose, si parte da $5/mese per VM!)
Ultima nota (per i CIO) , forse la più importante. Se per anni si è tentato di eliminare gli sviluppatori interni all’azienda (soprattutto nelle piccole e nelle medie), oggi c’è un trend diverso. Molti, anche per via del fatto che parte del business si sta spostando velocemente sul web e su device mobili, stanno cercando di riportare in casa degli sviluppatori per avere un controllo migliore sulla qualità delle applicazioni (spesso fatte ad hoc) e, di conseguenza, sull’esperienza d’uso dei propri utenti/clienti.
Disclaimer: Sono stato invitato a questo meeting da Condor Consulting Group e loro hanno pagato per il viaggio e l’alloggio. Non sono stato ricompensato in alcun modo per il mio tempo e non sono in obbligo di scrivere articoli. In ogni caso, i contenuti di questi articoli non sono concordati, rivisti o approvati dalle aziende menzionate o da altri al di fuori del team di juku.
