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 

No content

No content

No content

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 

No content

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]