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