Diego GUENZI Rodolfo BORASO
NOSQL Movimento che promuove una classe non ben definita di strumenti di archiviazione di dati Un nuovo modo di vedere la persistenza Si differenziano dai RDBMS: Non utilizzano il tradizionale SQL Non adottano schemi tabellari fissi (dati semistrutturati) Evitano join Scalano facilmente Usano commodity hardware 2
NOSQL Non è un movimento contro l SQL Not Only SQL Opensource Uso complementare ai RDBMS The right tool for the job Coprono aree dove i RDBMS sono deboli Hanno come target settori specifici 3
Scalabilità Verticale Potenziamento hardware Orizzontale Numero di macchine 4
Costo della scalabilità Verticale Esponenziale Orizzontale Lineare 5
Scalabilità RDBMS Verticale OK Orizzontale Problematica: tecniche complesse con forte degrado delle performance 6
Scalabilità DB NOSQL Verticale OK Orizzontale OK 7
Solo scalabilità? Scalare orizzontalmente => avere più macchine Fault tolerance Load balancing High availability Avere più macchine => poter distribuire e replicare i dati su più nodi Uso ideale in ambienti distribuiti Affidabilità Elevate prestazioni Tutto in bundle, senza bisogno di software aggiuntivi! 8
Shared-nothing vs shared-disk Necessita di un numero minore di lock Caching migliore e più snello Può richiedere l uso di TPC (2PC) per le operazioni che riguardano più nodi Recuperare dati non indicizzati richiede operazioni su ogni macchina 9
Ambienti distribuiti 10*1=10 10*2=20 10*3=30 10*4=40 10*5=50 10*6=60 10*7=70 10*8=80 10*9=90 10*10=100 10*11=110 10*12=120 10*13=130 10*14=140 10*15=150 10*4=40 10*5=50 10*6=60 10*1=10 10*2=20 10*3=30 10*10=100 10*11=110 10*12=120 VS 10*7=70 10*8=80 10*9=90 10*13=130 10*14=140 10*15=150 10
Fault tolerance VS 11
Ambienti distribuiti 12
Ambienti distribuiti 13
Network partitioning 14
Il teorema CAP Congettura di Brewer (2000), dimostrata da Gilbert e Lynch (2002) e divenuta un teorema Consistency, Availability e Partition tolerance Non si possono avere tutte e tre, al massimo due! 15
Il teorema CAP Consistency C Consistenza Ogni client ha la stessa visione dei dati RDBMS DBMS NOSQL CP P Partition Tolerance Tolleranza al partizionamento Il sistema funziona correttamente nonostante il partizionamento della rete Teorema CAP: due su tre CA PA DBMS NOSQL A Availability Disponibilità Ogni client può sempre leggere e scrivere, dato che il servizio risulta sempre attivo e funzionale 16
Teorema CAP - CA Filosofia adottata nei RDBMS tradizionali Evitare il network partitioning tenendo i dati in un unico punto Non scala orizzontalmente 17
Teorema CAP - PA Se si verifica un network partitioning, offriamo una eventual consistency Possibilità che si generino risposte differenti da server differenti Allo scomparire del partizionamento si torna ad una strong consistency 18
Teorema CAP - CP Se si verifica un network partitioning sospendiamo o limitiamo il servizio Possibilità che alcuni dati siano reperibili, altri no Allo scomparire del partizionamento, tutti i dati ritornano reperibili 19
ACID vs BASE Atomicity, Consistency, Isolation & Durability RDBMS Basically available, Soft state & Eventually consistent DBMS NOSQL 20
Replica Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 21
Eventual consistency Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 48 22
Eventual consistency Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 48 Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 49 23
Strong Consistency Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 49 Nome: Mario Cognome: Rossi Età: 49 24
Sharding Nome: Mario Cognome: Rossi Età: 49 Nome: Ugo Cognome: Verdi Età: 37 Nome: Antonio Cognome: Bianchi Età: 30 Nome: Viola Cognome: Gialli Età:?? Nome: Viola Cognome: Gialli Età: 50 Nome: Marisa Cognome: Azzurri Età: 56 25
Sharding Nome: Mario Cognome: Rossi Età: 49 Nome: Viola Cognome: Gialli Età: 50 Nome: Ugo Cognome: Verdi Età: 37 Nome: Antonio Cognome: Bianchi Età: 30 Nome: Viola Cognome: Gialli Età: 50 Nome: Marisa Cognome: Azzurri Età: 56 26
Basic Availability Nome: Mario Cognome: Rossi Età: 49??? Nome: Ugo Cognome: Verdi Età: 37 Nome: Antonio Cognome: Bianchi Età: 30 Nome: Viola Cognome: Gialli Età:?? Nome: Viola Cognome: Gialli Età: 50 Nome: Marisa Cognome: Azzurri Età: 56 27
Replica e sharding Mario, Rossi, 49 Ugo, Verdi, 37 Antonio, Bianchi, 30 Mario, Rossi, 49 Antonio, Bianchi, 30 Mario, Rossi, 49 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Antonio, Bianchi, 30 28
Il mercato 29
I prodotti 30
I data model Modello dei dati nei DBMS NOSQL: Chiave-Valore Orientato alle colonne Orientato ai documenti Orientato ai grafi Esempi di DBMS NOSQL: Berkley DB MemcacheDB Redis Dynamo Voldemort BigTable Hypertable HBase Cassandra SimpleDB CouchDB Riak MongoDB Neo4j 31
Key-Value Coppie di attributi chiave - valore Dati scritti e letti principalmente per chiave primaria Spesso usato come sistema per rendere persistenti oggetti all interno di applicativi distribuiti Poche join e semplici 32
Row-oriented Usato di default dai RDBMS Lettura di una riga in un solo colpo (località dei dati) Lettura di una colonna richiede scan completo 33
Column-oriented Località a livello di colonna, utile per query di aggregazione Lettura di una riga richiede scan completo 34
Column-family Località scelta durante la creazione della base dati Se ben utilizzato, vantaggi di entrambe le tecniche (o svantaggi di entrambi se mal progettato!) 35
Document-oriented Gestione di dati eterogenei Proprietà degli oggetti estremamente differenti Spesso non in relazione fra di loro Es.: gestire un negozio di libri sul Ruby e di film sugli zombi 36
Graph-oriented Dati strutturati in grafi Forti relazioni mono e bi-direzionali Basse richieste di consistenza 37
Cassandra Architettura orientata alle colonne / ibrida basata sul peer-to-peer (no SPOF) Si ispira ad altri DB NOSQL: BigTable (Google) e Dynamo (Amazon) Nato da un idea di Facebook in sostituzione di MySQL e rilasciato come opensource (licenza Apache) Scritto interamente in Java Consistenza dei dati personalizzabile (0,1,Quorum,All) Replica dei dati automatica e sharding basato su DHT Aggiunta di nodi a caldo Salvataggio dati in RAM (con flush) 38
Salvataggio dati I dati vengono scritti in memoria e su un commit log Velocità di lettura/scrittura Possibilità di recovery in caso di failure Flush periodiche 39
Flush dei dati Periodicamente (o dopo richieste specifiche), la RAM viene copiata su disco Si svuota il commit log Si aggiunge un file dati I file dati possono essere compattati 40
Aggiunta di un nodo Mario, Rossi, 49 Ugo, Verdi, 37 Antonio, Bianchi, 30 Mario, Rossi, 49 Antonio, Bianchi, 30 Mario, Rossi, 49 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Antonio, Bianchi, 30 41
Bilanciamento Ugo, Verdi, 37 Antonio, Bianchi, 30 Mario, Rossi, 49 Ugo, Verdi, 37 Ugo, Verdi, 37 Viola, Gialli, 50 Mario, Rossi, 49 Antonio, Bianchi, 30 Mario, Rossi, 49 Viola, Gialli, 50 Viola, Gialli, 50 Antonio, Bianchi, 30 42
HBase Architettura orientata alle colonne / ibrida basata sul file system distribuito HDFS di Hadoop Si ispira a BigTable di Google Software opensource con licenza Apache Scritto interamente in Java Salvataggio dati in RAM (con flush) Replica dei dati e sharding ottenuti grazie all HDFS Aggiunta di nodi a caldo Self-healing 43
Architettura (semplificata) HBASE HDFS 1 Master Server (eventualmente replicato) 1 NameNode (SPOF fino alla futura v.0.21) Metadati Metadati N Region Server M DataNode Dati Dati HDFS Data Region Master Secondary Region Name Data Region Data 44
Self-healing Se un Data Node dell HDFS cessa di funzionare, i blocchi dei dati mancanti vengono replicati (e bilanciati) dalle altre copie esistenti Se una macchina cade, le applicazioni non se ne rendono neppure conto Eventual consistency e basic availability solo in rari casi (caduta contemporanea di molte macchine, split della rete ) 45
Self-healing Mario, Rossi, 49 Ugo, Verdi, 37 Antonio, Bianchi, 30 Mario, Rossi, 49 Antonio, Bianchi, 30 Mario, Rossi, 49 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 In realtà, il self-healing è una feature del livello sottostante ad HBase, HDFS, quindi riguarda i blocchi dei dati. Per semplicità di comprensione, l esempio è stato fatto con i dati veri e propri Ugo, Verdi, 37 Viola, Gialli, 50 Antonio, Bianchi, 30 46
Self-healing Mario, Rossi, 49 Ugo, Verdi, 37 Antonio, Bianchi, 30 Mario, Rossi, 49 Antonio, Bianchi, 30 Mario, Rossi, 49 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Antonio, Bianchi, 30 47
Self-healing e balancing Mario, Rossi, 49 Ugo, Verdi, 37 Antonio, Bianchi, 30 Viola, Gialli, 50 Mario, Rossi, 49 Antonio, Bianchi, 30 Mario, Rossi, 49 Viola, Gialli, 50 Mario, Rossi, 49 Ugo, Verdi, 37 Viola, Gialli, 50 Ugo, Verdi, 37 Viola, Gialli, 50 Antonio, Bianchi, 30 48
MongoDB Architettura orientata ai documenti (formato JSON/BSON) Software opensource scritto in C++ Memorizzazione di dati binari molto semplice ed efficiente grazie a GridFS Ottima gestione degli indici e delle collezioni Possibilità di fare query tramite Javascript Replica dei server (replica set) e sharding Supporta API verso molti linguaggi (Driver) 49
Architettura 50
YCSB Yahoo Cloud Serving Benchmark Una piattaforma comune per il benchmarking dei DBMS NOSQL 51
SQL scalabile Una via di mezzo fra il mondo NOSQL e quello relazionale Uso di tabelle relazionali e di SQL Stessa scalabilità dei DBMS NOSQL Molti prodotti stanno nascendo: VoltDB, MySQL Cluster (NDB), ScaleDB, Xeround Molti storage engine per MySQL 52
Quindi 53
Diego GUENZI tgsi@libero.it Rodolfo BORASO rboraso@gmail.com Domande?