A differenza dei DB relazionali, che possono vantare mezzo secolo di vita, un uso diffuso e massiccio, spesso a supporto delle "applicazioni mission critical" delle organizzazioni, i DB NoSql sono relativamente giovani: la nascita delle principali soluzioni oggi disponibili risale mediamente ad una quindicina di anni fa.

Ma forse sarebbe più giusto dire che stanno rinascendo in questi ultimi anni, vediamo perchè.

A dispetto del claim NoSql, che Carlo Strozzi coniò per indicare l'orientamento Not Only Sql, a voler evidenziare un distacco dal modello relazione, l'interpretazione comune che ne derivò fu di DB che non usavano il linguaggio di interrogazione dei dati tipico del DB relazioni, lo Structured Query Language, SQL in sigla, determinando una categorizzazione totalmente fuorviante.

Un per l'altro dei molti prodotti oggi disponibili, il fattore comune è l'assenza della definizione dello schema dati, croce e delizia dei DB relazioni ed elemento di disputa a 'mo di Guelfi e Ghibellini tra chi lo ritiene un modello imprescindibile per garantire il giusto rigore (governance?) sui dati, e chi al contrario (e noi siamo tra quelli), lo ritiene un vincolo ancestrale che oggi non ha nessuna ragione per sussistere. Vediamo perché.

Il modello relazionale nacque per risparmiare spazio disco, perché era molto costoso, mentre i costi computazionali che ne derivavano (applicazioni batch) erano assai più contenuti.

Oggi lo spazio disco costa veramente poco, ma le applicazioni (spessissimo) devono rispondere in tempo reale ad un utente in attesa, quindi il costo computazionale cresce in misura correlata con la velocità di risposta: in questo contesto, sprecare tempo a rimettere insieme i dati sparpagliati in tanti frammenti non solo è un non sense, ma non potrà mai eguagliare le prestazioni di una soluzione che i dati li ritrova pronti in un "colpo solo".

Se poi a questo aggiungiamo il diverso orientamento dei nuovi dati raccolti e gestiti, non più per soli fini operativi (amministrativi, di supply chain, fulfillment, ...) ma a supporto e sviluppo del business (una migliore e possibilmente personalizzata UX dei clienti, loyalty, omnichannel touchpoint, AI suggestion, ...), lo scenario è completo: i DB relazioni, per loro struttura intrinseca, scarsa o nulla scalabilità orizzontale, rigidità ed anche il costo, non sono la scelta più proficua.

Queste sono le ragioni che hanno orientato la nostra strategia di posizionamento dei nostri servizi di supporto alla progettazione ed al delivery di soluzioni Data Intensive, come quelle orientate alle problematiche di:

• IoT Data Management,

• CustomerView360,

• Field Services,

• Content Management Systems

che ci hanno portato a selezionare quello che a nostro avviso è il miglior prodotto sul mercato in grado non solo di coprire tali necessità, ma di completarle con soluzioni orientate a:

• edge & mobile

• analytics

racchiudendo in un unico prodotto quanto serve a realizzare progetti ambiziosi nella declinazione più moderna ed attuale che possiamo dare al concetto di mission critical, ovvero:

Stiamo parlando di Couchbase, Multicloud to Edge NOSql Database.

Questo uno dei più frequenti schemi di posizionamento all'interno dei sistemi aziendali: