NOSQL

Giovedì, 17 maggio 2012
Speaker: Manuel Scapolan

NOSQL
Il database relazionale va in pensione,
avanza il movimento NOSQL

RavenDB, database non relazionale,
rappresentante del movimento NOSQL

Il mondo è cambiato troppo in fretta …
+
+
+
=

Per superare questa
montagna di dati era
necessario scalare
orizzontalmente, ovvero
fare scale out,
cosa che però gli attuali
RDBMS non sapevano
fare molto bene …

Per risolvere il problema
Amazon e Google hanno
deciso di implementare
internamente delle soluzioni
che avessero come
caratteristica principale la
scalabilità orizzontale

Le implementazioni dei due
giganti del web hanno dato il via
ad un piccolo esercito di
database “alternativi”
(chiamati poi NOSQL)

BigTable: http://research.google.com/archive/bigtable.html
Dynamo: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

Per definirsi tale, un database
NOSQL deve essere:
Non relazionale
Inteso come modello di
trattamento del dato Supporto? Distribuito
Open-source
Scalabile orizzontalmente
Deve essere scalabile
“by design”
In accordo con la definizione data su http://nosql-database.org/

Classificazione
I database NOSQL sono
classificati in base al tipo di
modello che utilizzano per la
memorizzazione del dato, in
particolare possiamo individuare
queste grandi famiglie:

Key-Value stores
Column-oriented databases
Document databases
Graph databases

Fonte: http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

Voldemort

Key/Value stores memcached
Tokyo cabinet

Sono definiti da un semplice dizionario/mappa che permette
all’utente di recuperare e aggiornare il valore memorizzato
data la sua chiave
stringa
BLOB

• Get(key)

• Set(key, value)

• Delete(key)
… e poco altro

Caso d’uso: memcached
Utilizzare memcached per alleggerire il carico sul database
relazionale ed avere una cache scalabile e indipendente dal
processo ASP.NET

Qui posso fare scale-out

Qui posso fare
“solo” scale-up

Caso d’uso: memcached
Utilizzare memcached per alleggerire il carico sul database
Facebook's fork of
relazionale ed avere una cache scalabile e indipendente dal
memcached can
processo ASP.NET
do ~200k QPS

Qui posso fare scale-out

Qui posso fare 1 Se non trovo il valore lo recupero
“solo” scale-up dal database (2)

2
Con l’aiuto di memcached posso fare
scale-out anche con i dati, ma in memoria

MongoDB

Document databases RavenDB
CouchDB

Memorizza le informazioni come collezioni di documenti.
Un documento può contenere informazioni annidate ed
ha un formato riconosciuto (JSON, XML, etc.) che
permette poi al server di eseguire delle query sui dati.

A differenza delle tabelle di un relazionale però è
schema-free nel senso che non deve sottostare ad uno
schema ben preciso.

Posso avere documenti di una stessa tipologia con campi
diversi e posso aggiungere nuovi campi senza
compromettere i documenti esistenti.

Allegro Graph

Graph databases Sones Neo4j
FlockDB

Rappresentano perfettamente una realtà composta
da una fitta rete di connessioni e la modellano
sotto forma di nodi e rami di un grafo.

Ai nodi come ai singoli rami vengono associate le
informazioni attraverso Key-Value store.

Se togliamo le relazioni (i rami) assomigliano a
tutti gli effetti ad un database documentale.
recommends
Per le query che soddisfano il modello gerarchico i
tempi di esecuzione possono essere 1.000 volte
più veloci rispetto agli altri database.

Amazon SimpleDB

Column-oriented Cassandra
Hypertable

databases Hadoop / HBase

Le informazioni non sono memorizzate per riga bensì per colonna.
L’ovvietà dell’affermazione si può spiegare meglio con un esempio:

Row-oriented Column-oriented

1,Smith,Joe,40000; 1,2,3;
2,Jones,Mary,50000; Smith,Jones,Johnson;
3,Johnson,Cathy,44000; Joe,Mary,Cathy;
40000,50000,44000;

DEMO 1
Installazione di RavenDB, configurazione e
operazioni di lettura e scrittura
E’ un database documentale

Schema-free
Le informazioni sono memorizzate in JSON e non devono sottostare
ad uno schema, quindi posso arbitrariamente decidere di aggiungere
successivamente dei campi senza compromettere i dati esistenti.

Indici
Se i documenti che inseriamo non hanno un formato stabilito non abbiamo un modo per
poter recuperare selettivamente le informazioni. RavenDB ci mette a disposizione la
possibilità di creare degli indici con i quali fare le query per recuperare i documenti, una
porzione di essi (proiezione) oppure fare delle aggregazioni.

Come funzionano allora le query?
Premessa: tutte le query devono usare un indice

Se non esiste un indice per quella interrogazione RavenDB ne crea uno temporaneo.
Se lo chiamo più volte diventa persistente.

in Lucene.NET

E’ la funzione usata da RavenDB per estrarre le informazioni da memorizzare insieme all’indice.

Quando chiamo la query le informazioni precedentemente memorizzate mi vengono ritornate
come risultato.

Informazioni staleness
Siccome l’elaborazione di un indice è molto pesante non viene fatta nello stesso momento
della query, ma viene fatta in un thread in background che parte quando viene aggiunto
un nuovo dato oppure ne viene modificato uno esistente.

Questo comportamento ha due immediate conseguenze:
• Le query sono molto veloci
• Le query possono ritornare dati non aggiornati (staleness)

Posso sempre verificare se il risultato della query ha tornato dati non aggiornati:

oppure posso specificare alla query quanto può attendere (oppure fino a quando attendere):

Ci consente di

Map/Reduce fare delle
aggregazioni

La Map/Reduce non è altro che un group by applicato ad un elevato numero di dati
distribuiti. La sua applicazione è giustificata dal fatto che abbiamo la necessità di eseguire
un group by in più step ognuno dei quali da eseguire su macchine differenti.

Map/Reduce
Il primo passo è quello di separare l’operazione precedente in più operazioni distinte.

MAP
FUNCTION

Subset di risultati
che diventerà uno
degli input della
reduce

Map/Reduce
Il passo successivo riguarda l’esecuzione del group by sui risultati della map function.

REDUCE
FUNCTION

Il risultato:

Indice Map/Reduce
Ovviamente il passo conclusivo è quello di creare un indice map/reduce che ci permetta di
fare query di aggregazione sui dati:

Ed ecco come poi faccio la query su questo indice:

DEMO 2
Creiamo il nostro primo indice Map/Reduce

DDD (Domain Driven Design)
RavenDB, come tutti gli altri database
documentali, si sposa perfettamente con la
metodologia del Domain Driven Design in quanto
assume che l’informazione minima da salvare,
ovvero il documento, rappresenti un aggregato.

L’aggregato è una unità logica indipendente che
contiene tutte le informazioni necessarie per
definire un contesto applicativo.
Ad esempio il singolo post con l’autore, i
commenti, le categorie e i tag.

No Impedance Mismatch!
ORM

Nessuna Join, la regola è
denormalizzare
DDD tutta la vita, ma mi stai forse dicendo che lo stesso autore
devo salvarlo in ogni documento che contiene un suo post?

Esatto! Nell’aggregato devo mettere solo una versione denormalizzata
che contenga per quanto possibile solo le informazioni strettamente
necessarie che verranno modificate raramente.

Ma così ho una forte duplicazione dei dati, e se poi mi
servirà fare un update?

CAP Theorem

Devi scegliere tra consistenza
e disponibilità del dato

ACID vs BASE

Atomicity, Basic Available,
Consistency, Soft-state,
Isolation, Eventual
Durability consistency

Mantengo l’integrità e la consistenza del dato Favorisco la replicazione per aumentare la
garantendo transazionalità a scapito delle scalabilità orizzontale e la disponibilità del
performance e della scalabilità orizzontale dato a scapito della consistenza

Come scegliere il database “giusto”?

La scelta deve essere guidata da:
• Tipo di dati da memorizzare
• Richieste in termini di scalabilità
• Natura del tipo di interrogazioni
che devo fare sui dati
• Esigenze o vincoli in
termini di consistenza

Alcune considerazioni
Non esiste più un solo modo di pensare al
trattamento dei dati

SQL e NOSQL possono convivere occupandosi di
aspetti diversi ed essere sfruttati al massimo per
quelle che sono le loro caratteristiche e
peculiarità (polyglot persistance)

Alcuni prodotti NOSQL non sono ancora maturi
per giustificarne un impiego a livello enterprise

In alcune circostanze è meglio approfondire gli
strumenti in possesso perché potrebbe risiedere
nella scarsa conoscenza di essi il collo di bottiglia
che stiamo cercando di superare

Riferimenti
Introduzione e concetti base
NoSQL. Present, Past & Future (Gabriele Lana)
NoSQL Databases - Christof Strauch
NoSQL Data Modeling Techniques
Availability & Consistency
Scalable SQL and NoSQL Data Stores - Rick Cattell
Highly Connected Data Models in NOSQL Stores

Casi d’uso ed esempi
What the heck are you actually using NoSQL for?
35+ Use Cases for Choosing Your Next NoSQL Database
What Should I Do? Choosing SQL, NoSQL or Both for Scalable Web Applications
Social networks in the database: using a graph database
Stack Overflow Architecture
NOSQL Overview, Neo4j Intro And Production Example (QCon London 2010)

Riferimenti
SQL vs NOSQL
NoSQL vs. RDBMS: Let the flames begin!
Fighting The NoSQL Mindset, Though This Isn't an anti-NoSQL Piece

RavenDB
RavenDB overview
MVC – Get RavenDB up and running in 5 minutes using Ninject
RavenDB Documentation
Using RavenDB and ASP.NET MVC 4 to create a Twitter Clone Chirpy
Document Databases Compared: CouchDB, MongoDB, RavenDB
Humor
MongoDB vs MySQL
Your Guide to No-SQL - Brian Aker

Credits
Le immagini contenute in questa presentazione hanno
licenza Creative Commons

Slide 1:http://www.flickr.com/photos/32931740@N06/4640796393/
Slide 3:http://www.flickr.com/photos/x1brett/6069486112/
Slide 6: http://www.flickr.com/photos/32066106@N06/4192572579/
Slide 8: http://www.flickr.com/photos/hikingartist/4192577791/in/photostream/
Slide 33:http://www.flickr.com/photos/hikingartist/4193330034/in/photostream/

Thank You MANUEL SCAPOLAN
website: www.manuelscapolan.it
twitter: manuelscapolan
e-mail: info@manuelscapolan.it

NOSQL

Related slideshows

More Related Content

NOSQL