1. Web scalabile con Nginx e MongoDB
ovvero
NOSQL e nuovi demoni HTTP alla base della scalabilità del web
Diego Guenzi
Collaboratore - Area Distributed Computing
Direzione Progettazione e Gestione Risorse
1
2. Problematiche & obiettivi
• Individuare alternative rispetto a prodotti
(spesso) commerciali di memorizzazione dati
• Analisi per CSI Piemonte
• Requisiti:
– Specificità (vs general purpose)
– Utilizzo di commodity hardware
– Operare in ambienti distribuiti / cloud
– Opensource (=ridurre i costi ed evitare il più
possibile vendor lock-in)
– Possibilità di scalare orizzontalmente e
verticalmente, sia per lo storage, sia per la
capacità di calcolo
– Tolleranza ai guasti e robustezza
• Paper GARR 2010 di Torino
2
3. NOSQL
• Movimento che promuove una classe non ben
definita di strumenti di archiviazione di dati
• Not Only SQL:
– Non è un movimento contro l’SQL
– Esistono delle alternative ai RDBMS
– The right tool for the job
• Strumenti nati per ambienti distribuiti, dove
l'eccezione è l'uso su macchine stand-alone
• Si differenziano dai RDBMS:
– Non utilizzano il tradizionale SQL
– Non adottano schemi tabellari fissi (dati semi-
strutturati)
– Evitano join
– Scalano facilmente su commodity hardware
3
4. Scalabilità
• Verticale
– Potenziamento hardware
– Costo esponenziale
• Orizzontale
– Numero di macchine
– Costo lineare
4
5. Scalabilità RDBMS
• Verticale
– OK
• Orizzontale
– Problematica: tecniche
complesse con degrado delle
performance
5
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!
7
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
8
13. 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!
13
14. Il teorema CAP
Consistency
C Consistenza – Ogni client
ha la stessa visione dei dati
DBMS NOSQL RDBMS
CP Teorema CA
CAP:
due su tre
P A
PA
DBMS NOSQL
Availability
Partition Tolerance Disponibilità – Ogni client può
Tolleranza al partizionamento – Il sempre leggere e scrivere, dato
sistema funziona correttamente che il servizio risulta sempre
nonostante il partizionamento attivo e funzionale
della rete
14
15. Teorema CAP - CA
• Filosofia adottata nei RDBMS tradizionali
• Evitare il network partitioning tenendo i dati in
un unico punto
• Non scala orizzontalmente
15
16. 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
16
17. 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
17
18. ACID vs BASE
• Atomicity, • Basically
• Consistency, available,
• Isolation & • Soft state &
• Durability • Eventually consistent
RDBMS DBMS NOSQL
18
29. I data model
Modello dei dati nei DBMS NOSQL Esempi di DBMS NOSQL
● Chiave-Valore ● Berkley DB
● MemcacheDB
● Redis
● Dynamo
● Voldemort
● Orientato alle colonne ● BigTable
● Hypertable
● HBase
● Cassandra
● Orientato ai documenti ● SimpleDB
● CouchDB
● Riak
● MongoDB
● Orientato ai grafi ● Neo4j
29
30. Benchmarking: YCSB
• Yahoo Cloud Serving Benchmark.
• Una piattaforma comune per il benchmarking
dei DBMS NOSQL (e non solo).
30
31. MongoDB
• Architettura orientata ai documenti
(formato JSON/BSON)
• Software opensource scritto in C++
utilizzato da grossi siti quali bit.ly,
github.com e sourceforge.net
• 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)
31
32. Architettura (base e replica)
Client / Server
• Basata su due processi
• Il client può essere sia un applicativo
utente, sia la shell di MongoDB
Replica set
• Estensione del client / server
• Più di un processo server, che
dialogano fra loro per sincronizzare i
dati
32
33. Architettura (sharding)
Sharding
• Si aggiungono un config server (metadati) e
un mongos (instradamento delle richieste)
• I dati sono partizionati all'interno dei mongod
33
34. Architettura (sharding+replica)
Sharding + Replica set
• La configurazione più completa, per avere
fault tolerance e bilanciamento
34
36. Infinite possibilità
• Creazione di un'appliance
con MongoDB
• Stile Oracle Exadata
Database Machine
• Mongo-in-a-box
=
36
37. 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
37
38. Standard del mondo NOSQL
• Carenza di linguaggi e protocolli standard
• Tecnologia recente e, a volte, parzialmente
immatura
• Esistenza di diversi tentativi di
standardizzazione tramite layer comuni ai
DBMS
– Pig e Hive
– SPARQL
– GUI con supporto multi-DB
– Wrapper / Driver per API multi-DB
38
39. Server web e C10K
• Avere uno storage scalabile non è tutto
• Anche i web server devono scalare facilmente
• Sfida: 10.000 connessioni HTTP contemporanee
• Nuovi server oltre ad Apache e IIS
– costruiti su linee progettuali differenti
– lightweight
– riescono a superare le 10.000 connessioni
contemporanee (risolvono il problema C10K)
39
41. Un demone HTTP ottimizzato
• Utilizzato come web server, load balancer e proxy
sotto licenza BSD-like
• Supporta lo streaming di FLV e MP4
• Permette l'uso di SSL e TLS
• Più leggero e veloce: utilizza un’architettura di tipo
event-driven (asincrona) invece dei classici thread
• Gestisce un numero di connessioni maggiore rispetto
agli altri prodotti presenti sul mercato
41
43. Apache non molla
• Apache HTTP server gode di:
– forte integrazione con i pannelli di controllo per
hosting
– un numero elevato di moduli ed estensioni
– una presenza sul mercato pluriennale (1995)
• I nuovi server web (e Nginx primo fra tutti) offrono
prestazioni migliori ma:
– sono spesso poco supportati da altri applicativi
(perché poco diffusi)
– i moduli e le estensioni disponibili sono ancora
limitati (ma in rapido aumento)
– sono ancora piuttosto immaturi (sebbene stabili)
43
47. Architetture web scalabili - 3/3
• Scalabilità orizzontale su 3 livelli
• Aggiungo macchine solo dove
serve
• Eventuale load balancer ulteriore
47
48. Alcuni test di fault tolerance
• Down di una macchina del DB tollerato senza interruzione
del servizio
– Numero di macchine variabile in base al fattore di
replica e di sharding, alla presenza di un arbiter e al
peso dei nodi
– Conseguente ripristino del servizio con
sincronizzazione automatica
• Fallimento di un supporto di memorizzazione →
Sincronizzazione automatica recuperando i dati da un altro
nodo appartenente allo stesso replica set
• Down di un nodo PHP → Nginx sposta il carico in
automatico sull'altro (o sugli altri) nodo
– Al ritorno on-line, ribilanciamento automatico da parte
di Nginx
48
49. Test di paragone - 1/4
vs
• Dell PowerEdge R610
– Dual Xeon quad core L5520
– 32Gb RAM
– 160 Gb SAS local storage
49
50. Test di paragone - 2/4
vs
1600
1400
1200
Tempo di esecuzione
1000
800
Apache
600 Nginx
400
200
0
1 2 3 4 5 6 7 8 9 10
# test 1600
1400
1200
Tempo di esecuzione
1000
Pre-ottimizzazione
800
MongoDB
600 MySQL
400
200
0
1 2 3 4 5 6 7 8
# test
50
51. Test di paragone - 3/4
vs
700
600
Tempo di esecuzione
500
400
Apache
300
Nginx
200
100
0
1 2 3 4 5 6 7 8 9 10
# test
700
600
Tempo di esecuzione
500
400
Post-ottimizzazione 300
MongoDB
MySQL
200
100
0
1 2 3 4 5 6 7 8
# test
51
52. Test di paragone - 4/4
700
600
Tempi di esecuzione
500
400
Cassandra
300 MongoDB
MySQL
200
100
0
1 2 3 4 5 6 7 8
# test (1-4 = Apache, 5-8 = Nginx)
800
700
600
Errori non-2xx
500
400 Cassandra
MongoDB
300
MySQL
200
100
0
1 2 3 4 5 6 7 8
# test (1-4 = Apache, 5-8 = Nginx)
52
53. Conclusioni
Pillola azzurra, fine della storia:
domani ti sveglierai in camera tua, e
crederai a quello che vorrai
Pillola rossa, resti nel paese delle
meraviglie, e vedrai quant'è profonda
la tana del bianconiglio
53
54. Contatti
http://www.mongotorino.org
diego.guenzi@csp.it
rodolfo.boraso@csp.it
CSP innovazione nelle ICT
Sede
via Livorno 60 - 10144 Torino
Edificio Laboratori A1
Tel +39 011 4815111
Fax +39 011 4815001
E-mail: info@csp.it
Seconda sede operativa
Villa Gualino - Viale Settimio Severo 63
10133 Torino
www.csp.it
54