Web scalabile con Nginx e MongoDB                           ovveroNOSQL e nuovi demoni HTTP alla base della scalabilità de...
Problematiche & obiettivi• Individuare alternative rispetto a prodotti  (spesso) commerciali di memorizzazione dati• Anali...
NOSQL•   Movimento che promuove una classe non ben    definita di strumenti di archiviazione di dati•   Not Only SQL:     ...
Scalabilità              • Verticale                 – Potenziamento hardware                 – Costo esponenziale        ...
Scalabilità RDBMS           • Verticale              – OK           • Orizzontale             – Problematica: tecniche    ...
Scalabilità DB NOSQL           • Verticale              – OK           • Orizzontale             – OK                     ...
Solo scalabilità?• Scalare orizzontalmente => avere più macchine   – Fault tolerance   – Load balancing   – High availabil...
Shared-nothing vs shared-disk                  • Necessita di un                    numero minore di lock                 ...
Ambienti distribuiti - Pro10*1=1010*2=2010*3=3010*4=40                                   10*4=40                          ...
Fault tolerance          VS                  10
Ambienti distribuiti - Con                             11
Network partitioning                       12
Il teorema CAP• Congettura di Brewer  (2000), dimostrata da  Gilbert e Lynch (2002) e  divenuta un teorema• Consistency, A...
Il teorema CAP                                                  Consistency                               C               ...
Teorema CAP - CA• Filosofia adottata nei RDBMS tradizionali• Evitare il network partitioning tenendo i dati in  un unico p...
Teorema CAP - PA• Se si verifica un network partitioning, offriamo  una eventual consistency• Possibilità che si generino ...
Teorema CAP - CP• Se si verifica un network partitioning  “sospendiamo” o limitiamo il servizio• Possibilità che alcuni da...
ACID vs BASE•   Atomicity,   • Basically•   Consistency,   available,•   Isolation &  • Soft state &•   Durability   • Eve...
Replica                   Nome: “Mario”                   Cognome: “Rossi”                   Età: 48                      ...
Eventual consistency                   Nome: “Mario”                   Cognome: “Rossi”                   Età: 48         ...
Eventual consistency                   Nome: “Mario”                   Cognome: “Rossi”                   Età: 48         ...
Strong Consistency                   Nome: “Mario”                   Cognome: “Rossi”                   Età: 49           ...
Sharding                    Nome: “Mario”                    Cognome: “Rossi”                    Età: 49                  ...
Sharding                                                                     Nome: “Viola”                                ...
Basic Availability                                                                         ???                    Nome: “M...
Replica e sharding                       “Mario”,“Rossi”, 49                       “Ugo”,”Verdi”, 37                      ...
Il mercato             27
I prodotti             28
I data modelModello dei dati nei DBMS NOSQL       Esempi di DBMS NOSQL ●   Chiave-Valore                ●   Berkley DB    ...
Benchmarking: YCSB• Yahoo Cloud Serving Benchmark.• Una piattaforma comune per il benchmarking  dei DBMS NOSQL (e non solo...
MongoDB• Architettura orientata ai documenti  (formato JSON/BSON)• Software opensource scritto in C++  utilizzato da gross...
Architettura (base e replica)               Client / Server           •   Basata su due processi           •   Il client p...
Architettura (sharding)    Sharding•   Si aggiungono un config server (metadati) e    un mongos (instradamento delle richi...
Architettura (sharding+replica)    Sharding + Replica set•   La configurazione più completa, per avere    fault tolerance ...
Architettura fisica realizzata                                 35
Infinite possibilità                       •   Creazione di unappliance                           con MongoDB             ...
SQL scalabile• Una via di mezzo fra il mondo NOSQL e  quello relazionale:   – Uso di tabelle relazionali e di SQL   – Stes...
Standard del mondo NOSQL• Carenza di linguaggi e protocolli standard• Tecnologia recente e, a volte, parzialmente  immatur...
Server web e C10K•   Avere uno storage scalabile non è tutto•   Anche i web server devono scalare facilmente•   Sfida: 10....
Esempi di successo: un URL shortner                                      40
Un demone HTTP ottimizzato• Utilizzato come web server, load balancer e proxy  sotto licenza BSD-like• Supporta lo streami...
Utilizzo – Agosto 2011                                  Alcuni esempi:                                  http://sourceforge...
Apache non molla• Apache HTTP server gode di:   – forte integrazione con i pannelli di controllo per     hosting   – un nu...
Test pagine statiche                                                              Apache - Nginx - No KeepAlive           ...
Architetture web scalabili - 1/3                          •   Scalabilità orizzontale con                              mac...
Architetture web scalabili - 2/3                       •   Scalabilità orizzontale su 2 livelli                       •   ...
Architetture web scalabili - 3/3                       •   Scalabilità orizzontale su 3 livelli                       •   ...
Alcuni test di fault tolerance• Down di una macchina del DB tollerato senza interruzione  del servizio   – Numero di macch...
Test di paragone - 1/4             vs                    • Dell PowerEdge R610                       – Dual Xeon quad core...
Test di paragone - 2/4                                                                                                    ...
Test di paragone - 3/4                                                                                                    ...
Test di paragone - 4/4                      700                      600Tempi di esecuzione                      500      ...
Conclusioni              Pillola azzurra, fine della storia:              domani ti sveglierai in camera tua, e           ...
Contatti                                           http://www.mongotorino.org diego.guenzi@csp.itrodolfo.boraso@csp.itCSP ...
Upcoming SlideShare
Loading in...5
×

Presentazione mongo torino

669

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
669
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Presentazione mongo torino

  1. 1. Web scalabile con Nginx e MongoDB ovveroNOSQL e nuovi demoni HTTP alla base della scalabilità del web Diego Guenzi Collaboratore - Area Distributed Computing Direzione Progettazione e Gestione Risorse 1
  2. 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. 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 leccezione è luso 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. 4. Scalabilità • Verticale – Potenziamento hardware – Costo esponenziale • Orizzontale – Numero di macchine – Costo lineare 4
  5. 5. Scalabilità RDBMS • Verticale – OK • Orizzontale – Problematica: tecniche complesse con degrado delle performance 5
  6. 6. Scalabilità DB NOSQL • Verticale – OK • Orizzontale – OK 6
  7. 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. 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. 9. Ambienti distribuiti - Pro10*1=1010*2=2010*3=3010*4=40 10*4=40 10*5=5010*5=50 10*6=6010*6=60 10*1=1010*7=70 10*2=2010*8=80 10*3=3010*9=9010*10=10010*11=11010*12=12010*13=130 10*10=10010*14=140 10*11=11010*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. 10. Fault tolerance VS 10
  11. 11. Ambienti distribuiti - Con 11
  12. 12. Network partitioning 12
  13. 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. 14. Il teorema CAP Consistency C Consistenza – Ogni client ha la stessa visione dei datiDBMS NOSQL RDBMS CP Teorema CA CAP: due su tre P A PA DBMS NOSQL AvailabilityPartition Tolerance Disponibilità – Ogni client puòTolleranza al partizionamento – Il sempre leggere e scrivere, datosistema funziona correttamente che il servizio risulta semprenonostante il partizionamento attivo e funzionaledella rete 14
  15. 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. 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. 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. 18. ACID vs BASE• Atomicity, • Basically• Consistency, available,• Isolation & • Soft state &• Durability • Eventually consistent RDBMS DBMS NOSQL 18
  19. 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à: 48Cognome: “Rossi”Età: 48 19
  20. 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à: 48Cognome: “Rossi”Età: 49 20
  21. 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à: 49Cognome: “Rossi”Età: 49 21
  22. 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à: 49Cognome: “Rossi”Età: 49 22
  23. 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à: 56Cognome: “Gialli”Età: 50 23
  24. 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à: 56Cognome: “Gialli”Età: 50 24
  25. 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à: 56Cognome: “Gialli”Età: 50 25
  26. 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. 27. Il mercato 27
  28. 28. I prodotti 28
  29. 29. I data modelModello 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. 30. Benchmarking: YCSB• Yahoo Cloud Serving Benchmark.• Una piattaforma comune per il benchmarking dei DBMS NOSQL (e non solo). 30
  31. 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. 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. 33. Architettura (sharding) Sharding• Si aggiungono un config server (metadati) e un mongos (instradamento delle richieste)• I dati sono partizionati allinterno dei mongod 33
  34. 34. Architettura (sharding+replica) Sharding + Replica set• La configurazione più completa, per avere fault tolerance e bilanciamento 34
  35. 35. Architettura fisica realizzata 35
  36. 36. Infinite possibilità • Creazione di unappliance con MongoDB • Stile Oracle Exadata Database Machine • Mongo-in-a-box = 36
  37. 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. 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. 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. 40. Esempi di successo: un URL shortner 40
  41. 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 luso 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. 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. 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. 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. 45. Architetture web scalabili - 1/3 • Scalabilità orizzontale con macchine tutte identiche • Semplicità di gestione 45
  46. 46. Architetture web scalabili - 2/3 • Scalabilità orizzontale su 2 livelli • Load balancer separato 46
  47. 47. Architetture web scalabili - 3/3 • Scalabilità orizzontale su 3 livelli • Aggiungo macchine solo dove serve • Eventuale load balancer ulteriore 47
  48. 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 sullaltro (o sugli altri) nodo – Al ritorno on-line, ribilanciamento automatico da parte di Nginx 48
  49. 49. Test di paragone - 1/4 vs • Dell PowerEdge R610 – Dual Xeon quad core L5520 – 32Gb RAM – 160 Gb SAS local storage 49
  50. 50. Test di paragone - 2/4 vs 1600 1400 1200Tempo 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. 51. Test di paragone - 3/4 vs 700 600Tempo 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. 52. Test di paragone - 4/4 700 600Tempi 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. 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. 54. Contatti http://www.mongotorino.org diego.guenzi@csp.itrodolfo.boraso@csp.itCSP innovazione nelle ICTSedevia Livorno 60 - 10144 TorinoEdificio Laboratori A1Tel +39 011 4815111Fax +39 011 4815001E-mail: info@csp.itSeconda sede operativaVilla Gualino - Viale Settimio Severo 6310133 Torinowww.csp.it 54
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×