Presentazione mongo torino
Upcoming SlideShare
Loading in...5
×
 

Presentazione mongo torino

on

  • 770 views

 

Statistics

Views

Total Views
770
Views on SlideShare
770
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Presentazione mongo torino Presentazione mongo torino Presentation Transcript

    • 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
    • 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
    • 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
    • Scalabilità • Verticale – Potenziamento hardware – Costo esponenziale • Orizzontale – Numero di macchine – Costo lineare 4
    • Scalabilità RDBMS • Verticale – OK • Orizzontale – Problematica: tecniche complesse con degrado delle performance 5
    • Scalabilità DB NOSQL • Verticale – OK • Orizzontale – OK 6
    • 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
    • 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
    • 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
    • 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, Availability e Partition tolerance – Non si possono avere tutte e tre, al massimo due! 13
    • 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
    • Teorema CAP - CA• Filosofia adottata nei RDBMS tradizionali• Evitare il network partitioning tenendo i dati in un unico punto• Non scala orizzontalmente 15
    • 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
    • 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
    • ACID vs BASE• Atomicity, • Basically• Consistency, available,• Isolation & • Soft state &• Durability • Eventually consistent RDBMS DBMS NOSQL 18
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Il mercato 27
    • I prodotti 28
    • 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
    • Benchmarking: YCSB• Yahoo Cloud Serving Benchmark.• Una piattaforma comune per il benchmarking dei DBMS NOSQL (e non solo). 30
    • 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
    • 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
    • Architettura (sharding) Sharding• Si aggiungono un config server (metadati) e un mongos (instradamento delle richieste)• I dati sono partizionati allinterno dei mongod 33
    • Architettura (sharding+replica) Sharding + Replica set• La configurazione più completa, per avere fault tolerance e bilanciamento 34
    • Architettura fisica realizzata 35
    • Infinite possibilità • Creazione di unappliance con MongoDB • Stile Oracle Exadata Database Machine • Mongo-in-a-box = 36
    • 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
    • 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
    • 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
    • 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 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
    • 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
    • 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
    • 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
    • Architetture web scalabili - 1/3 • Scalabilità orizzontale con macchine tutte identiche • Semplicità di gestione 45
    • Architetture web scalabili - 2/3 • Scalabilità orizzontale su 2 livelli • Load balancer separato 46
    • Architetture web scalabili - 3/3 • Scalabilità orizzontale su 3 livelli • Aggiungo macchine solo dove serve • Eventuale load balancer ulteriore 47
    • 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
    • Test di paragone - 1/4 vs • Dell PowerEdge R610 – Dual Xeon quad core L5520 – 32Gb RAM – 160 Gb SAS local storage 49
    • 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
    • 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
    • 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
    • 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
    • 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