SQL & NoSQL

SQL & NoSQL

Nove brevi articoli su argomenti parecchio in auge negli ultimi anni, per i quali, nel corso dell’evolversi tecnologico, i concetti, le definizioni ed i limiti gradualmente svaniscono e risulta a volte confuso spiegare “chi è chi” in modo abbastanza semplice.

SQL & NoSQL

La frase attribuita ad Einstein "Non capisci veramente qualcosa finché non puoi spiegarlo a tua nonna", ha una variante che utilizza un bambino di 6 anni al posto della nonna, ma, visto che si parla di tecnologia, adotterò la prima.

Definizione
Un modo semplice e comprensibile per spiegare la differenza tra un database SQL e un database NoSQL potrebbe essere quello d'immaginare di dover fare una torta: il punto di partenza è senz'altro il libro delle ricette.

NoSQL è come il libro delle ricette, si può passare ad una pagina e trovare tutti gli ingredienti necessari in un unico posto.

Dall'altra parte, SQL è come acquistare i singoli ingredienti, passando nelle diverse corsie del supermercato per raccoglierli uno ad uno.

Terminando qui la spiegazione, si potrebbe obiettare che NoSQL sia migliore e quindi chiedersi perché non lo utilizzino tutti.

In un negozio organizzato per ricetta, il latte potrebbe essere venduto in 50+ luoghi diversi, moltiplicando le ripetizioni sia. ad esempio, per il latte che per le unità di refrigerazione, che comporta ovviamente uno spreco di denaro e risorse.

DOCKER

Si sente molto parlare di Docker e, dando un'occhiata più da vicino al logo, si ha già l'indicazione di cosa si tratta: è una balena atteggiata a bastimento che trasporta container.

Un container Docker è proprio come un container di spedizione (contiene un'app) e il server o la macchina virtuale su cui Docker è in esecuzione è come la barca.

I contenitori Docker sono utili perché dopo aver configurato il proprio container (app) come si desidera, può essere spedito su QUALUNQUE barca (server) con QUALUNQUE altro container (app).

A titolo di esempio si può immaginare di voler spedire bibite (app front-end) e pizze surgelate (app back-end). Senza Docker si necessita di due barche dato che non si vogliono congelare le bibite. Ma due barche significano un doppio lavoro di configurazione e il doppio dell'overhead (sistema operativo). Con Docker si possono collocare (le app) in contenitori separati e spedirle insieme su QUALUNQUE barca.

API

Per spiegare cosa è un'API si può immaginare di essere ad un ristorante e di sedersi ad un tavolo.

In questo scenario il cameriere è l'API.

Quando si sceglie qualcosa dal menu (che è la documentazione API) questa deve essere in qualche modo inviato alla cucina (che è il database).

Qui entra in scena il cameriere il quale si assicura che ciò che si è ordinato sia effettivamente presente nel menu (questo è chiamato convalida dei dati), successivamente va in cucina e ritornano con la risposta (che è il cibo) sulla tavola.

Si potrebbe obiettare come mai si ha bisogno dell'API, visto che si potrebbe andare in autonomia direttamente in cucina a prendersi il cibo.

Le API riducono la complessità. Senza un cameriere (API), sarebbe necessario conoscere l'organizzazione e la struttura dell'intero ambiente, qual è il proprio cibo, impiattarlo e poi riportarlo sul proprio tavolo. Di gran lunga è meglio che tutto ciò lo faccia il cameriere (API).

WEBHOOK

Si legge e sente spesso, guardando le API di una piattaforma (social come Instagram, oppure sistemi di pagamento come Stripe) che si possono ricevere dati utilizzando i webhook.

Per capire di cosa si tratta, si può immaginare di trovarsi in un negozio di calzature e ci si innamori di un paio di snickers, ma, purtroppo, la propria taglia è andata esaurita.

Una soluzione è quella di tornare al negozio ogni giorno per domandare se la scarpa (risorsa) nella taglia desiderata è tornata disponibile o meno. Questo si chiama polling.

Un modo più efficiente per farlo è invece quello di, semplicemente, lasciare il proprio indirizzo al negozio e dire loro di inviarlo direttamente a casa non appena ritornerà disponibile.

Questo è ciò che fa un webhook. Non appena la risorsa sarà disponibile, la invierà all'indirizzo richiesto senza che si debba richiederla continuamente.

RICORSIONE

Per capire cosa si intende con ricorsione, si suppone di essere in fila al furgone dello street food per comprare il panino preferito, ma non si possono vedere quante persone ci sono nella fila.

Per saperlo, un metodo è quello di andare all'inizio della fila e contarle, ma si suppone di essere affamati e non c'è modo di lasciare il posto in fila, se non perdendolo.

L'alternativa è chiedere alla persona di fronte "Quante persone ci sono davanti a te?".

Probabilmente risponderà con "Non lo so, ma chiederò alla persona davanti a me".

Questo modello ripetuto è chiamato ricorsione e il processo continuerà fino a quando la domanda non raggiungerà la persona che si trova all'inizio della fila che, una volta raggiunta, risponderà "Non c'è nessuno davanti a me!"

Questo è il caso base, o dove finisce la ricorsione, quindi, ogni persona si gira e dice alla persona dietro quante persone si trovano davanti sommando 1, fino a quando la risposta non torna a chi l'ha posta.

CACHING

Dove si ripongono le cose a casa propria? Di solito in magazzino, garage o solatio.

Possiamo paragonare ciò all'archiviazione dei dati sul disco rigido, ha un basso costo di archiviazione poiché c'è molto spazio.

Ha però un costo elevato per il recupero, soprattutto se abiti al terzo piano e sei comodo e rilassato nel tuo soggiorno.

Un altro luogo dove poter conservare le cose che si utilizzano più spesso è probabilmente il proprio armadio o il ripostiglio di casa.

Archiviare le cose nell'armadio è come archiviare i dati nella RAM o nella memoria (cache).

È molto veloce accedervi, ma lo spazio è limitato. E questo è esattamente ciò che è il caching: archiviare i dati usati più spesso in una posizione di accesso più veloce, per risparmiare tempo.