Lo scopo della presentazione è quella di fornire una visione a 360 gradi su come realizzare un'architettura MongoDB su un'infrastruttura Cloud Amazon Web Services. La presentazione è suddivisa in quattro aree: - Introduzione di base su MongoDB - Preview delle caratteristiche di MongoDB 3 - Come organizzare architetture Replica Set e Sharding di MongoDB in VPC Cloud di Amazon Web Services - Introduzione alle logiche di Schema Design di MongoDB

1. @stefanodindo
Stefano Dindo
Deploy di MongoDB su infrastruttura AWS

2. Agenda:
• Introduzione a MongoDB
• MongoDB 3.0
• Deploy MongoDB su AWS
• Architetture MongoDB su AWS
• Backup
• Esempio architettura su AWS
• Schema Design
• Integrazione MongoDB su EMR

3. Capitolo 1
Introduzione a MongoDB

4. MongoDB è un database non relazione,
orientato ai documento, classificato come un
database NoSQL. MongoDB si allontana dalla
struttura tradizionale basata su tabelle dei
database relazionali in favore di documenti in
stile JSON con schema flessibile.
Cos’è MongoDB ?

5. General Purpose Document Database Open Source
MongoDB

6. Cos’è un documento per MongoDB?
{
“nome”: “Giorgio”,
“cognome”: “Rossi”,
“email”: “giorgio.rossi@gmail.com”,
“cell”: 3281432896,
“sport”: [“nuoto”, “calcio”]
}
MongoDB salva i documenti su disco in formato BSON (http://
bsonspec.org).
La dimensione massima di un documento BSON è 16MB.
Un documento è una struttura dati in stile JSON formata da
un numero variabile di coppie campo - valore

7. Agilità & Flessibilità
• Evoluzione semplice del modello di dati
• Adattamento e cambi rapidi sulla struttura dati
Rappresentazione dati intuitiva e naturale
• Sviluppatori sono più produttivi
• Le applicazioni risultano più semplici da gestire
Riduzione di operazioni di join e disk seek
• La programmazione è più semplice
• Maggiori performance
Benefici del modello a documenti

8. Better data locality Caching In-Place Updates
Performance
( solo per MMAPv1 )

9. SQL - Like Corrispettivo in MongoDB
Database Database
Tabella Collections
Riga Documents
Colonna Field
Terminologia

10. {
_id: ‘Objectid(“4b2b9…”)’,
first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: [45.123,47.232],
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
]
}
MongoDB: Modello a Documenti

11. Document
{
_id: ‘Objectid(“4b2b9…”)’,
first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: [45.123,47.232],
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
]
}
Esempio Tipi di dati
Null
Boolean
Number
String
Date
Array
Embedded documents
{ x: null }
{ x: true }
{ x: 3.14 } { x: 3 }
{ x: “zero12” }
{ x: new Date() }
{ x: [“a”,”b”, “c”] }
{ x: {y: “a” } }

12. Object id
0 1 2 3 4 5 6 7 8 9 10 11
Timestamp Machine PID Increment

13. Query Language
use <nome db>
show collections
db.<nomeCollection>.insert({…})
db.<nomeCollection>.findOne()
db.<nomeCollection>.update(<query>, <update>)
db.<nomeCollection>.remove(<query>)
db.<nomeCollection>.update(<query>, {$set: <update>})

14. Capitolo 2
MONGODB 3.0

15. Riduzione del carico fino a
Distribuzione globale fino a
nodi Replica Set
Fino a
occupazione di spazio
di storage con la compressione
miglioramento generale
delle performance
3.0
95%
50
80%
7 - 10x
Nuovo storage engine
WiredTiger

16. MongoDB Query Language + Native Drivers
MongoDB Document Data Model
MMAP v1 WiredTiger Altri
Sicurezza
Management
Repository
data
IoT Sensori
e servizi
Servizi
di
Advertising
Analisi dati Archiviazione
Storage Engine

17. Perché WiredTiger è interessante
• Concorrenza a livello di documento
• Compressione
• Consistenza senza journaling
• Performance migliori in determinate condizioni
• Operazioni di scrittura pesante
• Scalabilità verticale
• Migliore utilizzo delle risorse hardware
• Più possibilità di fare tuning

18. Notevole ottimizzazione dello spazio di storage
• Migliore utilizzazione dello spazio di storage
• Alta scalabilità di I/O
• Più opzioni di compressione
• Snappy ( default )
• zlib
• None
• Dati e file Journal compressi su disco
• Indici compressi su disco e in memoria

19. SpaziodiStorageinMB
0
650
1300
1950
2600
Enron E-Mail Dataset
MMAPv1 WiredTiger ( senza Compressione )
WiredTiger ( Snappy ) WiredTiger ( zlib )
Esempio compressione

20. Capitolo 3
Deploy MongoDB su AWS

21. M3
General Purpose
C3
Compute Optimized
R3
Memory Optimized
G2
GPU PurposeStorage Optimized
I2 HS1
Offerta Istanze EC2 AWS
T2
Micro

22. M3
General Purpose
C3
Compute Optimized
R3
Memory Optimized
G2
GPU PurposeStorage Optimized
I2 HS1
Offerta Istanze EC2 AWS
T2
Micro
X
X

23. S3#
Blob#storage#
Sta.c#
content#
EBS#
Magne.c#
SSD,#burst#
IOPS#
OS#root#
volume#
PIOPS#EBS#
SSD;backed,#
predictable#
performance#
Cost#scales#
up#with#size#
and#IOPS#
Instance#Store#
SSD;backed#
Blazing,#
ephemeral#
Included#in#
instance#cost#
Configurazione di Storage

24. S3#
Blob#storage#
Sta.c#
content#
EBS#
Magne.c#
SSD,#burst#
IOPS#
OS#root#
volume#
PIOPS#EBS#
SSD;backed,#
predictable#
performance#
Cost#scales#
up#with#size#
and#IOPS#
Instance#Store#
SSD;backed#
Blazing,#
ephemeral#
Included#in#
instance#cost#
Configurazione di Storage
X
Ideale per
ambiente di
produzione
Ideale fase
di test e sviluppo
Ottimo Rapporto
$/IOPS

25. Mongod:
Mongos:
Mongo:
E’ il processo server che esegue il database e che rende disponibile tutte i servizi
per la creazione di database, collections, l’inserimento di documenti e le relative
funzioni di interrogazione
E’ il servizio di routing per processare le query provenienti dallo strato applicativo e che
determina la locazione dei dati richiesti in una configurazione Sharding.
Rappresenta l’eseguibile per avviare la shell Javascript per interagire con database,
collezioni e documenti che possono essere interrogati e manipolati da riga di comando.
Terminologia

26. Pacchetti
Mongod-org:
Pacchetto principale che contiene tutte e quattro le componenti
MongoDB necessarie.
Mongod-org-Server:
Questo pacchetto contiene il demone Mongod ed i relativi
servizi e script di inizializzazione
Mongod-org-mongos: Contiene il pacchetto del demone Mongos
Mongod-org-shell: Contiene la shell mongo per il controllo del database
Mongod-org-tools:
Questo pacchetto contiene tutti gli strumenti di gestione del
database come mongoimport, mongoexport, mongodump etc

27. Installazione
“Manuale” “MMS”

28. Capitolo 3a
Installazione Manuale

29. Avvia MongoDB
1
2
3
4
Import della public key usata dal gestore di pacchetti
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
Creare il “List File” per MongoDB
echo "deb http://repo.mongodb.org/apt/ubuntu "$(lsb_release -sc)"/mongodb-
org/3.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list
Aggiornare il gestore di pacchetti di Ubuntu
sudo apt-get update
Installare il pacchetto di MongoDB
sudo apt-get install mongodb-org
sudo apt-get install mongodb-org=2.6.8

30. Capitolo 3b
Installazione tramite MMS

31. MongoDB Management Service

32. Automation

33. Cosa significa automation?
Richiedere
le risorse in
AWS
Deploy di
qualsiasi versione
di mongodb
Inserimento
di repliche e
shard
Aggiornamento
della
configurazione in
ogni momento
Premere un
pulsante per
aggiornare
MongoDB

34. Automation

35. Automation

36. Monitoring

37. Capitolo 4
Architetture MongoDB su AWS

38. Capitolo 4a
Replica Set

39. Nodo 1 Nodo 2
Nodo 3
Creazione Replica-Set

40. > conf = {
_id : "zero12rs”,
members : [
{_id : 0, host : "A”},
{_id : 1, host : "B"},
{_id : 2, host : "C”},
]
}
> rs.initiate(conf)
Configurazione Replica-Set

41. Nodo 1
Secondary
Nodo 2
Secondary
Nodo 3
Primary
Heartbeat
Replica Replica
Replica-Set - 1 di 4

42. Nodo 1
Secondary
Nodo 2
Secondary
Nodo 3
Primary
Elezione primary
XFAIL !
Replica-Set - 2 di 4

43. Nodo 1
Primary
Nodo 2
Secondary
Nodo 3
Primary
Heartbeat
XFAIL !
Replica
Replica-Set - 3 di 4

44. Nodo 1
Secondary
Nodo 2
Secondary
Nodo 3
Primary
Heartbeat
Sync
/
Replica
Replica
Replica-Set - 4 di 4
Nodo 1
Primary
Nodo 3
Secondary

45. Importante
Come funziona la replica

46. Come funziona la replica ?
oplog: contiene la lista di tutte le operazioni di scrittura e aggiornamenti fatti nel nodo primario
Primary
Secondary #1
Secondary #2
query per oplogs {$gt: 10}
query per oplogs {$gt: 7}
6 7 8 9 10 11 12 13
6 7 8 9 10
6 7

47. Alta disponibilità - Cross Zones
Nodo 1
Secondary
Nodo 2
Secondary
Heartbeat
Replica
Nodo 1
Primary
Nodo 3
Secondary
AZ-1 AZ-2

48. Nodo 1
Secondary
Nodo 2
Secondary
Heartbeat
Replica
Nodo 1
Primary
Nodo 3
Secondary
Region 1 Region 2
Alta disponibilità - Cross Regions

49. Capitolo 4b
Sharding

50. Il set di dati supera la capacità di storage di un
singolo mongod

51. First Edition (1771)
3 Volumes
Fifteenth Edition (2010)
32 Volumes
Sharding permette scalabilità orizzontale

52. Capitolo 4c
L’approccio di MongoDB

53. Shard
Shard key
range

54. Elementi necessari per creare uno sharding
Mongod:
Mongos:
Mongo:
E’ il processo server che esegue il database e che rende disponibile tutte i servizi
per la creazione di database, collections, l’inserimento di documenti e le relative
funzioni di interrogazione
E’ il servizio di routing per processare le query provenienti dallo strato applicativo e che
determina la locazione dei dati richiesti in una configurazione Sharding.
Rappresenta l’eseguibile per avviare la shell Javascript per interagire con database,
collezioni e documenti che possono essere interrogati e manipolati da riga di comando.
Config Server:
Rappresenta i server contenenti i metadati relativi alle chiavi di sharding e alla
distribuzione delle informazioni.

55. Distribuzione dei dati
( Sharding )
Shard
Primary
Secondary
Secondary
Shard
orMongod
• E’ un nodo di un cluster
• Può essere un singolo mongod oppure un Replica Set

56. orNode 1
Secondary
Config
Server
Node 1
Secondary
Config
Server
Node 1
Secondary
Config
Server
Node 1
Secondary
Config
Server
Config Server
• Conserva il range di chunck e la loro localizzazione
• In un’architettura possono essere da 1 a 3 Nodi di server
Config
• Non possono essere configurati come Replica-Set

57. Mongos
• Funge da router / balancer
• Non ci sono dati presenti localmente (Informazioni utili sono conservati nel
configgi server)
• Un’architettura può essere composta da 1 o più Mongos
App Server App Server App Server App Server
Mongos Mongos Mongos
Oppure

58. Esempio architettura Sharding
App Server
Mongos
App Server
Mongos
App Server
Mongos
Config
Server
Config
Server
Config
Server
Shard 1 Shard 2 Shard 3

59. Sharding: Alta disponibilità Cross AZ
App Server
Mongos
App Server
Mongos
App Server
Mongos
Config
Server
Config
Server
Config
Server
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Mongod
primary
Mongod
Secondary
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Mongod
Secondary
AZ -1
AZ -2
Shard1 Shard2 Shard3
App Server
Mongos

60. Sharding: Alta disponibilità Cross Region
App Server
Mongos
App Server
Mongos
App Server
Mongos
Config
Server
Config
Server
Config
Server
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Mongod
primary
Mongod
Secondary
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Mongod
Secondary
Region 1
Shard1 Shard2 Shard3
App Server
Mongos
Region 2

61. Capitolo 4d
Sharding Key

62. • La chiave di Shard è immutabile
• I valori della chiave di Shard sono immutabile
• La chiave di Shard deve essere indicizzata
• La chiave di Shard è limitata ad una dimensione di 512 bytes
• La chiave di Shard è usata per definire il routing delle query
- Usare un campo usato nelle query
• Solamente la shard key può essere unica tra tutti gli shards
- `_id` è unico all’interno del singolo shard
Sharding Key

63. Capitolo 4e
Sharding Key - Funzionamento

64. Partitioning
E’ importante ricordare che il partizionamento degli oggetti
è basato su un range

65. I chunk sono una partizione di questo range

66. Divisione Chunk
• Un chunk viene suddiviso quando supera la dimensione massima
• Non ci sono punti di divisione se i documenti hanno la stessa
shared key
• Lo split di un chunk è un’operazione logica (nessun dato viene
spostato)

67. Balancing
• Il Balancer è eseguito all’interno di Mongos
• Quando la differenza tra lo shard più denso e la densità degli altri shard
supera la soglia di migrazione, il processo di bilanciamento viene avviato

68. Cleanup
• Lo shard sorgente cancella i dati
• Mongos rimuove il lock dal balancer dopo che l’operazione di
rimozione dei chunk è stata completata.

69. Capitolo 5
Backup

70. MMS Backup
MMS & Backup Agent
MMS
Shard 1 Shard 2 Shard 3
Mongod
primary
Mongod
Secondary
Mongod
Secondary

71. Snapshot Backup
EC2 EBS EBS Snapshot
Lo snapshot del volume EBS con journaling attivato è possibile
se e solo se il file di journal risiede nello stesso volume EBS dei dati MongoDB
db.runCommand({fsync:1,lock:1})

72. Capitolo 6
Esempio di Architettura su AWS

73. Config
Server
AZ-1
Shard1 Shard2 Shard3
AZ-2
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Mongod
primary
Mongod
Secondary
Mongod
Secondary
Config
Server
Config
Server
MMS & Backup Agent
Autoscaling
App Server
+ Mongos
CloudWatch
SNS
MMS
Monitoring
Monitoring&Backup
Users
Tecnici

74. Capitolo 7
Schema Design

76. Contacts
{
“_id”: 2,
“name”: “Steven Jobs”,
“title”: “VP, New Product Development”,
“company”: “Apple Computer”,
“phone”: “408-996-1010”,
“address_id”: 1
}
Addresses
{
“_id”: 1,
“street”: “10260 Bandley Dr”,
“city”: “Cupertino”,
“state”: “CA”,
“zip_code”: ”95014”,
“country”: “USA”
}
References

77. Embedding
Contacts
{
“_id”: 2,
“name”: “Steven Jobs”,
“title”: “VP, New Product Development”,
“company”: “Apple Computer”,
“address”: {
“street”: “10260 Bandley Dr”,
“city”: “Cupertino”,
“state”: “CA”,
“zip_code”: ”95014”,
“country”: “USA”
},
“phone”: “408-996-1010”
}

78. Relazionale vs Documents
Quali sono le differenze e perché?
Contact Address
Contact
• Name
• Company
• Title
• Phone
• Street
• City
• State
• Zip_code
• Name
• Company
• Title
• Address
• Street
• City
• State
• Zip_Code
• Phone

79. Flessibilità
{
“name”: “Steven Jobs”,
“title”: “VP, New Product Development”,
“company”: “Apple Computer”,
“address”: {
“street”: “10260 Bandley Dr”,
“city”: “Cupertino”,
“state”: “CA”,
“zip_code”: ”95014”
},
“phone”: “408-996-1010”
}
{
“name”: “Larry Page”,
“url”: “http://google.com/”,
“title”: “CEO”,
“company”: “Google!”,
“email”: “larry@google.com”,
“address”: {
“street”: “555 Bryant, #106”,
“city”: “Palo Alto”,
“state”: “CA”,
“zip_code”: “94301”
}
“phone”: “650-618-1499”,
“fax”: “650-330-0100”
}

80. Capitolo 7a
1:1

81. Contact
Groups
Twitter
• Name
• Location
• Web
• Bio
11 • Name
• Company
• Title
1:1 Schema Design

82. 1:1 Schema Design
Contact Twitter
Contact Twitter
Twitter_id
Contact_id
1 1
1 1
Contact
• Name
• Company
• Title
• Twitter
Twitter
Può ridurre le operazioni di reperimento dell’informazione?

83. Raccomandazioni:
• Tutte le informazioni del contatto reperibili con un’unica
operazione
• Contatto Twitter Embedded nel documento principale
• Relazione padre - figlio ( contenute )
• Non ci sono dati duplicati
• Sono possibili query e creazione di indici anche in campi
embedded
Casi eccezionali
• Valutare la decisione dell’embedding quando ci sono
grandi volumi di informazioni
Contact
• Name
• Company
• Title
• Twitter
Twitter
1:1 Schema Design

84. Capitolo 7b
1:N

85. Contact Phones
• Type
• Number
N1• Name
• Company
• Title
1:N Schema Design

86. Contact Phones
Contact Phones
Phones_id: [ ]
Contact_id
1 N
1 N
Contact
• Name
• Company
• Title
• Phones
Phones
1:N Schema Design

87. Raccomandazioni:
• Tutte le informazioni del contatto reperibili con un’unica
operazione
• Il documento “Contact” può contenere multipli numeri di
telefono
• Relazione padre - figlio ( contenute )
• Sono possibili query e creazione di indici anche in campi
embedded ( Esempio {“phone.type”: “Mobile”}
Casi eccezionali
• Valutare la decisione dell’embedding quando ci sono
grandi volumi di informazioni
ContactContact
• Name
• Company
• Title
• Phones
Phones
1:N Schema Design

88. Capitolo 7b
N:N

89. Contact
• Name
• Company
• Title
Groups
• Name
NN
N:N Schema Design

90. Groups
• Name
GroupsContacts
• group_id
• contact_id
• Name
• Company
• Title
Contact
Join Table
N:N Schema Design

91. Groups
• Name
GroupsContacts
• group_id
• contact_id
• Name
• Company
• Title
Contact
Join Table
Conviene usare gli Array
N:N Schema Design

92. Group Contact
Group Contact
contacts_id: [ ]
Contact_id
N N
N N
Group
• Contact
Contact N N
Contact
• Groups
Groups N
Informazioni ridondanti in entrambi i casi per
mantenere le relazioni
Entrambe le referenze richiedono di essere aggiornate
per mantenere la consistenza
Informazioni ridondanti in entrambi i casi per
mantenere le relazioni
Entrambe le referenze richiedono di essere aggiornate
per mantenere la consistenza
N:N Schema Design

93. Raccomandazioni:
• Dipende dai casi:
• Semplice Address Book
• Contatti referenziano ai gruppi
• Corporate e-mail Group
• Gruppi embeddano i contatti per performance
Casi eccezionali
• Attenzione al limite di 16MB di un documento
• La crescita del volume di dati può avere impatti sulle
performance e nell’organizzazione dei dati
Group
• Contact
Contact N
Contact
• Groups
Groups
N:N Schema Design

94. Capitolo 8
MongoDB & EMR

95. Elastic Map-Reduce
Veloce deploy ed esecuzione di
Hadoop su AWS
Supporta istanze Spot e Reserved
per ottimizzazione dei costi
Deploy su qualsiasi numero di nodi
del cluster Hadoop
Provision deployment su un numero
qualsiasi di nodi del cluster

96. Easy to Use
Basso costo
Sicuro
Affidabile
Scalabile
Flessibile

97. EMR & MongoDB
• Connettore MongoDB - Hadoop
• Accesso bidirezionale con MongoDB e Hadoop
• Supporta MapReduce, Hive, Pig e Streaming
• Read / Write da:
• MongoDB
• BSON File backup
https://github.com/mongodb/mongo-hadoop

98. EMR & MongoDB
BSONBSON

99. Riferimenti utili
• https://aws.amazon.com/it/blogs/aws/mongodb-on-the-aws-cloud-new-
quick-start-reference-deployment/
• https://media.amazonwebservices.com/AWS_NoSQL_MongoDB.pdf
• http://docs.mongodb.org/manual/
• http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/
emr-what-is-emr.html
• http://www.zero12.it/integrare-mms-con-soluzioni-enterprise-di-
archiviazione-dati/

100. Grazie!
@stefanodindo
Stefano Dindo