Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB

Polyglot Persistance
Esempio di architettura basata
su PostgreSQL, CouchDB, MongoDB, Redis e OrientDB
DiTeDi, Udine - Italia 15-12-2012

REPERIMENTO FEEDBACK IMMEDIATO

Partiamo da stack LAMP/LAPP
11

Gestione "meta" dati di:
• Hotel
• Applicazioni
• Configurazioni
• Personalizzazioni
• Utenti
• ACL
• RELAZIONI tra essi
14

Modello relazionale
15
Film
Titolo
Nome Categoria
Rating Categoria
Anno
Visioni
Gradimenti
Voto

Diamo un’occhio ai dati…
16
E se voglio cambiare rating per i drammatici?

Come sono memorizzati i dati
19

E se vogliamo un report?
20
SELECT film_normal.* , categoria.*
FROM film_normal
JOIN categoria on categoria.id = film_normal.categoria_id

JOIN: Operazione impegnativa
21
X
Morale: considerare sempre i benefici della normalizzazione. Ci torniamo tra poco!

Indici
22
EXPLAIN ANALIZE SELECT …
O(N) -> O(log N)

PostgreSQL vs MySQL
23
Idea: SELECT titolo, max(visioni) FROM film;
Qual’è il film più visto?

MySQL
24
SELECT titolo, max(visioni) FROM film;

PostgreSQL
25
SQL error:
ERROR: column "film.titolo" must appear in the GROUP BY clause or
be used in an aggregate function at character 8
In statement:

PostgreSQL
26
SQL error:
ERROR: column "film.titolo" must appear in the GROUP BY clause or
be used in an aggregate function at character 8
In statement:

27
Disclaimer: Ciò non significa che non utilizziamo anche MySQL in determinati contesti
Ocio però!

Perchè cio?
28
Risultato
Casuale

Possibile Soluzione
30
CREATE VIEW film AS
SELECT titolo, anno, visioni FROM film_provider1
UNION
SELECT titolo, anno, visioni FROM film_provider2;

Supporto per Ereditarietà
33
CREATE TABLE film (
id integer NOT NULL,
titolo character varying(50),
anno integer,
visioni integer
);
CREATE TABLE film_provider1 (
gradimenti integer
) INHERITS (film);
CREATE TABLE film_provider2 (
voto integer
) INHERITS (film);

Comportamento dell’Ereditarietà
34
select * from film; select * from film_provider1;

Write Ahead Log (Journal)
• Apri il Log
• Scrivici informazioni tipo “Questo dato va
qui (offset)”
• Scrivi il file
• Tenta il salvataggio su disco (fsync)
• Modifica i dati
• Segna sul Log che le operazioni sono
state compiute
35
http://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/

Replicazione con LOG – 8.4
38

Replicazione Streaming - 9.0
39

Replicazione Sincrona - 9.1
40

Cosa portare a casa:
• Solido e Affidabile (Ingres 1974)
• Potenti strumenti di programmazione
(PL/PGSQL, PL/Python, PL/Java, ...)
• Object-Relational Database (eredità)
• Interessanti add-ons (IE fuzzystrmatch)
• Replicazione Master/Slave Integrata
• PostGIS
• Community estesa, know how consolidato
42

Non potete avere tutto, ragazzi!
Prof. Eric Brewer
http://www.cs.berkeley.edu/~brewer/

Se volete distribuire una base
dati, qualora si venga a creare
un partizionamento, dovete
scegliere tra coerenza dei dati
e disponibilità del servizio.
CAP Theorem, Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility
of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume
33 Issue 2 (2002), pg. 51-59.

Vediamo che significa
53
Uno o più nodi
non raggiungibili:
partizonamento

Vediamo che significa
54
HotelFarm
Uno o più nodi
non raggiungibili:
partizonamento

Non scordiamo neppure la latenza!

CAP Theorem
58
Consistency
Availability
Partition
Tolerance

Soluzioni disponibili
59
Consistency
Availability
Partition
Tolerance
Categoria CP:
BigTable
Hbase
MongoDB
Redis
Memcached
etc.
Categoria CA:
RDBMS
etc.
Categoria AP:
DynamoDB
CouchDB
Cassandra
SimpleDB
Tokyo Cabinet
Riak
Voldemort
etc.

60
Consistency
Availability
Partition
Tolerance
Categoria CP:
BigTable
Hbase
MongoDB
Redis
Memcached
etc.
Categoria CA:
RDBMS
etc.
Categoria AP:
DynamoDB
CouchDB
Cassandra
SimpleDB
Tokyo Cabinet
Riak
Voldemort
etc.

Come abbiamo scelto?
• Supporto multi-master
• Facilità di sincronizzazione applicazione
• Flessibilità del modello dati
• Semplicità
61

62
Consistency
Availability
Partition
Tolerance
Categoria CP:
BigTable
Hbase
MongoDB
Redis
Memcached
Scalaris
etc.
Categoria CA:
RDBMS
GreenPlum
etc.
Categoria AP:
DynamoDB
CouchDB
Cassandra
SimpleDB
Tokyo Cabinet
Riak
Voldemort
etc.

63
“designed with the web in mind”

Cos’è CouchDB?
• Datastore Documentale (JSON)
• Interfaccia HTTP
• Replicazione master-master (con filtri)
• Può contenere applicazioni Web
HTML/CSS/JS (Couchapp)
• Pensato per contesti distribuiti
• Un progetto dalla storia “travagliata”
64

Incontriamo Futon (demo live)
65

Replicazione Semplice
68
Supporto per modalità PULL e PUSH

Ma Semplice Davvero!
69
Aggiornati non solo i dati ma anche le viste (design docs)

Scenario di conflitto
70
CouchDB – The definitive guide – O’Reilly

Risoluzione del Conflitto
71
CouchDB – The definitive guide – O’Reilly

Versioni
• ID / _rev
• Meglio generare da se gli ID (sequenziali)
• Aggiornamenti atomici sui documenti
• Aggiornamento ottimista, MVCC
• Coerenza Eventuale
72

POSSIAMO RISOLVERE I CONFLITTI

Progettiamo per evitarli
75
{
"titolo": "Il Padrino",
"sommario": "..."
"visioni": 3873,
"gradimenti": 185,
}
Provider Camera 1
Camera 2

76
{
"sommario": "...",
"visioni": 3873,
"gradimenti": 185,
}
Provider Camera 1
Camera 2
{
"sommario": "...",
"visioni": 3873,
"gradimenti": 185,
}

77
{
"sommario": "..."
}
Provider Camera 1
Camera 2
{
"visioni": 3873,
"gradimenti": 185,
}
MVCC

78
{
"sommario": "..."
}
Provider Camera 1
Camera 2
{
"visioni": 3873,
"gradimenti": 185,
}
{
"visioni": 3873,
"gradimenti": 185,
}
{
"sommario": "..."
}

WebApps Generate Server Side
87

Alto consumo di disco
90
0
2000
4000
6000
8000
10000
12000
14000
16000
DB Size (MB)
NB Quanto sopra su update!

Btree+, che Succede?
91
Questione di affidabilità, performance

COMPATTIAMO QUANDO POSSIBILE…

Indicatori di Performance
• 350 evt/sec in inserimento
• 3000 evt/sec se in batch mode
• 100 evt/sec su update
• 10 evt/sec durante compattazione
93
• 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

Da considerare:
• Inerentemente più rischioso
• Più onerosa la manutenzione e il backup
degli shard
• Delicato decidere con quali criteri
• In SQL: “Join” tra shards costosi.
Replicazione delle tabelle “globali” – es.
categorie film
99

Recap su CouchDB:
• Ottima soluzione per contesti distribuiti
• Non adatto per situazioni con frequenti
aggiornamenti e carichi (ingenti) costanti
• API REST aiuta a scalare le letture
• Bigcouch in aiuto sulle scritture
• Architetture innovative con le Couchapp
• Si possono usare strumenti Tipici Web:
HAproxy, Nginx
101

Da Tenere a Mente:
• Attenzione alla generazione degli ID,
specie se distribuiti
• Lo spazio su disco cresce e la
compattazione «inchioda» lo strumento
• I «driver» disponibili non sempre sono di
alta qualità...
102

Da Tenere sotto controllo:
• TouchDB
database CouchDB compatibile,
adatto all’embedding in device
mobili
• PouchDB
libreria js: come avere
CouchDB nel browser
103

“L’aggregatore”
105
RSS
Previsioni meteo
Vimeo
Eventi
...
Aggregatore

Architettura dell’aggregatore
106
RSS
Previsioni meteo
Vimeo
Eventi
...
REST API Crawler
CDN

Cosa scegliamo?
107
RSS
Previsioni meteo
Vimeo
Eventi
...
REST API Crawler
CDN
?

Cosa ci serve?
• Semplicità
• Facilità di dialogo con PHP
• Scalabilità sulle letture
• Flessibilità di query
108

Perché no CouchDB?
• Semplicità
• Facilità di dialogo con PHP
• Scalabilità sulle letture
• Flessibilità di query
109

Quante visioni hanno
avuto i film in totale?

113
{
"_id": "39c7c57daddba704c2b04606de001373",
"info_type": "view",
"movie": "The Gladiator",
"views": 37
}
{
"_id": "39c7c57daddba704c2b04606de000a2f",
"movie": "Spiderman",
"views": 10
}
{
"_id": "39c7c57daddba704c2b04606de000c92",
"movie": "Shrek",
"views": 25
}

114
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}

115
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25

116
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25

117
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
72

118
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
72
MAP

119
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25
47 25
72
REDUCE

In CouchDB
120
function(doc) {
if (doc.info_type == 'view') {
emit(doc.movie, doc.views);
}
}
Map:
{
"_id": "39c7c57...",
"views": 37
}

Cosa fa il map?
121
Map:
function(doc) {
if (doc.info_type == 'view') {
emit(doc.movie, doc.views);
}
}
{
"views": 10
}
{
"views": 37
}
{
"movie": "Shrek",
"views": 25
}
10 37 25

Cosa fa il reduce?
122
Reduce:
function (key, values, rereduce) {
return sum(values);
}
10 37 25
47 25

Dov’è il problema?
123
function(doc) {
if (doc.info_type == 'config') {
for (param in doc.params) {
emit(param, doc.params[param]);
}
}
}
Map:
Reduce:
.... Non possiamo avere parametri in input!
Viste precalcolate su
ciascun documento

About MongoDB
• Datastore Documentale (JSON)
• Database / Collezioni
• Protocollo Binario
• Tanto Marketing
• Veloce quasi come /dev/null :-P
• Update in place -> locks!
• Flessibilità nelle query
• Autosharding
125

Interagire con il DB è banale
126

Query
128
// operatori di confronto
db.notizie.find({tipo: {$ne: ‘cnn’},
ora_reperimento: {$gt: 1352505039}
});
// eventi di oggi e (necessariamente) domani
db.evento.find( { data: { $all: [ ‘2012-11-10’,
‘2012-11-11’ ] } } );
// eventi di oggi e/o domani
db.evento.find( { data : { $in : [‘2012-11-10’
‘2012-11-11’ ] } } );
// eventi di una giornata sola
db.evento.find( { data : { $size: 1 } } );
// cerca dentro gli array
db.previsioni.find( { ‘settimana.temp_max’ : 20 } );

Performance VS Durevolezza
129
Le impostazioni predefinite (32bit e <v2.0) sono “rischiose” (no journal)

Performance VS Durevolezza
130
MongoDB a 32bit NON VA USATO in PRODUZIONE!

Replica Set
131
http://docs.mongodb.org/manual/core/replication/

Recap su MongoDB:
• Semplice (arma a doppio taglio!)
• Linguaggio d’interrogazione potente
• Ottima documentazione
• Flessibilità nella configurazione
• Driver disponibili per molti linguaggi
• Sviluppo molto attivo
• Supporto
133

Fare attenzione a:
• Opzione safe, journaling
• Si inchioda negli ordinamenti se non
definiti indici
• Attenzione ai nomi!
• Non farsi coinvolgere e cercare di
costruirci sopra DB relazionali
134

Cosa abbiamo considerato?
• Performance
• Semplicità
• Expiration automatico dei valori
• Gestione del cold start
• Non è un problema la perdita di dati
-> Ok persistenza volatile, no replicazione
137

Perchè no Couch/Mongo?
• Couch occupa troppo spazio, troppo lento
• MongoDB poteva starci (soprattutto
perché TTL introdotte da poco – 12/09);
• Ma ci sono soluzioni più semplici…
138

139
“An open source, advanced key-value store”

About Redis
• Key/Value++
• Progetto Italiano (Salvatore Sanfilippo)
• Protocollo Binario
• Sponsorizzato da VMWare
• Gestione expiry delle chiavi
140

Esempi di query
141
// Memorizzare un valore
> SET status ok
// Collezioni
> SADD luci_accese camera bagno
// Valore con scadenza prefissata
> SET status ok
> EXPIRE status 10 // in secondi

Recap su Redis:
• E’ molto veloce
• Salva su RAM (snapshot su disco)
• E’ un’ottima soluzione di caching,
evitando problema cold start
• Necessario avere abbastanza RAM
• Può essere usato per delegare alcuni
calcoli costosi
143

Cosa ci serve?
• Gestire grandi moli di dati
• Modello di dati che supporti correlazione
146

Com’è fatta una nostra app?
147

Cosa ci ricorda tutto ciò?
152

Con strumenti visti prima…
• Query di Couch poco flessibili
• Redis assenza indici secondari
• MongoDB e Postgres forse ok ma limiti
nel traversare nodi non immediatamente
adiacenti
155

Troviamo le visite a partire dalla
dashboard in un determinato periodo

Con RDBMS
157
SELECT p1 . * , p2 . * , v . *
FROM pagina AS p1
JOIN visita AS v ON v.pagina_da = p1.id
JOIN pagina AS p2 ON v.pagina_a = p2.id
WHERE p1.id =1
AND v.data_visita >0
AND v.data_visita <4

Il problema…
158
SELECT p1 . * , p2 . * , v . *
FROM pagina AS p1
JOIN visita AS v ON v.pagina_da = p1.id
JOIN pagina AS p2 ON v.pagina_a = p2.id
WHERE p1.id =1
AND v.data_visita >0
AND v.data_visita <4
O(log N) O(log M) O(log N)

Invece con un grafo:
159
O(1)
O(1)
Adiacenza senza necessità di consultare un indice!

160
“Multiple datamodels support”

https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model

Interagire con OrientDB
• Protocollo binario / REST
• JSON
• Tinkerpop Stack: Gremlin, Pipes
• SQL(+)
163

Select titolo, in.out.in.nome from #16:5

Replica Master-Master
Sync/Async - Configurabile
165

Recap su OrientDB:
• Ottima soluzione per gestire relazioni
• Traversa 5 Milioni+ di record/sec
• Progetto Italiano (Luca Garulli)
• ACID
• Supporta ereditarietà
• Semplice da installare e avviare
166

Ringraziamento
168
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.
Ringraziamo il team leader del progetto, Stefano Brenelli, e tutto il team
di sviluppo, per l'interessante, edificante e proficua collaborazione. In
particolare ringraziamo: Carlo Anselmi, Maurizio Battistella, Manuel
Bitto, Nicola Busanello, Antonino Murador, Antonio Parrella, Nicola
Pressi, Riccardo Zamuner, Michele Zanon, Tiziano Zonta.
Ringraziamo anche i colleghi Diego Drigani e Dario Tion, nonchè tutto il
PUG Friuli per i sempre utili confronti e consigli.

Image Credits
• http://www.flickr.com/photos/leandrociuffo/4128603357/
• http://www.flickr.com/photos/uggboy/8043043095/
• http://www.flickr.com/photos/kky/704056791/
• http://www.flickr.com/photos/shareandenjoy/7074965023/
• http://www.flickr.com/photos/ivyfield/4497654857/
• http://www.flickr.com/photos/craigmarren/6086280669/
• http://www.flickr.com/photos/getbutterfly/6317955134/
• http://www.flickr.com/photos/62698615@N08/5948655391/
• http://20bits.com/article/interview-questions-database-indexes
• http://www.flickr.com/photos/iita-media-library/4808291918/
• http://www.flickr.com/photos/rrrodrigo/4139483872/
• http://www.flickr.com/photos/latt/509790815/
• http://www.flickr.com/photos/spine/525988813/
• http://www.flickr.com/photos/latt/509790815/
• http://www.flickr.com/photos/antmoose/116845021/
• http://www.flickr.com/photos/charleylhasa/3374499088/
• http://www.flickr.com/photos/mcascherrypoint/6277623762/
• http://www.flickr.com/photos/superk8/2801590280/
• http://www.flickr.com/photos/cawley/1067814030/
• http://www.flickr.com/photos/mr_g_travels/863720665/
• http://www.flickr.com/photos/cortesdecima/6099516346/
• http://www.flickr.com/photos/portofsandiego/7777282856/
• http://www.flickr.com/photos/petereed/132829587/
• http://www.flickr.com/photos/myfruit/7031263653/
• http://www.flickr.com/photos/maugiart/5014963068/
• http://www.flickr.com/photos/freefoto/3844247553/
• http://www.flickr.com/photos/incognito_rico/69242116/
• http://tinkerpop.com/
• http://www.slideshare.net/lvca/orientdb-distributed-architecture-11h
• ttp://www.flickr.com/photos/dobs/4128798936/
172

Grazie per l’attenzione
Stefano Maraspin
@maraspin
s.maraspin@mvassociati.it
Stefano Valle
@stefanovalle
s.valle@mvassociati.it

Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (9)

Similaire à Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB

Similaire à Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB (20)

Plus de Steve Maraspin

Plus de Steve Maraspin (20)

Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB