Sono passati i tempi in cui la gestione dei dati sembrava avere una e una sola soluzione: il classico database relazionale accoppiato a SQL.
Oggi, anche grazie alla diffusione dei microservizi, la scelta del database non è a priori ma è legata al tipo di applicazione che lo gestirà. in questo senso hanno preso largamente piede i document database, in cui le informazioni non sono strutturate in tabelle rigide ma in “documenti” dalla struttura generica rappresentati di solito in formato JSON.
Ai dati si accede via API, il che tra l’altro rende la gestione delle informazioni più in linea con i linguaggi programmazione e meno con quelli di gestione delle basi dati.
I document database hanno il vantaggio di essere veloci e scalabili, adatti ai canoni dello sviluppo moderno. E hanno qualche limitazione dal punto di vista dell’approccio classico: non supportano quasi mai SQL (fanno parte del mondo genericamente indicato come NoSQL) e demandano il controllo della consistenza dei dati alla logica applicativa.
Per molte applicazioni oggi questi non sono veri problemi, comunque.
Il mondo dei document database si è sviluppato molto negli ultimi anni. Comprende diverse piattaforme open source già molto apprezzate e alcune offerte commerciali, di cui contano in particolare quelle proposte dai grandi cloud provider perché sono integrate nativamente con gli altri loro servizi cloud.
MongoDB e RethinkDB
MongoDB è il document database più noto e diffuso. La versione open source contiene già le funzioni che servono in un ambiente di produzione, per andare oltre ci sono alcune versioni commerciali che aggiungono elementi anche importanti come il backup, la gestione dei dati in-memory, funzioni di analytics e il supporto alle query tipo SQL.
D’altro canto la sua popolarità ha portato in evidenza anche alcuni limiti che in parte sono dovuti alla natura stessa di document database e in parte a caratteristiche proprie di MongoDB che sono state migliorate solo nelle versioni più recenti. I punti deboli più spesso criticati riguardano la consistenza delle basi dati e la sicurezza nel controllo degli accessi.
Una piattaforma che invece nativamente cerca di garantire proprio la coerenza dei dati tra applicazioni distribuite è RethinkDB. Si tratta sempre di un document database, in cui però è stato integrato un meccanismo di notifiche che comunica in tempo reale le modifiche alla base dati a tutte le applicazioni collegate. Questo non vuol dire che il database nel suo complesso sia consistente in qualsiasi momento, ma semplifica molto lo sviluppo di applicazioni in real time.
Il mondo “couch”
Nei document database ci sono due filoni di sviluppo paralleli tra cui è facile confondersi: CouchDB e Couchbase. CouchDB è nato prima, Couchbase ha preso una parte del suo sviluppo, l’ha ampliata con altre tecnologie ed è diventata un prodotto piuttosto diverso.
CouchDB mantiene molte caratteristiche da progetto open source mirato. È assolutamente un document database, non ha troppi fronzoli e tralascia caratteristiche aggiuntive come il supporto a linguaggi di query tipo SQL.
Punta tutto sulla semplicità e sulla possibilità di gestire database CouchDB con qualsiasi linguaggio di programmazione. Uno dei suoi punti forti è un meccanismo di riconciliazione tra varie istanze di un database, che opera come un sistema di versioning. Questo significa però che l’allineamento tra le versioni non è immediato, il che può essere un limite.
Couchbase è più evoluto dal punto di vista delle funzioni utili ad applicazioni aziendali. Non è solo un document database ma sa gestire anche strutture key-value, ha nativamente funzioni di failover e replica dei dati, supporta un linguaggio di query (N1QL) simile a SQL. È insomma il document database ideale per chi non vuole allontanarsi troppo dal mondo tradizionale. Esiste in varie versioni commerciali e open source, più o meno complete.
L’offerta del cloud
AWS ha una sua versione di quasi qualsiasi cosa, in campo document database la sua offerta è DynamoDB. Il suo vantaggio è che libera gli sviluppatori da qualsiasi preoccupazione su ciò che sta “sotto” il database: c’è solo da definire la quantità di storage dedicata e a tutto il resto, dal provisioning dei server in poi, ci pensa AWS. Conta anche l’integrazione con altri elementi di AWS, dalla parte di programmazione con ad esempio la parte serverless di AWS Lambda a quella di analisi dei dati memorizzati.
La risposta di Google a DynamoDB è Firebase Realtime Database, un prodotto che Big G ha acquisito qualche anno fa con Firebase e che ha man mano trasformato in una parte di uno stack di sviluppo. Non è più quindi un prodotto pensato per esistere in modalità stand-alone, serve soprattutto per la gestione dei dati da parte di app mobili che non sono costantemente connesse al cloud. Anche per questo può essere gestito da tutti i principali linguaggi di sviluppo: C++, Java, Python e via dicendo.
In casa IBM c’è da segnalare Cloudant, che si può considerare come una versione cloud di CouchDB arricchita con alcune funzioni. Alcune sono state anche portate al progetto open source di CouchDB, come ad esempio il supporto alle query via Mango, e altre invece no, come le funzioni native per la ricerca testuale. Di Cloudant esiste anche una versione da installare on-premise – Cloudant Local – pensata però come estensione del servizio cloud.
