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: [email protected]