2. Chi sono?
• Solutions Architect/Evangelist in MongoDB Inc.
• 24 anni di esperienza nel mondo dei database e dello
sviluppo software
• Ex dipendente di MySQL
• In precedenza: web,web,web
3. Agenda
• Che cos’è un Record?
• Concetti chiave
• Che cos’è un’Entità?
• Associazione tra Entità
• Suggerimenti generali
7. Chiave → Valore
• Storage mono-dimensionale
• Il singolo valore e’un blob
• Le query sono solo per chiave
• Nessuno schema
• I valore non può essere aggiornato ma solamente
sovrascritto
Key Blob
8. Relazionale
• Storage bi-dimensionale (tuple)
• Ogni campo contiene solo un valore
• Query sono su ogni campo
• Schema molto strutturato (tabelle)
• Update sul posto
• Il processo di normalizzazione richiede molte tabelle,
indici e con una pessima localizzazione dei dati.
Primary
Key
9. Documento
• Storage N-dimensionale
• Ogni campo può contenere 0,1,
tanti o valori incapsulati
• Query su tutti i campi e livelli
• Schema dinamico
• Update in linea
• Incapsulare i dati migliora la localizzazione dei dati,
richiede meno indici e ha migliori performance
_id
17. E come si sviluppava il software?
pio, il LISP (LISt Processing language) [24].
A quel tempo, i problemi significativi non ri-
denti con interfacce chiare e componibili. Si
diffusero concetti quali la programmazione
1
ei
gi
Processo Bisogno Linguaggio
1950
1960
1970
1980
1990
2000
Primi tentativi di “ordine”
nello sviluppo
Comprensibilità e portabilità del codice,
per sostenere la sua evoluzione
Organizzazione “industriale”
dello sviluppo dei sistemi software
Impossibilità di definire in modo
preciso il sistema da sviluppare
Sviluppo e distribuzione molto
rapidi e orientati ai sistemi
di comunicazione
Waterfall, a “V”, ...
Incrementale, Spirale, ...
Metodologie agili
Linguaggi assemblativi
Linguaggi di alto livello
Linguaggi strutturati
Linguaggi orientati agli oggetti
Linguaggi per lo sviluppo
dinamico
18. RDBMS Rende lo Sviluppo Difficile
Relational
Database
Object Relational
Mapping
Application
Code XML Config DB Schema
19. E Ancora Più Difficile Evolverlo…
New
Table
New
Table
New
Column
Name Pet Phone Email
New
Column
3 months later…
20. RDBMS
Dalla Complessità alla Semplicità..
MongoDB
{
_id : ObjectId("4c4ba5e5e8aabf3"),
employee_name: "Dunham, Justin",
department : "Marketing",
title : "Product Manager, Web",
report_up: "Neray, Graham",
pay_band: “C",
benefits : [
{ type : "Health",
plan : "PPO Plus" },
{ type : "Dental",
plan : "Standard" }
]
}
24. I 3 Elementi fondamentali dello
Schema Design Documentale
25. 1 – Flessibilità
• Scelte per lo schema design
• Ogni documento può avere campi differenti
• I nomi di campi sono consistenti per la
programmazione
• La struttura può essere forzata dall’applicazione
• Facile da evolvere secondo necessità
26. 2 – Arrays – Valori Multipli per Campo
• Ogni campi può essere:
– Assente
– Settato a null
– Settato a un valore singolo
– Settato a un array con molteplici valori
• Query per ogni valore:
– Può essere indicizzato e ogni valore dell’array è nell’indice
27. 3 – Documenti Incapsulati (embedded)
• Un valore accettato è un documento
• I documenti nidificati creano la struttura
• Query di ogni campo ad ogni livello
– Possono essere indicizzati
29. Un’Entità
• Un Oggetto del vostro modello
• Ci sono Associazioni con altre entità
Referencing (Relazionale) Embedding (Documentale)
has_one embeds_one
belongs_to embedded_in
has_many embeds_many
has_and_belongs_to_many
MongoDB ha sia il referencing sia l’embedding per un uso generale
35. Contatti
• nome
• azienda
• adress
• Street
• City
• State
• Zip
• titolo
• telefono
• indirizzi
• strada
• città
• stato
• cap
Schema Documentale
36. In cosa differiscono? E Perché?
Contact
• name
• company
• title
• phone
Address
• street
• city
• state
• zip_code
Contact
• name
• company
• adress
• Street
• City
• State
• Zip
• title
• phone
• address
• street
• city
• state
• zip_code
41. Tipico ERD di una Rubrica
Contacts
• name
• company
• title
Addresses
• type
• street
• city
• state
• zip_code
Phones
• type
• number
Emails
• type
• address
Thumbnails
• mime_type
• data
Portraits
• mime_type
• data
Groups
• name
N
1
N
1
N
N
N
1
1
1
11
Twitters
• name
• location
• web
• bio
1
1
43. 1-a-1
Contacts
• name
• company
• title
Addresses
• type
• street
• city
• state
• zip_code
Phones
• type
• number
Emails
• type
• address
Thumbnails
• mime_type
• data
Portraits
• mime_type
• data
Groups
• name
N
1
N
1
N
N
N
1
1
1
11
Twitters
• name
• location
• web
• bio
1
1
44. 1-a-1
Scelte di Schema Design
contact
• twitter_id
twitter1 1
contact twitter
• contact_id1 1
E’ ridondante tenere entrambe le relazioni
• Entrambe devono essere aggiornate per consistenza
• Posso risparmiare una lettura?
Contact
• twitter
twitter 1
45. 1-a-1
Consigli Generali
• Tutto il contatto in un sol colpo
– Il contatto embedda twitter
• Relazione padre-figlio
– “contiene”
• Nessuna duplicazioni dei dati
• Possibilie eseguire query o indicizzare il campo
incapsulato
– Ad es.,“twitter.nome”
– Eccezioni…
• L’immagine del ritratto potrebbe essere troppo
grande
Contact
• twitter
twitter 1
46. 1-a-molti
Contacts
• name
• company
• title
Addresses
• type
• street
• city
• state
• zip_code
Phones
• type
• number
Emails
• type
• address
Thumbnails
• mime_type
• data
Portraits
• mime_type
• data
Groups
• name
N
1
N
1
N
N
N
1
1
1
11
Twitters
• name
• location
• web
• bio
1
1
47. 1-a-molti
Scelte di Schema Design
contact
• phone_ids: [ ]
phone1 N
contact phone
• contact_id1 N
E’ ridondante tenere entrambe le relazioni
• Entrambe devono essere aggiornate per consistenza
• Non possibile in un DB relazionale
• E’ possibile risparmiare letture?
Contact
• phones
phone N
48. 1-a-molti
Consigli Generali
• Tutto il contatto in un sol colpo
– Il contatto incapsula molteplici telefoni
• Relazione Padre-Figlio
– “contiene”
• Nessuna duplicazione di dati
• Si possono eseguire query o indicizzare ogni campo
– e.g., { “phones.type”: “mobile” }
– Eccezioni…
• Dimensioni: la grandezza massima di un
documento è 16MB
Contact
• phones
phone N
49. molti-a-molti
Contacts
• name
• company
• title
Addresses
• type
• street
• city
• state
• zip_code
Phones
• type
• number
Emails
• type
• address
Thumbnails
• mime_type
• data
Portraits
• mime_type
• data
Groups
• name
N
1
N
1
N
N
N
1
1
1
11
Twitters
• name
• location
• web
• bio
1
1
50. Molti-a-molti
Associazione del mondo relazionale
Join table
Contacts
• name
• company
• title
• phone
Groups
• name
GroupContacts
• group_id
• contact_id
nei documenti si usano gli arrays
X
51. Molti-a-molti
Scelte di Schema Design
group
• contact_ids: [ ]
contactN N
group contact
• group_ids: [ ]N N
Redundant to track
relationship on both sides
• Both references must be
updated for consistency
Redundant to track
relationship on both sides
• Duplicated data must be
updated for consistency
group
• contacts
contact
N
contact
• groups
group
N
52. Molti-a-Molti
Consigli Generali
• Dipende dai casi
1. Rubrica semplice
• I contatti referenziano i gruppi
2. Gruppi di email corporate
• I gruppi incapsulano i contatti per performance
• Eccezioni
– Scalabilità: dimensione massima documenti16MB
– Scalabilità: può avere impatti sulle performance and sulle
dimensioni del working set
group contact
• group_ids: [ ]N N
53. Contacts
• name
• company
• title
addresses
• type
• street
• city
• state
• zip_code
phones
• type
• number
emails
• type
• address
thumbnail
• mime_type
• data
Portraits
• mime_type
• data
Groups
• name
N
1
N
1
twitter
• name
• location
• web
• bio
N
N
N
1
1
Modello del documento – Rappresentazione efficiente
54. Esempio di documento di un contatto
{
“name” : “Gary J. Murakami, Ph.D.”,
“company” : “MongoDB, Inc.”,
“title” : “Lead Engineer”,
“twitter” : {
“name” : “Gary Murakami”, “location” : “New Providence, NJ”,
“web” : “http://www.nobell.org”
},
“portrait_id” : 1,
“addresses” :
,
“phones” :
,
“emails” :
}
55. Working Set
Per ridurre le dimensioni del working set,considera
• Referenzia i data grandi,e.g.,portrait
• Referenzia i dati usati poco invece di embeddarli
– Estraili in un documento figlio referenziato
57. Migrazione da schemi legacy
1. Copiate lo schema esistente e qualche dato su
mongoDB
2. Iterate lo sviluppo dello schema design
1. Prima le associazioni one to one
2. Poi le associazioni one to many
3. Ed infine le associazioni many to many
3. Migrate l’intero dataset al nuovo schema
L’applicazione è nuova? Embeddate di default
58. Embedding contro Referencing
• Embedding è come fare un pre-join dei dati
– Le operazioni su documenti BSON (Binary JSON) sono facili
per il server
• Embed (90/10 regola del pollo)
– Quando l’uno a molti sono oggetti visti nello stesso
contesto del padre
– Per performance
– Per atomicità
• Reference
– Quando avete bisogno di scalare maggiormente
– Per consistenza nel molti-a-molti evitando di ripetere tanti
dati.
59. E’ Tutto nella Vostra Applicazione
• Programmi + Database = Applicazioni Big Data
• Programmi×MongoDB = Grandi applicazioni Big Data
62. High Volume Data Feeds
• More machine forms, sensors & data
• Variably structured
Machine
Generated Data
• High frequency trading
• Daily closing priceSecurities Data
• Multiple data sources
• Each changes their format consistently
• Student Scores, ISP logs
Social Media /
General Public
63. Operational Intelligence
• Large volume of users
• Very strict latency requirements
• Sentiment Analysis
Ad Targeting
• Expose data to millions of customers
• Reports on large volumes of data
• Reports that update in real time
Real time
dashboards
• Join the conversation
• Catered Games
• Customized Surveys
Social Media
Monitoring
64. Metadata
• Diverse product portfolio
• Complex querying and filtering
• Multi-faceted product attributes
Product
Catalogue
• Data mining
• Call records
• Insurance Claims
Data analysis
• Retina Scans
• FingerprintsBiometric
65. Content Management
• Comments and user generated content
• Personalization of content and layoutNews Site
• Generate layout on the fly
• No need to cache static pages
Multi-device
rendering
• Store large objects
• Simpler modeling of metadataSharing
