Introduzione a Riak, database NoSQL. Slide adatte per una introduzione molto generale, seguita da discussione in aula ed esempi pratici. Materiale prodotto nell'ambito di un progetto per la facoltà di Informatica della Università Bicocca di Milano, in collaborazione con Andrea Maurino e Blerina Spahiu

1. Riakhttp://basho.com/riak/

2. Caratteristiche Principali
● Key-Value store
● High-availability tramite clustering e replication
● Architettura Peer-to-Peer (No Master)
● Semplicità di gestione operazionale
● Trade-offs:
– Consistency
– Availability

3. Data store
● I dati sono memorizzati come coppie Chiave-Valore
● I Bucket partizionano lo spazio delle chiavi:
– corrispondono (grossomodo) alle tabelle del modello
relazionale
– evitano le collisioni (chiavi identiche per oggetti diversi)
● Gli oggetti memorizzati:
– sono semplicemente dati binari
– il tipo è determinato di volta in volta dal MIME Type
memorizzato insieme al dato
– possono avere una lista di metadati aggiuntivi

4. Architettura – 1
● Architettura a cluster per definizione
● Anello di indirizzamento (Riak Ring) a 160-bit
– suddiviso in partizioni di eguale dimensione
– ogni partizione è associata ad un vnode
● Ogni nodo fisico prende in carico lo stesso numero
di partizioni = (n. di partizioni) / (n. di nodi fisici)
● L'allocazione dei Vnode si alterna ciclicamente fra i
nodi fisici (ecco perché “anello”)

5. Architettura – 2
Ring con 32 partizioni/vnode e 4 nodi fisici (fonte: documentazione Riak)

6. Operazioni CRUD
● Create:
– La chiave può essere predeterminata o auto-generata da Riak
● Read:
– Accesso diretto per chiave
– Indici secondari
– Indici invertiti (ricerca testuale)
– Elenco delle chiavi del bucket
● Update:
– Gli update devono sempre contenere tutto il dato
● Delete
– Per eliminare un bucket bisogna cancellare ogni valore in esso contenuto

7. MapReduce – 1
● Tecnica per suddividere l'elaborazione di grandi dataset
in un sistema distribuito
● Filosofia:
“È più efficiente spostare 10 kb di codice verso i dati,
che spostare (stream) Gb di dati verso i tuoi 10 k di
codice”
● L'elaborazione avviene sugli stessi nodi fisici dove sono
memorizzati i dati
● Sfrutta in modo diretto la natura distribuita del sistema

8. MapReduce – 2
● La funzione Map viene eseguita su ogni oggetto selezionato,
producendo una lista di risultati intermedi. Esempi:
– A) conteggio delle parole in un testo
– B) estrazione di uno o più valori
● I risultati intermedi vengono aggregati dalla funzione Reduce.
Esempi:
– A) aggregazione di tutti i conteggi delle parole
– B) somma/media/ecc. dei valori estratti
● Le fasi Map e Reduce sono molto simili, possono infatti essere
concatenate per produrre analisi più complesse.

9. MapReduce – 3
Nodo coordinatore
Nodo elaboraz. 1
Map(Dato 1) {...}
Nodo elaboraz. 2
Map(Dato 2) {...}
Nodo elaboraz. N
Map(Dato N) {...}
...
Dato 1
Dato 2
Dato N
...
1
Richieste
di Map
Nodo coordinatore
Nodo elaboraz. 1
Nodo elaboraz. 2
Nodo elaboraz. N
...
2 Reduce
Dati intermedi 1
Dati intermedi 2
Dati intermedi N
3 Risultato

10. Ricerca
● Ricerca testuale:
– funzioni built-in di ricerca su dati di tipo XML o JSON
– necessaria configurazione
● Indici secondari
– sono costruiti sui metadati, invece che sui contenuti
– è quindi una “etichettatura” (tagging) più che
un'indicizzazione vera e propria

11. Use case – esempi
● Logging e monitoring
– log applicativi / web
– dati prodotti da sensori
● Session Storage
● Fornitura di contenuti
– banner pubblicitari
– siti web
– social network streams/walls
● Preferenze e dati utente

12. Use case: Server Monitoring - 1
● Raccolta di dati di monitoring: utilizzo memoria,
CPU, ecc.
● Quantità e intensità notevole di dati
● Struttura proposta:
– Bucket: identificativo del server
– Key: timestamp, con intervallo prefissato (ad es. 10
secondi)
– Value: JSON con i valori dei vari sensori, ad es:
{"CPU": 0.8, "MEM": 0.5}

13. Use case: Server Monitoring - 2
Server 1
Server 2
...
Server N
Riak Cluster:
/Bucket_Server1
/Bucket_Server2
/Bucket_ServerN
...
Dati
Dati
Dati

14. Use case: Server Monitoring - 3
● Si presta ad analisi massive con MapReduce
● Flessibilità: possiamo memorizzare qualsiasi
valore, anche non inizialmente previsto
● Tolleranza a comportamento non-ACID:
– Configurazione write-intensive (W=1)
– Tollera la perdita di dati
– Non sono necessarie transazioni ACID perché i
dati, una volta scritti, non cambieranno mai

15. Use case: Session Storage - 1
● Implementazione di un failover cluster:
– Cluster di web server (ad es. Apache Tomcat)
– Le sessioni sono memorizzate in uno storage condiviso
– Se cade un membro del cluster, l'utente viene rediretto in
maniera trasparente verso un altro server
● Struttura proposta:
– Bucket: applicazione da servire
– Key: SessionID dell'utente
– Value: valori memorizzati nella sessione

16. Use case: Session Storage - 2
Riak
Session
Storage
...
Load
Balancer
Tomcat Cluster
Web requests

17. Use case: Session Storage - 3
● Scalabilità praticamente lineare
● Tolleranza a comportamento non-ACID:
– tollera la perdita di dati (al massimo l'utente deve ri-
eseguire la login)
– Non sono necessarie transazioni ACID, perché i
dati non sono contesi fra più lettori/scrittori

18. Use case - Conclusioni
● Prestazioni migliori rispetto ad un RDBMS:
– velocità e throughput
– resistenza ai guasti
– scalabilità lineare
● Bisogna però rinunciare ad alcune garanzie ACID!
● Bassa “ricercabilità” (queryability) dei dati:
– indicizzazione e ricerca piuttosto primitive
– MapReduce adatto ad elaborazioni di tipo batch, non real-time