Upgrade to Pro — share decks privately, control downloads, hide ads and more …

NOSQL

 NOSQL

Il database relazionale va in pensione, avanza il movimento NOSQL.

Manuel Scapolan

May 17, 2012
Tweet

More Decks by Manuel Scapolan

Other Decks in Technology

Transcript

  1. 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
  2. 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 …
  3. 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)
  4. 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?
  5. 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/
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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.
  13. 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.
  14. 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.
  15. 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):
  16. 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
  17. 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
  18. Map/Reduce Il passo successivo riguarda l’esecuzione del group by sui

    risultati della map function. REDUCE FUNCTION Il risultato:
  19. 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:
  20. 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!
  21. 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?
  22. 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
  23. 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
  24. 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
  25. 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)
  26. 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
  27. 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