Laboratori diffusi: ricerca e innovazione per i territoriCSP Scarl
Laboratori diffusi: ricerca e innovazione nei e per i territori remoti presentazione a cura di Chiara Gallino per il convegno IREs Piemonte "Risorsa o Rischio? Il contributo delle terre alte allo sviluppo regionale" http://www.ires.piemonte.it/convegni/prog-seminario_IRES_AISRE_13-4-2012.pdf
Laboratori diffusi: ricerca e innovazione per i territoriCSP Scarl
Laboratori diffusi: ricerca e innovazione nei e per i territori remoti presentazione a cura di Chiara Gallino per il convegno IREs Piemonte "Risorsa o Rischio? Il contributo delle terre alte allo sviluppo regionale" http://www.ires.piemonte.it/convegni/prog-seminario_IRES_AISRE_13-4-2012.pdf
"Get Results With Email Marketing" is a dynamic presentation given by Simon Grabowski, CEO of GetResponse, at the e-nnovation conference in Poznan. It focuses on permission-based email marketing, email list building. Simon also shares proven email marketing strategies that can help to grow any business on the Internet.
Protecting Data in the Cloud: The Truth about SaaS BackupDatto
Backupify teamed up with IT community Spiceworks to produce a piece of research focused on how today's IT departments back up data in their SaaS applications. This slide deck reveals some surprising stats on how IT professionals deal with data in the cloud.
A brief description of the Kennedy Creek Dispersal in March 2015. Further information available at www.sheepgenetics.org.au and www.auctionsplus.com.au
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDBSteve Maraspin
Pirma parte del seminario su NoSQL al DiTeDi di Udine del 15/12/2012. Affrontato il caso di studio di un'architettura enterprise, basata su datastore relazionali (PostgreSQL) e non (CouchDB, MongoDB, Redis e OrientDB).
"Get Results With Email Marketing" is a dynamic presentation given by Simon Grabowski, CEO of GetResponse, at the e-nnovation conference in Poznan. It focuses on permission-based email marketing, email list building. Simon also shares proven email marketing strategies that can help to grow any business on the Internet.
Protecting Data in the Cloud: The Truth about SaaS BackupDatto
Backupify teamed up with IT community Spiceworks to produce a piece of research focused on how today's IT departments back up data in their SaaS applications. This slide deck reveals some surprising stats on how IT professionals deal with data in the cloud.
A brief description of the Kennedy Creek Dispersal in March 2015. Further information available at www.sheepgenetics.org.au and www.auctionsplus.com.au
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDBSteve Maraspin
Pirma parte del seminario su NoSQL al DiTeDi di Udine del 15/12/2012. Affrontato il caso di studio di un'architettura enterprise, basata su datastore relazionali (PostgreSQL) e non (CouchDB, MongoDB, Redis e OrientDB).
Ottimizzazione della gestione dei dati sul cloudNicolò Carandini
Lo spazio dei dati (3Vs): Volume, Velocità e Varietà
Il CAP theorem
Data Modeling
Data Platform Azure solutions
Big Data and ML Azure solutions
Cosmos DB
More Data Consistency options: Bounded staleness, Session, Consistent Prefix
Cosmos DB Security & Compliance
Quality Assurance with TLA+
A Case Study: Venice Time Machine
CCI2018 - Iperconvergenza con Windows Serverwalk2talk srl
Il tread dell’iperconvergenza aumenta sempre di più sia grazie al numero sempre crescente di standard (sd* e simili) sia grazie alla presenza di soluzioni ready to go.
Ma spesso le soluzioni proposte sono chiuse e difficilmente integrabili tra loro.
Windows Server (già dalla versione 2012) ha tutto quello che serve per implementare una soluzione iperconvergente out of the box.
In questa sezione andremo ad analizzare cosa ci serve e come possiamo realizzare un semplice cluster a due nodi, senza componenti di terze parti
By Andrea Garattini e Mario Serra
MySQL Tech Tour 2015 - Soluzioni di alta disponibilità con MySQLPar-Tec S.p.A.
Il TechAdvisor Michelangelo Uberti fornisce una panoramica generale inerente le soluzioni di alta disponibilità con MySQL.
I punti trattati durante la presentazione sono:
- Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise
- Cause, effetti e reali esigenze di HA
- Funzionamento, benefici e limiti dei principali approcci:
- Replica di database
- Cluster attivo/passivo
- Cluster attivo/attivo: shared-nothing
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su http://www.par-tec.it/soluzioni-di-alta-disponibilita-con-mysql
OBSERVO - Piattaforma Open Source per la videosorveglianza territorialeCSP Scarl
Grazie alla collaborazione degli Enti Locali e all'esperienza tecnologica di CSP, la Regione Piemonte ha sviluppato un software di videosorveglianza opensource che permette agli Enti Locali di dotarsi di impianti di videosorveglianza in modo scalabile, flessibile, senza elevati investimenti economici ma soprattutto seguendo linee guida comuni. Tra le funzionalità principali, la piattaforma Observo e il software di videosorveglianza implementano la gestione di planimetrie di luoghi indoor, il tracking real-time di mezzi mobili e di relativi impianti di videosorveglianza temporanea, aggiornamento automatico e sincronizzazione delle informazioni, gestione sicura degli accessi e dei profili utente nel completo rispetto delle normative vigenti.
Concludendo, lo scopo del progetto è testare un sistema che consenta di produrre innovazione in un settore, quello dei servizi di pubblica utilità, attraverso tecnologie di prevenzione situazionale, in cui negli anni sono stati prodotti significativi investimenti pubblici coinvolgendo una vasta eterogeneità di tecnologie differenti, talvolta obsolete. Il progetto Observo, infatti, si inserisce nell’azione che da anni la Regione Piemonte svolge per promuovere e sostenere politiche locali di sicurezza, attraverso la cooperazione di soggetti pubblici e privati, sperimentando strumenti innovativi volti a migliorare l’azione pubblica in materia di sicurezza urbana nonché incrementarne la percezione da parte dei cittadini. La sperimentazione della piattaforma Observo diviene utile, da un lato per promuovere un corretto ed efficace uso delle tecnologie destinate alla prevenzione situazionale (ad esempio per specifiche indagini territoriali), e dall’altro sarà un’occasione per affrontare a livello regionale le questioni connesse all’utilizzo dei sistemi di controllo mediante tecnologie.
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