Post on 27-Jan-2015
description
NoSQL, No Worries
Stefano Maraspin
MV Associati
Vecchi problemi, nuove soluzioni
@maraspin
PARTIAMO DA UN CASE STUDY
L’OBIETTIVO
Classico Stack LAMP/LAPP
E SE?
DISTRIBUZIONE DATI, LOGICA
VOGLIAMO ALTA DISPONIBILITÀ…
…E COERENZA SUI DATI
Non potete avere tutto, ragazzi!
Prof. Eric Brewer http://www.cs.berkeley.edu/~brewer/
F H
Non scordiamo neppure la latenza!
Consistency
Availability Partition Tolerance
Consistency
Availability Partition Tolerance
Categoria AP: DynamoDB CouchDB Cassandra MongoDB* Tokyo Cabinet Riak* Voldemort etc.
* Posizione configurabile
Categoria CP: BigTable Hbase MongoDB* Riak* Redis Memcached Scalaris etc.
Categoria CA: RDBMS
Consistency
Availability Partition Tolerance
Categoria AP: DynamoDB CouchDB Cassandra MongoDB* Tokyo Cabinet Riak* Voldemort etc.
* Posizione configurabile
Categoria CP: BigTable Hbase MongoDB* Riak* Redis Memcached Scalaris etc.
Categoria CA: RDBMS
Cosa abbiamo considerato per la scelta? • Supporto multi-master configurabile • Facilità di sincronizzazione dati e
applicazione • Flessibilità del modello dati • Semplicità
Consistency
Availability Partition Tolerance
Categoria AP: DynamoDB CouchDB Cassandra MongoDB Tokyo Cabinet Riak Voldemort etc.
Categoria CP: BigTable Hbase MongoDB Riak Redis Memcached Scalaris etc.
Categoria CA: RDBMS
“designed with the web in mind”
Cos’è CouchDB? • Datastore che parla HTTP • Modello dati documentale (JSON) • Pensato per contesti distribuiti • Replicazione master-master • Può contenere intere applicazioni Web
lato client HTML/CSS/JS (couchapp)
SVILUPPATORI
SERVER-SIDE
RELAZIONI
METADATI
0
2000
4000
6000
8000
10000
12000
14000
16000
DB Size (MB)
NB Quanto sopra su update!
Problema di spazio
LA COMPATTAZIONE
Prestazioni durante la compattazione
• 350 evt/sec in inserimento • 3000 evt/sec se in batch mode • 100 evt/sec su update • 10 evt/sec durante compattazione
NB: dati forniti unicamente per dare ordini di grandezza. Test eseguiti su server entry level IBM x3550 M3, 1x3.60 GHz Xeon, 4GB RAM, Dischi SAS in RAID 0; CouchDB configurato con httpd max_connections = 2048, export ERL_MAX_PORTS=4096, export ERL_FLAGS="+A 4«, fsync
ULTERIORE ESIGENZA
RSS
Previsioni meteo
Video
Eventi
...
REST API Crawler
CDN
RSS
Previsioni meteo
Video
Eventi
...
REST API Crawler
CDN
?
Cosa ci serve? • Flessibilità del modello dati • Facilità di dialogo con PHP • Contesto non distribuito • Durevolezza non fondamentale • Prestazioni • Flessibilità di query
Perchè no CouchDB? • Flessibilità del modello dati • Facilità di dialogo con PHP • Contesto non distribuito • Durevolezza non fondamentale • Prestazioni • Flessibilità di query
LE QUERY IN COUCHDB: MAP REDUCE
Quante visioni hanno avuto i film in totale?
{
"_id": "39c7c57daddba704c2b04606de001373",
"info_type": "view",
"movie": "The Gladiator",
"views": 37
}
{
"_id": "39c7c57daddba704c2b04606de000a2f",
"info_type": "view",
"movie": "Spiderman",
"views": 10
}
{
"_id": "39c7c57daddba704c2b04606de000c92",
"info_type": "view",
"movie": "Shrek",
"views": 25
}
{
"movie": "Spiderman",
"views": 10
}
{
"movie": "The Gladiator",
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
{
"movie": "Spiderman",
"views": 10
}
{
"movie": "The Gladiator",
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
{
"movie": "Spiderman",
"views": 10
}
{
"movie": "The Gladiator",
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
{
"movie": "Spiderman",
"views": 10
}
{
"movie": "The Gladiator",
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
72
4
5
{
"movie": "Spiderman",
"views": 10
}
{
"movie": "The Gladiator",
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
72
MAP
4
6
{
"movie": "Spiderman",
"views": 10
}
{
"movie": "The Gladiator",
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
72
REDUCE
function(doc) {
if (doc.info_type == 'view') {
emit(doc.movie, doc.views);
}
}
Map:
Reduce: function (key, values, rereduce) {
return sum(values);
}
{
"_id": "39c7c57...",
"info_type": "view",
"movie": "The Gladiator",
"views": 37
}
function(doc) {
if (doc.info_type == 'view') {
emit(doc.movie, doc.views);
}
}
Map:
Reduce: function (key, values, rereduce) {
return sum(values);
}
{
"_id": "39c7c57...",
"info_type": "view",
"movie": "The Gladiator",
"views": 37
}
Il problema è qui!
“Hu(mongo)us”
Cos’è MongoDB: • Datastore Documentale (JSON) • Protocollo Binario • Update in place -> locks! • Flessibilità nelle query
Performance VS Data Safety
Le impostazioni predefinite (32bit e <v2.0) sono “rischiose” (no journal)
Replica Set
Failover
A cosa fare attenzione?
• Nomi su database/collection: su errore, lui crea le entità specificate senza avvisare*
• Ordinamenti senza indici: raggiunto un certo quantitativo di dati non rallenta ma errore*
• Non farsi coinvolgere dalla flessibilità di query e cercare di costruirci sopra DB con relazioni
* esperienze con driver PHP
TUTTO APPOSTO SIGNORE!
Cosa ci serve per un sistema di monitoring?
• Performance • Semplicità • Expiration automatico dei valori • Gestione del cold start • Non è un problema la perdita di dati
-> Ok persistenza volatile, no replicazione
Perchè no CouchDB, MongoDB?
• Couch occupa troppo spazio, troppo lento • MongoDB non supportava TTL • Ci basta qualcosa di molto più semplice
“Hey that’s Merz!”
Cos’è Redis?
• Key/Value++ • Protocollo Binario • Salva su RAM (snapshot su disco, evita
problema cold start) • Necessario avere abbastanza RAM
Dialogare con Redis
// Memorizzare un valore
> SET status ok
// Collezioni
> SADD luci_accese camera bagno
// Valore con scadenza prefissata
> SET status ok
> EXPIRE status 10 // in secondi
COME STANNO ANDANDO LE COSE?
DI COSA PARLIAMO?
Simuliamo un’esperienza d’uso
Simuliamo un’esperienza d’uso
Simuliamo un’esperienza d’uso
Simuliamo un’esperienza d’uso
G=(V,E)
Quali sono state le applicazioni più usate?
Database Relazionale
O(log N) O(log M) O(log N)
Grafo
O(1)
O(1)
Reperimento nodi adiacenti diretto, senza necessità di consultare un indice
“Multiple datamodels support”
Modello Dati
Di cosa parliamo?
“Interrogazioni“ con Stack Tinkerpop o SQL+
ACID Atomic Consistent Isolated Durable
BASE Basic Available Soft State Eventually Consistent
Quindi non ho atomicità?
Ordine
Oggetto 1 Oggetto 2
Cliente
Aggiornamento ordine
DATABASE RELAZIONALI
NOSQL
Aggregate Data Model
order_id = 1001
date = 2012-11-10
total_amount = 10.00€
name = Johnny
surname = Appleseed
product_name: Pear
quantity: 2
item_price: 2.50€
total_price: 5.00€
product_name: Mango
quantity: 1
item_price: 5.00€
total_price: 5.00€
SCHEMALESS IS A LIE!
Dati
Room TV Pannello Controllo
Analisi Statistiche
Metadati
API
Dati hotel
API
Statistiche
API
Room TV Pannello Controllo
Analisi Statistiche
POLYGLOT PERSISTANCE
TRADEOFFS
VELOCITÀ VS PERSISTENZA
DISPONIBILITÀ VS COERENZA
SOLIDITÀ, AFFIDABILITÀ
E IL MODELLO DATI?
Dimensioni
Complessità
Key Value
Colonne
Documentale
A grafo
> 90% dei casi d’uso
Tratto da: http://www.slideshare.net/emileifrem/an-overview-of-nosql-jfokus-2011
KEY/VALUE
DOCUMENTALE
GRAFO
A COLONNA
COSA PORTARE A CASA?
DATABASE RELAZIONALI
DATASTORE NOSQL
GRAZIE
DOMANDE?
Nome speaker
Mail speaker – company or community
http://www.hubme.in/
Eventi di rilievo nell’Information Technology
Nome speaker
Mail speaker – company or community
http://friuli.grusp.org/
Nome speaker
Mail speaker – company or community
http://www.mvassociati.it/
Serve aiuto con architetture NoSQL?
Per approfondire
Per approfondire
Per approfondire
Nome speaker
Mail speaker – company or community
http://www.flickr.com/photos/leandrociuffo/4128603357/
http://www.flickr.com/photos/uggboy/8043043095/
http://www.flickr.com/photos/47108884@N07/6949078701/
http://www.flickr.com/photos/22750018@N05/4268345597/
http://www.flickr.com/photos/latt/509790815/
http://www.flickr.com/photos/iita-media-library/4808291918/
http://www.flickr.com/photos/portofsandiego/7777282856/
http://www.flickr.com/photos/shareandenjoy/7074965023/
http://www.flickr.com/photos/miggslives/5351504116/
http://www.flickr.com/photos/jabb/6956142046/
http://www.flickr.com/photos/mr_g_travels/863720665/
http://www.flickr.com/photos/polkadotcreations/2480587587/
http://www.flickr.com/photos/ppym1/387781444/
http://www.flickr.com/photos/ephotion/171928602/
http://www.flickr.com/photos/sepehrehsani/5766453552/
http://www.flickr.com/photos/jpstanley/69523927/
http://www.flickr.com/photos/lodigs/2833648828/
http://www.flickr.com/photos/freefoto/3844247553/
http://www.flickr.com/photos/ilri/7839428936/
http://www.flickr.com/photos/maugiart/5014963068/
http://www.flickr.com/photos/toptechwriter/3069396941/
http://www.flickr.com/photos/31492524@N00/3801200094/
http://www.flickr.com/photos/iita-media-library/5762064624/
http://www.flickr.com/photos/gewitterhexer/5540504147/
http://www.flickr.com/photos/djnordic/167433120/
http://www.flickr.com/photos/aidanwojtas/5879866927/
http://www.flickr.com/photos/dhwright/8012651441/
http://www.flickr.com/photos/capcase/4970062870/
http://www.flickr.com/photos/birminghammag/7979485144/
Photo Credits:
Nome speaker
Mail speaker – company or community
Il know how utilizzato per la preparazione di questa presentazione è stato in buona parte acquisito durante lo sviluppo del sistema Hotel OnAir di concezione e proprietà di VDA Multimedia Spa, cui il case study di cui si è fatto accenno fa riferimento. Ringrazio il team leader del progetto, Stefano Brenelli, e tutto il team di sviluppo, per l'interessante, edificante e proficua collaborazione. In particolare ringrazio: Carlo Anselmi, Maurizio Battistella, Manuel Bitto, Nicola Busanello, Antonino Murador, Antonio Parrella, Nicola Pressi, Stefano Valle, Riccardo Zamuner, Michele Zanon, Tiziano Zonta. Ringrazio anche i colleghi Diego Drigani e Dario Tion, nonchè tutto il PUG Friuli per i sempre utili confronti e consigli.