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

6. Scalabilità DB NOSQL
• Verticale
– OK
• Orizzontale
– OK
6

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

9. Ambienti distribuiti - Pro
10*1=10
10*2=20
10*3=30
10*4=40 10*4=40
10*5=50
10*5=50
10*6=60
10*6=60
10*1=10
10*7=70 10*2=20
10*8=80 10*3=30
10*9=90
10*10=100
10*11=110
10*12=120
10*13=130
10*10=100
10*14=140
10*11=110
10*15=150 10*12=120
VS 10*13=130
10*14=140
10*7=70
10*15=150
10*8=80
10*9=90
9

10. Fault tolerance
VS
10

11. Ambienti distribuiti - Con
11

12. Network partitioning
12

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

19. Replica
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Nome: “Mario” Età: 48
Cognome: “Rossi”
Età: 48
19

20. Eventual consistency
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Nome: “Mario” Età: 48
Cognome: “Rossi”
Età: 49
20

21. Eventual consistency
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Età: 48
Nome: “Mario”
Cognome: “Rossi”
Età: 49
Nome: “Mario”
Cognome: “Rossi”
Nome: “Mario” Età: 49
Cognome: “Rossi”
Età: 49
21

22. Strong Consistency
Nome: “Mario”
Cognome: “Rossi”
Età: 49
Nome: “Mario”
Cognome: “Rossi”
Età: 49
Nome: “Mario”
Cognome: “Rossi”
Età: 49
Nome: “Mario”
Cognome: “Rossi”
Nome: “Mario” Età: 49
Cognome: “Rossi”
Età: 49
22

23. Sharding
Nome: “Mario”
Cognome: “Rossi”
Età: 49
Nome: “Ugo”
Cognome: “Verdi”
Età: 37
Nome: “Antonio”
Cognome: “Bianchi”
Età: 30
Nome: “Viola”
Cognome: “Gialli”
Età: ??
Nome: “Marisa”
Cognome: “Azzurri”
Nome: “Viola” Età: 56
Cognome: “Gialli”
Età: 50
23

24. Sharding
Nome: “Viola”
Cognome: “Gialli”
Nome: “Mario” Età: 50
Cognome: “Rossi”
Età: 49
Nome: “Ugo”
Cognome: “Verdi”
Età: 37
Nome: “Antonio”
Cognome: “Bianchi”
Età: 30
Nome: “Marisa”
Cognome: “Azzurri”
Nome: “Viola” Età: 56
Cognome: “Gialli”
Età: 50
24

25. Basic Availability
???
Nome: “Mario”
Cognome: “Rossi”
Età: 49
Nome: “Ugo”
Cognome: “Verdi”
Età: 37
Nome: “Antonio”
Cognome: “Bianchi”
Età: 30
Nome: “Viola”
Cognome: “Gialli”
Età: ??
Nome: “Marisa”
Cognome: “Azzurri”
Nome: “Viola” Età: 56
Cognome: “Gialli”
Età: 50
25

26. Replica e sharding
“Mario”,“Rossi”, 49
“Ugo”,”Verdi”, 37
“Antonio”,”Bianchi”, 30 “Mario”,“Rossi”, 49
“Antonio”,”Bianchi”, 30
“Mario”,“Rossi”, 49
“Viola”,”Gialli”, 50
“Ugo”,”Verdi”, 37
“Viola”,”Gialli”, 50
“Ugo”,”Verdi”, 37 “Antonio”,”Bianchi”, 30
“Viola”,”Gialli”, 50
26

27. Il mercato
27

28. I prodotti
28

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

35. Architettura fisica realizzata
35

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

40. Esempi di successo: un URL shortner
40

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

42. Utilizzo – Agosto 2011
Alcuni esempi:
http://sourceforge.net/
http://www.yellowpages.com/
http://www.whitepages.com/
http://www.filestube.com/
http://www.torrentreactor.net/
http://www.scribd.com/
http://wordpress.com/
http://wordpress.org/
https://github.com/
http://www.rambler.ru/
http://www.yandex.ru/
http://www.hulu.com/
http://www.ohloh.net/
https://www.tumblr.com/
http://www.chinanews.com/
http://www.soso.com/
http://www.163.com/
http://twitpic.com/
http://new.evite.com/
http://yfrog.com/
http://www.simplyhired.com/
http://www.wikihow.com/
http://brainient.com/
http://www.examiner.com/
http://fastmail.fm/
http://autoregister.co.uk/
...
fonte:
42

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

44. Test pagine statiche
Apache - Nginx - No KeepAlive
Nginx
10000 Apache
8940,23
9000
8000
7007 6978,27 6936,81
6844,04
7000 6544,46 6634,11
5951,31 5873,25
6000
Requests/sec
5269,86
5000
4000
3000
2000
1000
381,18 367,11 366,68 373,96 320,57 372,28 366,63 302,61 369,88 384,00
0
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Concurrency
• HP Proliant G4
– Dual Xeon dual core
– 2Gb RAM
– 685 Gb Raid local storage
44

45. Architetture web scalabili - 1/3
• Scalabilità orizzontale con
macchine tutte identiche
• Semplicità di gestione
45

46. Architetture web scalabili - 2/3
• Scalabilità orizzontale su 2 livelli
• Load balancer separato
46

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