Database documentali: RavenDB

RavenDB è un database che non utilizza il modello relazionale come SQL server o Oracle.

Un database documentale è infatti basato non su record ma su documenti, ogni documento è indipendente e privo di schema, diciamo che il documento è l’unità atomica di persistenza.
I database documentali come RavenDB (ce ne sono molti altri) vengono anche chiamati noSQL (che sta per “non solo SQL”), e sono per la maggior parte open source.

Open source, croce e delizia

Open source è da sempre considerato ben visto da tutti, è gratis e customizzabile, RavenDB è in particolare un prodotto open source scritto in c#.
Seppure sia possibile aprire i sorgenti di RavenDB e personalizzarseli, sfido chiunque a farlo, è un software piuttosto critico trattando direttamente con i dati dei nostri software, quindi open source si, ma in questo caso, direi che l’unico vantaggio sta nella parola gratis.
Ad ogni modo, i potenziali clienti spesso si aspettano un determinato tipo di supporto sul software dove andranno a salvare vita morte e miracoli, e da questo punto di vista, RavenDB è l’unico (che io sappia) che permette di fare una gabola manageriale/burocratrica: essendo Raven basato su database ESENT (formato proprietario di Microsoft) possiamo attivare in caso di problemi il supporto Microsoft che ci può fornire supporto essendo l’intero software basato su sue tecnologie.
Inoltre Raven è in grado di girare su linux anche se la base di persistenza in quel caso non è più ESENT ma MUNIN.
Questo discorso è puramente “manageriale” e non ha nulla di tecnico, sappiamo in realtà che sarà piuttosto improbabile che un bug del kernel di windows possa influire sul funzionamento di Raven.

Schema-less

Cosa vuol dire che un database documentale è schema-less? vuol dire che non ho tabelle, non ho campi e cosa ancora più importante, non ho foreign key.
Tutto questo è un’arma a doppio taglio, mi permette infatti di creare per esempio una versione 1.0 di un software che salva un contatto in Raven scrivendone Nome e Cognome, poi successivamente, possiamo nella versione 2.0 del software aggiungere il campo Numero di telefono, senza toccare nulla in Raven.
Raven è di fatto un calderone di dati dove io butto dentro qualsiasi cosa, lui non dirà mai di no.
Perchè è un’arma a doppio taglio? perchè a lungo andare i cambiamenti all’interno del contatto potrebbero divenire molti e se io non ne tengo conto all’interno del mio programma, rischio di arrivare a qualcosa di instabile se non tengo presente del fatto che nella versioni precedenti il campo numero di telefono non esiste e può essere null.

Il documento

I database documentali al contrario dei database relazionali, hanno come unità atomica minima, non il record, ma il documento.
Il documento, come già detto è schema-less, può contenere qualsiasi cosa e questo concetto è molto difficile da digerire per chi viene da un database relazionale.
Il modello documentale infatti, non ragiona su dati in relazione tra di loro, ma ragiona appunto, su documenti di dati, faccio un esempio:
Un ordine fornitore in modello relazionale è composto da una tabella ordini e da una tabella righe ordine con una foreign key, e fin qui credo che siamo tutti d’accordo.
Nel modello documentale invece, non esistendo foreign key, io persisto la classe ordine, fine.
All’interno del documento ordine avremo un array di righe ordini ma poco ci importa, penserà a tutto Raven.
L’unica cosa che dobbiamo capire è che le righe d’ordine non hanno ragione di esistere senza un ordine, e quindi possono essere inglobate all’interno dell’ordine stesso.

Consistenza

Ora che abbiamo parlato del come Raven persiste i suoi dati possiamo parlare di consistenza dei dati.
I database documentali, come quelli relazionali supportano le transazioni, ma i database documentali, non garantiscono la consistenza del dato, vado a spiegare in dettaglio.
Nei database relazionali, quando chiedo di scrivere un dato, il dato viene scritto, gli indici esistenti su quel dato vengono rivalutati e solo dopo la transazione viene conclusa, quindi in sostanza, scrivo, leggo ed il dato è già disponibile.
Nei database documentali, il processo avviene in maniera diversa: scrivo, la transazione viene chiusa e nel frattempo inizia la rivalutazione degli indici.
Questo ci porta a dover tener conto in fase di sviluppo del fatto che scrivo, leggo e il dato ancora non c’è oppure è ancora “obsoleto” (perchè non indicizzato).

Stale data

Da qui la nascita del un nuovo termine “stale data” ovvero dati obsoleti, in quanto, potremmo andare a leggere nel DB dei dati che sono in fase di indicizzazione e quindi obsoleti.
Solitamente il programmatore dopo una scoperta così, torna ai database relazionali, perchè spesso fa ragionamenti quadrati e non riesce a vedere oltre (io stesso mi sono ritrovato in questa condizione)
Ammettiamo per esempio che Pippo in azienda modifichi il numero di telefono di un’anagrafica del gestionale, ora… è veramente fondamentale che entro i prossimi 2 secondi il dato sia aggiornato e disponibile a tutti?
Il processo di indexing dei dati in Raven avviene in background ed è studiato per lavorare su enormi cluster e fornire prestazioni spaventose in lettura, gli indici vengono solitamente aggiornati in pochi secondi, ma potrebbero non esserlo in tutte le condizioni.
Il problema viene fuori subito se all’interno della stessa routine scriviamo e leggiamo nell’arco di pochi millisecondi, il software va in debug e ci accorgiamo di questa cosa immediatamente.
Ad ogni modo Raven ci mette a disposizione una proprietà che indica se su quel documento è in corso un reindexing dei dati, quindi potremmo fare in modo di aspettare che il reindexing termini se l’operazione necessita di dati consistenti.

Indici

Gli indici sono il vero nodo cruciale dei database documentali, per salvare infatti, il tutto è semplicissimo, ma in lettura, non avendo tabelle, campi, relazioni ecc… dobbiamo estrarre i dati da un blocco unico di documenti non categorizzati con degli indici creati adhoc.
Raven a differenza di altri DB documentali ci viene incontro offrendo la funzionalità di autoindexing.
Riesce infatti a creare autonomamente la projection dei dati che abbiamo chiesto, inoltre è in grado di gestire il ciclo di vita dei suoi indici e marcarli come temporanei o statici in base al numero di query che facciamo su quell’indice in un arco di tempo.
Oltre agli indici automatici potremmo aver bisogno di indici creati appositamente per estrarre i dati sotto una forma specifica, in questo caso possiamo creare una “map/reduce”.
La creazione della map/reduce avviene attraverso la specificazione di una map (dove prendere i dati) e la specificazione di una reduce (come elaborarli e restituirli).
Inoltre in questo processo possiamo istruire il processo di indexing affinchè escluda un determinato campo dal processo ecc…
Cosa molto interessante, Raven, per creare le map/reduce si appoggia a LINQ e offre intellisense al contrario di altri db documentali.

Json

Json è il formato con cui, sotto il cofano, Raven (e la maggior parte dei db documentali) salva i dati.
Json è un formato di facile lettura che salva i nostri documenti in formato testo.
Ecco un esempio di documento Json:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}]
    }
  }
}

Come potete vedere non esistono enforcement sul tipo di dati al contrario database relazionali, tutto viene considerato string quando viene persistito e riconvertito quando viene serializzato e deserializzato nel codice nel tipo descritto nella classe.

Lucene

Lucene è il motore di indicizzazione che Raven utilizza per “trovare” i dati scritti in maniera veloce a secondo degli indici che ci creiamo sopra.
Lucene è anch’esso un prodotto open source con tanto di porting in vari linguaggi.
Trovate informazioni sulla pagina di wikipedia.

Conclusioni

Bene, credo di aver trattato un 10% di Raven, a tempo debito farò dei post più pratici e meno teorici, questa vuole essere solo una piccola introduzione anche se già c’è molta carne al fuoco.

Rispondi

Leggi articolo precedente:
ALM, il prototipo cartaceo

Ho già accennato cos'è ALM e la gestione del ciclo di vita di un software a livello concettuale, oggi voglio...

Chiudi