Così come i linguaggi di programmazione Object Oriented hanno quasi completamente sopraffatto quelli procedurali, per lungo tempo si è pensato che i Database Object Oriented OODBMS fossero destinati a prendere il posto di quelli relazionali.
La storia di questi database inizia alla fine deli anni ‘80 e trova tra i suoi protagonisti Won Kim ed il suo progetto ORION.
Won Kim
Tra i principali vantaggi degli OODBM troviamo: ereditarietà, poliformismo, templates, e clustering individuale degli oggetti, tutti elementi noti al mondo della programmazione ad oggetti.
In realtà questa tipologia di DB ha sempre incontrato grandi difficoltà nella propria diffusione, in primis la mancanza di una versione standardizzata di OQL (Object Query Language, l’omologo si SQL) che obbliga gli utilizzatori ad imparare un nuovo “dialetto” e a riscrivere buona parte del codice in caso di sostituzione dell’OODBMS. Inoltre le vari implementazioni sono tutt’altro che affidabili e non sempre le interrogazioni rispondo nel modo atteso.
Esiste anche un discorso “concettuale” legato al fatto che quando un oggetto non è presente in memoria, in sostanza, smette di essere un oggetto e i suoi attributi vengono visti in modo naturale come elementi da memorizzare in una forma tabellare, sfruttando le capacità di aggregazione ed elaborazione dei dati dei classici sistemi relazionali.
Per cercare di superare parte di questi limiti, nel 1989 viene istitutio l’ Object Management Group (OMG) con l’obiettivo di standardizzare lo sviluppo e le funzionalità (in particolare OQL) degli OODBMS e il cui ultimo lavoro è lo standard ODMG 3 rilasciato nel 2001.
Versant e O2 sono sicuramente tra gli OODBMS più noti, oltre alle soluzioni ibride chiamate ORDBMS che permettono di memorizzare i dati o come oggetti o come tabelle, cercando di sfruttare le peculiarità sia degli OODBMS che degli RDBMS.
Sempre nel campo delle soluzioni evolutive/alternative agli RDBMS, una proposta anch’essa passata negli anni in secondo piano è quella dei database basati su XML e sui linguaggi di interrogazione XQuery e XPath. In realtà questo tipo di sistemi sono nati sotto la spinta di utilizzare un linguaggio di mark-up universale e indipendente a tutti i costi, portando però a soluzioni poco performanti, espansive (ogni singolo elemento richieste una serie di tag descrittivi), e senza nessun controllo sugli accessi ai dati e sulla loro consistenza.
La GUI di BaseX 6.6, uno dei database XML based più noti
Al contrario quello che invece sembra la nuova linea evolutiva dei database è identificabile sotto il cappello NoSQL o anche NRDMBS. Si tratta di sistemi concepiti in modo diametralmente opposto a quelli relazionali e che devono la propria denominazione all’italiano Carlo Strozzi, già presidente dell’Italian Linux Society, che conia il termine nel 1998 per indicare il proprio progetto inerente un piccolo database non relazionale.
Carlo Strozzi
Nel 2000 un contributo fondamentale ai sistemi NoSQL arriva da Eric Brewer, che, in un KeyNote alla conferenza “Principle of Distributed Computing”, presenta il CAP Theorem relativo all’utilizzo delle basi dati in ambito distribuito. Ogni lettera di CAP sta a rappresentare una caratteristica del sistema distribuito su cui si sta lavorando:
- Consistency (Consistenza): tutti i nodi del sistema distribuito devono riflettere le modifiche effettuate;
- Availability (Disponibilità): il sistema è sempre in grado di rispondere alle richieste, risultando praticamente sempre operativo;
- Partition Tollerance (Tolleranza al Partizionamento): anche se la comunicazione si interrompono tra due punti del sistema, il sistema deve comunque continuare ad essere raggiungibile.
e di queste, secondo il teorema, se ne possono avere contemporaneamente valide solo 2, potendo scegliere quali prediligere in base alle proprie necessità.
La prima società ad abbracciare questo “mondo” è Amazon grazie all’intuito del suo CTO Werner Vogels che, basandosi sul white paper redatto da Seth Gilbert e Nancy Lynch nel 2002, avvia il progetto interno noSQL SampleDB (sviluppato in Erlang). Wogels sceglie di prediligere i fattori AP, sacrificando la Consistenza dei dati e introducendo il concetto di “eventualmente consistente”, ovvero la propagazione ritardata delle informazioni a tutti i nodi.
Le soluzioni NoSQL sono oggi alla base di quasi tutte le grandi web application: dall’App Engine Data Store di Google fino ad arrivare a Cassandra utilizzato da Facebook e Twitter e sviluppato dalla Apache Software Foundation che cura anche CouchDB.
Con gli NRDBMS è possibile memorizzare un elemento atomico, con tutte le informazioni rilevanti, senza dover ricorrere ai costosi (in termini computazionali) join per aggregare i dati e senza spreco di spazio dovuto a campi non significativi. Un altro punto di forza è, inoltre, la possibilità di scalare orizzontalmente il sistema, aggiungendo nuovi nodi ai cluster senza provocare alcun blocco operativo unitamente al fatto che questo tipo di storage si adatta particolarmente allo sviluppo di applicazioni object oriented abbattendo la necessità di realizzare livelli di mapping/scambio dati.
Ma ance i NoSQL hanno i propri limiti e il principale è la mancanza dell’integrità dei dati. Infatti non esistendo relazioni (in senso stretto), il sistema non può garantire che le operazioni effettuate mantengano in uno stato consistente le informazioni esistenti. Questo sposta al livello applicativo tutti i controlli necessari, trasformando di fatti l’NRDMBS in uno storage altamente flessibile ma sostanzialmente “poco intelligente” (come piace al sottoscritto).
In conclusione è doveroso precisare che con “NoSQL” si identificano famiglie di storage molto differenti tra loro: Column Family, Document Store, Graph Database e Key-Value Stores,, ognuna con caratteristiche esplicitamente pensate per ambiti ben precisi.
Famiglie NoSQL
Si chiude così il nostro viaggio attraverso l’evoluzione dei database che non mancherà in futuro di riservarci straordinarie innovazioni. Come sempre ringrazio tutti i lettori e un arrivederci al prossimo viaggio nella storia dell’informatica.
Anche questa parte è stata molto interessante, non conoscevo l’origine della nuova generazione di DB non relazionali.
Un appunto, però, sul discorso “Eventual consistency”. In inglese “eventual” significa che alla fine, prima o poi, qualcosa accade. Il che è sottilmente differente dall’italiano “eventualmente” che indica la possibilità o meno che accada un evento.
Visto, però, l’ambito in cui viene usato, credo la distinzione sia sostanziale. Scusate la lezioncina :-)
ahh adesso mi è piu chiaro come diavolo faccia Facebook a scalare anche con l’utenza che si ritrova, mi sembrava impossibile che riuscisse a stare in piedi su un db relazionale!
Non si parla mai dei database historian. Perché? Eppure in ambito industriale sono assai usati anche se ignoti al grande pubblico.
Io non parlerei di NoSQL in termini di evoluzione dei database. Per quanto mi riguarda sono un altro ramo che s’è creato nell’ambito della memorizzazione e interrogazione dei dati.
DB relazionali e non hanno entrambi punti di forza e di debolezza, e vanno scelti in base ai requisiti che bisogna rispettare.
Io preferisco nettamente i db relazionali e con parecchia logica spostata dentro i server. La consistenza dei dati è per me il requisito più importante da soddisfare (spesso; non sempre), oltre al fatto che preferisco dei tiny client con poca logica, al contrario di fat client che devono occuparsi della logica col problema non indifferente della manutenibilità e della propagazione “coerente” degli aggiornamenti al codice (che si devono tenere in conto, perché… capitano. E sovente).
Ciò non toglie che, nel caso in cui dovessi ravvisarne la necessità, non avrei problemi a impiegare qualche db NoSQL.
Insomma, cerco si sfruttare il meglio delle tecnologie a disposizione, come poi dovrebbe essere.
Spotify ne è un esempio: usano PostgreSQL dove serve la consistenza dei dati, e Cassandra per la scalabilità. ;)
Per esperienza in un grosso progetto i NoSQl non sono sempre una scelta cosi’ intelligente. Anzi, a noi ha dato piu’ problemi che vantaggi. Il caro Cassandra si e’ rivelato una spina nel fianco enorme con limiti devastanti, nonostante si fosse pianificato il suo uso con ben tre mesi di analisi.
Conoscevo l’esistenza dei DB non relazionali, ma onestamente mi sfugge un po’ il senso.
Un DBMS relazionale mi permette la “relazionalita’”, ma non la obbliga di certo, e’ il DB che puo’ o meno sfruttarla, anzi, e’ a livello di tabelle che si decide se utilizzare o meno la relazionalita’.
Noi abbiamo un grosso DB con centinaia di tabelle, di cui una parte sono relazionali, una parte no, ed una piccola parte contiene delle tabelle mappate a degli oggetti…non vedo il vantaggio di un DB che permette solo “non relazioni”, sinceramente.
Il vantaggio di DB non relazionali è la scalabilità, che è il tallone d’Achille di quelli relazionali.
Ma per la scalabilità viene sacrificata la consistenza, e questo NON mi piace (se non casi ben precisi).
Non lo so, devo mettermi a studiarli un attimo, perche’ non capisco bene la questione ed i termini mi stanno incasinando.
Un “DB non relazionale” e’ un DB creato senza sfruttare le relazioni, ma questo non implica che il DBE non supporti la relazionalita’ o non sia scalabile…no?
Oltre al fatto che i miei server Oracle scalano che e’ una bellezza semplicemente aggiungendo nodi al cluster e partizionando le tabelle :-D
Ciao,
ti sei dimenticato di Orient! Nato come un ODBMS tanti anni fa fu compliant allo standard ODMG 3.0. Dopo 12 anni è stato riscritto in Java ed oggi è OrientDB: un document-graph (NoSQL).
Dimenticavo, il progetto è italiano.
http://www.orientechnologies.com
Sì, ma i DB NoSQL scalano meglio, proprio perché non hanno tanti vincoli da rispettare, in primis la consistenza dei dati che un engine ACID può fornire.
@Luca… chiedo venia :-) Hai ragione, Orient mi è proprio sfuggito. Grazie per la segnalazione
Ciao, il 1 ottobre si terra’ mongoTorino, un evento che si rivolge a tutti coloro che sono interessati alle tecnologie NoSQL ed in particolare a MongoDB. http://www.mongotorino.org/ , vi aspettiamo :)