Cosa sono i database NoSQL

Disamina sui DB NoSQL per capire che sono e a cosa servono.

In the last years we follow the rising of NoSQL technology and its employ in a even more extended set of application. This article aim to make an objective comparison from SQL and NO-SQL technology and try to clarify some unclear aspect to help people to choose it’s backend knowledgeably.

Negli ultimi anni abbiamo assistito all’evoluzione della tecnologia NoSQL e all’impiego in un numero sempre più vasto di applicazione. Questo articolo vuole essere una confronto oggettivo tra SQL e NoSQL al fine di chiarire gli aspetti meno chiari, eliminare ogni pregiudizio verso le nuove tecnologie e aiutare nella scelta.

Cosa è NoSQL

In parole semplici, NoSQL è un sistema di memorizzazione dei dati che non segue un modello relazionale. Stiamo parlando di un contenitore di dati che lavora in maniera differente da un qualunque motore SQL tradizionale.

Le tecnologie NoSQL nascono per coprire un set di necesssità che i tradizionali sistemi NoSQL faticano a soddisfare. Queste tecnlogie, comparate alle tradizionali, sono più giovani ma ormai mature per essere prese in considerazione anche in ambito aziendale.

Ma quali sono queste necessità e in quali ambiti applicativi possiamo valutare una soluzione NoSQL?

 

  • Applicazioni che lavorano con un grande volume di dati. (Big Data)
  • Applicazioni che lavorano con dati soggetti a cambiamento nella struttura o dinamismo (semi-structured, unstructured and polymorphic data, come ad esempio le basi dati che implementano un modello EAV).
  • Sviluppatori in un team ristretto che adottano un approccio agile.
  • SaaS application o prodotti, che magari richiedono by design clustering e distribuzione dei dati
  • Applicazioni con un alto numero di utenti, rispetto alle poche centinaia di un applicazione in ambito aziendale
  • Incertezza sul futuro dell’applicazione. Oggi è utilizzata da pochi utenti e contiente pochi dati ma domani potrebbe dover scalare rapidamente.

Ci sono molte soluzioni NoSQL offerte dal mercato, opensource o meno. Onguna di esse lavora in maniera leggermente diversa, specializzata su una specifica esigenza. Il principio di fondo e la caratteristica preponderante è la scalabilità e le performance. Questi risultati sono ottenuti rinunciando ad aclune caratteristiche tipiche dei RDBMS, e introducendo altre funzionalità.

 

Implementazioni NoSQL

Uno dei principali breaking changes rispetto ai database tasizionali e che, mentre questi sono degli strumenti general purpose, i sistemi NoSQL sono concepiti per ospitare una determinata tipologia di dati. Questa specializzazione  consente di essere molto più efficienti su un determinato ambito e garantire performance anche con moli di dati enormi. Questa caratteristica ci suggerisce che per raggiungere le specifiche applicative potrebbe essere necessario adottare più di un sistema NoSQL e farli lavorare insieme, magari in sincronia con un sistema database tradizionale.

Document-oriented

Questo tipo di database ricorda più degli altri il classico RDBMS, in quanto memorizza dei documenti in apposite collezioni. Consideriamole come righe e tabelle, fatta eccezione per il fatto che ciascun elemento della collezione (documento) può avere campi diversi e non definiti a priori (polimorfismo). Questo tipo di contenitore è utilissimo per dati che hanno una struttura variabile o non predeterminabile, come quelli memorizzati tramite pattern EAV su RDBMS.

  • Goal: Memorizzare grandi quantitativi di dati senza una struttura predefinita
  • Examples: MongoDB, CouchDB
  • Target: Heterogeneous data, working object-oriented, agile development

Graph databases

Abbiamo detto che i NoSQL rimuove il concetto di relazione per ottenere prestazioni migliori. In questa famiglia di database, invece, questo concetto è rafforzato per riuscire a rappresentare grafi di dati. Questi sistemi servono dove le relazioni tra dati sono più importanti del dato stesso.

  • Goal: describe data relations
  • Examples: Neo4j, GiraffeDB.
  • Target: Data Mining

Key-Value Stores

Questo tipo di db è concepito per memorizzare dati in forma chiave-valore, come per sistemi di cache, traduzioni, proprietà o sessione utente.

  • Goal: Store data in key-value form
  • Examples: Redis, Cassandra, MemcacheDB
  • Target: key-value storage

 

Vantaggi delle piattaforme  NOSQL

 

E’ scontato che, per come sono costruiti, i sistemi  NoSQL db presentino alcuni vantaggi interessanti e possano risolvere facilmente problemi che il tradizionale RDMS non è in grado di risolvere. Il loro ampio impiego in sistemi critici, come i sistemi  in cloud e alcuni prodotti Saas di grandi dimensioni, conferma che sono maturi e utilizzabili. Ma la domanda è: perché dovrei cambiare? E in questo caso, quando la mossa è redditizia? Non possiamo basare questo tipo di decisione solo sulle nostre impressioni o fidarci di qualche articolo interessante letto su internet. Sappiamo bene che non è tutto oro quello che luccica ed è logico essere diffidenti. Però, non possiamo nemmeno ostacolare il progesso per evitare i disagi rispetto al cambiamento. In questo capitolo cercherò di spiegare perché è conveniente passare a NoSQL e in quali casi.

Come abbiamo detto, i database NoSQL sono stati creati in risposta ai limiti della tecnologia di database relazionale tradizionale.

I vantaggi dei sistemi NoSQL consistono nel gestire facilmente:

  • Big data:  insiemi di dati di dimensioni enormi.
  • Mutable data: Dati che possono variale costantemente nella struttura e che by-design presentano caratteristiche diverse elemento per elemento (EAV)
  • Dynamic development:  Contesti in cui il team di lavoro ha bisogno di estrema flessibilità e dinamismo.
  • Object-oriented: Contesti in cui tutti gli utilizzatori del dato lavorano ad oggetti
  • Expandable: Possibilità di espandere l’applicazione costantemente ed in maniera responsiva.
  • Open Source: la maggior parte delle soluzioni sono opensource o senza costi di licenza.

In sintesi:

I database NoSQL sono più scalabili e garantiscono migliori performance, avvicinando il modello dati al dominio applicativo. Oggi, le aziende che iniziano un progetto nuovo, trovano nel NoSQL un’alternativa valida e allettante per un ampio set di applicazioni. Non considerare questa soluzione significa perdere un’opportunità e forse compromettere il progetto stesso.

 

Limitazioni di  NO-SQL

In questo capitolo sono riepilogate alcune funzionalità che potresti perdere utilizzando una soluzione NoSQL. Nel valutare i limiti dei database NoSQL, è importante ricordare che il mondo NoSQL è una costellazione di prodotti diversi. Non tutti i prodotti di NoSQL sono soggetti alle stesse limitazioni e sicuramente non nella stessa misura. Tuttavia ci sono dei punti deboli comuni di cui tener conto. Questo non vuole essere un modo per screditare la soluzione NoSQL, consideralo una checklist per capire quanto perderebbe la tua applicazione abbandonando i DB tradizionali.

Sicurezza

La sicurezza è un requisito importantissimo quando si parla di dati, i sistemi NoSQL sono sicuri? Da un punto di vista funzionale, adottare un db NoSQL invece che tradizionale non impatta minimamente sulla sicurezza. Quello che può cambiare, invece, è il livello di maturità delle piattaforme che usiamo e l’abilità dei sistemisti nel gestirle. I db tradizionali sono nel mercato dagli albori dell’espansione informatica che le aziende stanno vivendo e do per scontato che i sistemisti ne conoscano vita morte e miracoli, anche in termini di gestione e sicurezza. I sistemi NoSQL, anche se maturi, sono relativamente nuovi e ancora poco diffusi, quindi non posso essere altrettanto ottimista. In  questo caso suggerisco di  adottare una soluzione NoSQL con un vendor forte alle spalle, che permette di avere (pagando) tutta la consulenza necessaria.

Data Consistency & Tricky transactions

Una delle prime cose che ci hanno insegnato sui db è stato che le transazioni ACID sono la miglior soluzione per gestire una sequenza di operazioni sui dati. Bene, anche se questa è davvero una soluzione ottima per garantire la consistenza dati, praticamente nessun sistema NoSQL la implementa. Il principio di fondo dei db NoSQL è l’ Eventual consistency , in pratica un approccio molto ottimista che accoglie il rischio del’inconsistenza in cambio di un considerevole aumento di performances. La domanda è: sareste disposti ad accogliere il rischio di inconsistenza durante una transazione finanziaria? Preferite la certezza che vi venga addebitato il giusto importo quando ritirate al bancomat, o sareste disposti ad accettare un errore per velocizzare l’operazione? Questo esempio vi fa già capire che ci sono casi in cui la consistenza del dato è più importante delle performance.

Implementazioni come FoundationDB permettono transazioni ACID-like e performance comparabili con gli altri sistemi NoSQL, tuttavia in generale il tema della consistenza dei dati rimane un aspetto critico e va analizzato bene in base al contesto applicativo.

JOINs

Tra tutte le differenze tra NoSQL e RDBMS la più evidente è la mancanza di relazioni. Oltre che per gli aspetti funzionali legati alle performance, proprio per un discorso di esperienza nello sviluppo. Infatti, la progettazione della base dati, lo sviluppo applicativo e il nostro modo di pensare i dati è molto legato alle relazioni tra tabelle. Questa rimozione, è una vera e propria rivoluzione perché non significa “abolire” le foreign key, ma ripensare i dati in maniera differente. Perché ? Partiamo dal fatto che le JOIN non esistono più. O meglio, ci sono,  ma sono difficili da usare, poco potenti e vanno lente. Dobbiamo quindi  limitare l’uso delle lookup introducendo nuovi pattern applicativi, spesso replicando i dati. Pensa ad un catalogo prodotti con categorie, sottocategorie e prodotti. Per non fare la join possiamo replicare i dati della categoria sul prodotto. Che succede se cambio l’alberatura delle categorie? In un RDBM con un’update sulla singola riga altero le relazione e cambio il significato di tutti i dati. In un NoSQL, dove per comodità ho replicato i dati delle categorie nei prodotti, dovrò eseguire un update massivo che coinvolge tutti i prodotti legati alle categorie modificate. In parole povere, la velocità nell’accesso ai dati si ripaga nella modifica.

Assenza di standard tra tecnologie diverse

SQL è un linguaggio standard. Ci sono tanti dialetti, diciamo uno per vendor, ma alla radice c’è uno standard comune che li accomuna tutti. Questo fattore coumune è un elemento molto utile per tutto quello che c’è costruito sopra, ad esempio l’accesso astratto ai dati. Pensiamo ad esempio ai vari ORM  Hibernate, NHibernate, Doctrine, Entity Framework. Questo standard ha aiutato anche la diffusione di sistemi di gestione dei dati multi database, strumenti di integrazione dati e reportistica che supportano pressappoco tutte le basi dati. Bene, su NoSQL non ci sono standard di base ma tante implementazioni differenti. Questo rende molto difficile la realizzazione di un sistema di accesso ai dati indipendente dalla soluzione e strumenti di integrazione dati. In pratica, la scelta del prodotto è ancora più vincolante e deve tener conto non solo di “come funziona” ma anche dei tool e delle capacità di integrazioni con altri sistemi, che in genere diamo per scontato.

La flessibilità dello schema dati può diventare un cappio al collo

Abbiamo detto che i sistemi NoSQL non hanno relazioni e permettono uno schema variabile non predefinito. Fantastico, non abbiamo vincoli. Però non abbiamo nemmeno un posto dove andare a vedere come i dati dovrebbero essere strutturati. Certo, potremmo verificare la documentazione… Siate sinceri, quante volte vi è capitato di dover fare reverse engineering dalla struttura del db per capire cosa scrivere su un db? Beh, questo non lo potrai più fare. Inoltre, qualunque dato che inserisci viene accettato. Ad esempio se sbagli a mappare il nome del campo, creerai proprietà diverse da quelle previste sui documenti.  In caso di bugs è molto difficile riuscire a risalire all’errore. Documentare la business logic diventa fondamentale perché a distanza di tempo non c’è modo di capirla, se ci siamo dimenticati come doveva essere strutturato il dato. Mettiamo quindi in conto di dedicare più tempo alla documentazione e farla in maniera sistematica.

Analytics

La parte di reportistica è basata su funzionalità tipiche del RDBMS come SUM, COUNT, e JOIN. Tutte caratteristiche che sui sistemi NoSQL non ci sono o sono emulate in maniera non abbastanza efficace. Inoltre le differenti strutturazioni dati derivanti dall’assenza di relazione impediscono di effettuare query strutturate come faremmo di solito. La parte di analisi dei dati è uno dei punti più critici per i sistemi NoSQL. La soluzione migliore è quella di replicare i dati in un sistema relazionale, magari non in tempo reale, portando il dato ad una forma adatta per essere interrogato dai tradizionali sistemi di reportistica.

Pochi strumenti NoSQL

Per i motivi già elencati (tecnologie nuove, mancanza di uno standard condiviso)

We spoke about the lack of standardization on NoSQL query language and syntax. This problem may be reflected also in tools, together with youngness of most platforms. I’m speaking about tools for querying, but also for migrate data between database, manage backup etc..
Of course, most of NoSQL project are growing, and we expect tools will grow with them, so this problem will be automatically solved in the near future.

The lack of standardization makes hard for third party vendors build tools that can support multiple NoSQL solution. Moreover young platforms means less users, less customer, and less time to develop mature tools.

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento