Scarica la presentazione di Manuel Scapolan

Scarica la presentazione di Manuel Scapolan

Giovedì, 17 maggio 2012
Speaker: Manuel Scapolan
NOSQL
Il database
avanza il
relazionale va in pensione,
movimento NOSQL
RavenDB, database non relazionale,
rappresentante del movimento NOSQL
Sondaggio 1
Cosa ne pensi dei database NOSQL?
Il
mondo è cambiato troppo in fretta …
+
+
+
=
Per superare questa
montagna di dati era
necessario scalare
orizzontalmente, ovvero
scale out
fare
,
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/
Key/Value stores
Sono definiti da un semplice dizionario/mappa che permette
all’utente di recuperare e aggiornare il valore memorizzato
data la sua chiave
stringa
• Get(key)
• Set(key, value)
• Delete(key)
… e poco altro
BLOB
Voldemort
memcached
Tokyo cabinet
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
relazionale ed avere una cache scalabile e indipendente dal
processo ASP.NET
Facebook's fork of
memcached can
do ~200k QPS
Qui posso fare scale-out
Qui posso fare
“solo” scale-up
1
Se non trovo il valore lo recupero
dal database (2)
2
Con l’aiuto di memcached posso fare
scale-out anche con i dati, ma in memoria
Sondaggio 2
Nelle tue applicazioni usi la cache?
Document databases
MongoDB
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.
Graph databases
Allegro Graph
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.
Column-oriented
databases
Amazon SimpleDB
Cassandra
Hypertable
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;
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?
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):
Map/Reduce
Ci consente di
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 finale è questo:
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,
Consistency,
Isolation,
Durability
Basic Available,
Soft-state,
Eventual
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
Sondaggio 3
Useresti NOSQL nella tua prossima
applicazione?
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 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/
Thank You
MANUEL SCAPOLAN
website: www.manuelscapolan.it
twitter: manuelscapolan
e-mail: [email protected]
Sondaggio 1: Cosa ne pensi dei database NOSQL?
• Non so, aspetto di capire meglio cosa sono e a che
cosa servono prima di esprimere un giudizio
• Sono scettico, per me il database relazionale rimane
l’unica destinazione possibile per i miei dati
• Penso possano essere in alcuni casi una valida
alternativa ai database relazionali
• Sono fantastici, appena possibile abbandono il
database relazionale e porto tutto su NOSQL!
Sondaggio 2: Nelle tue applicazioni usi la cache?
•
•
•
•
•
Si, quella di ASP.NET
Si
Si, tra l’altro utilizzo proprio memcached
No, per ora non ne ho avuto bisogno
No, ma penso che proverò memcached
Sondaggio 3: Useresti NOSQL nella tua prossima
applicazione?
• Si, però solo come test
• Si, anche in produzione
• No