NOSQL Il database relazionale va in pensione,

avanza il movimento NOSQL

Giovedì, 17 maggio 2012

Speaker: Manuel Scapolan

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 …

BigTable: http://research.google.com/archive/bigtable.html

Dynamo: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

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)

Per definirsi tale, un database

NOSQL deve essere:

Non relazionale Distribuito

Open-source

Scalabile orizzontalmente

In accordo con la definizione data su http://nosql-database.org/

Inteso come modello di trattamento del dato

Deve essere scalabile “by design”

Supporto?

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

Classificazione

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

Key/Value stores memcached

Voldemort

Tokyo cabinet

Sono definiti da un semplice dizionario/mappa che permette

all’utente di recuperare e aggiornare il valore memorizzato

data la sua chiave

• Get(key) • Set(key, value) • Delete(key) … e poco altro

BLOB stringa

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 “solo” scale-up

Qui posso fare scale-out

Caso d’uso: memcached Utilizzare memcached per alleggerire il carico sul database

relazionale ed avere una cache scalabile e indipendente dal

processo ASP.NET

1

2

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

Se non trovo il valore lo recupero dal database (2)

Qui posso fare scale-out

Qui posso fare “solo” scale-up

Facebook's fork of

memcached can

do ~200k QPS

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.

MongoDB

Graph databases 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.

Per le query che soddisfano il modello gerarchico i

tempi di esecuzione possono essere 1.000 volte

più veloci rispetto agli altri database.

Sones

Allegro Graph

recommends

Column-oriented databases

Cassandra

Hypertable

Le informazioni non sono memorizzate per riga bensì per colonna.

L’ovvietà dell’affermazione si può spiegare meglio con un esempio:

Amazon SimpleDB

Hadoop / HBase

1,Smith,Joe,40000;

2,Jones,Mary,50000;

3,Johnson,Cathy,44000;

1,2,3;

Smith,Jones,Johnson;

Joe,Mary,Cathy;

40000,50000,44000;

Row-oriented Column-oriented

Il mantra dei database NOSQL:

DEMO 1 Installazione di RavenDB, configurazione e

operazioni di lettura e scrittura

E’ un database documentale

RavenDB in deep

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?

Se non esiste un indice per quella interrogazione RavenDB ne crea uno temporaneo.

Se lo chiamo più volte diventa persistente.

Premessa: tutte le query devono usare un indice

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

in Lucene.NET

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):

Map/Reduce

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.

Ci consente di fare delle aggregazioni

Map/Reduce

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

Subset di risultati che diventerà uno degli input della reduce

MAP FUNCTION

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.

ORM No Impedance Mismatch!

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

Mantengo l’integrità e la consistenza del dato

garantendo transazionalità a scapito delle

performance e della scalabilità orizzontale

Favorisco la replicazione per aumentare la

scalabilità orizzontale e la disponibilità del

dato a scapito della consistenza

Atomicity, Consistency,

Isolation, Durability

Basic Available, Soft-state, Eventual consistency

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

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

Introduzione e concetti base

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

MongoDB vs MySQL

Your Guide to No-SQL - Brian Aker

Humor

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

Credits

Slide 1:http://www.flickr.com/photos/32931740@N06/4640796393/

Slide 3:http://www.flickr.com/photos/x1brett/6069486112/

Slide 4:http://www.flickr.com/photos/55497864@N00/4742540168/

Slide 5:http://www.flickr.com/photos/11357767@N00/7096393207/

Slide 6: http://www.flickr.com/photos/32066106@N06/4192572579/

Slide 7: http://www.flickr.com/photos/7205246@N02/6890042407/

Slide 8: http://www.flickr.com/photos/hikingartist/4192577791/in/photostream/

Slide 18: http://www.flickr.com/photos/32066106@N06/4193330368/

Slide 20: http://www.flickr.com/photos/32066106@N06/3554539705/

Slide 33:http://www.flickr.com/photos/hikingartist/4193330034/in/photostream/

Le immagini contenute in questa presentazione hanno licenza Creative Commons

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