nosql, no worries: vecchi problemi, nuove soluzioni

NoSQL, No Worries

Stefano Maraspin

MV Associati

Vecchi problemi, nuove soluzioni

@maraspin

PARTIAMO DA UN CASE STUDY

L’OBIETTIVO

Classico Stack LAMP/LAPP

DISTRIBUZIONE DATI, LOGICA

VOGLIAMO ALTA DISPONIBILITÀ…

…E COERENZA SUI DATI

Non potete avere tutto, ragazzi!

Prof. Eric Brewer http://www.cs.berkeley.edu/~brewer/

Non scordiamo neppure la latenza!

Consistency

Availability Partition Tolerance

Consistency


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


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",


"movie": "Spiderman",

"views": 10

}

{

"_id": "39c7c57daddba704c2b04606de000c92",


"movie": "Shrek",

"views": 25

}

{


"views": 10

}

{


"views": 37

}

{

"movie": "Shrek",

"views": 25

}

{


"views": 10

}

{


"views": 37

}

{

"movie": "Shrek",

"views": 25

}

10 37 25

{


"views": 10

}

{


"views": 37

}

{

"movie": "Shrek",

"views": 25

}

10 37 25

47 25

{


"views": 10

}

{


"views": 37

}

{

"movie": "Shrek",

"views": 25

}

10 37 25

47 25

72

4

5

{


"views": 10

}

{


"views": 37

}

{

"movie": "Shrek",

"views": 25

}

10 37 25

47 25

72

MAP

4

6

{


"views": 10

}

{


"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...",



"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...",



"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

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

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

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


http://friuli.grusp.org/

Nome speaker


http://www.mvassociati.it/

Serve aiuto con architetture NoSQL?

Per approfondire

Nome speaker


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/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/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


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.