Schema Design
Senior Solution Architect, MongoDB Inc.
Massimo Brignoli
@massimobrignoli
Chi sono?
•  Solutions Architect/Evangelist in MongoDB Inc.
•  24 anni di esperienza nel mondo dei database e dello
svilup...
Agenda
•  Che cos’è un Record?
•  Concetti chiave
•  Che cos’è un’Entità?
•  Associazione tra Entità
•  Suggerimenti gener...
Tutto lo sviluppo di
applicazioni richiede
Schema Design
Il successo arriva da
Una struttura dati
appropriata
Che cos’è un Record?
Chiave → Valore
•  Storage mono-dimensionale
•  Il singolo valore e’un blob
•  Le query sono solo per chiave
•  Nessuno sc...
Relazionale
•  Storage bi-dimensionale (tuple)
•  Ogni campo contiene solo un valore
•  Query sono su ogni campo
•  Schema...
Documento
•  Storage N-dimensionale
•  Ogni campo può contenere 0,1,
tanti o valori incapsulati
•  Query su tutti i campi ...
Innovation
Tante grandi innovazioni dal 1970…
Ma usereste una di queste
tecnologie per lanciare un
nuovo business oggi?
Incluso il modello relazionale dei dati!
Per quali computer è stato
pensato il modello
relazionale?
Questi erano i computer!
E lo Storage?
E come si sviluppava il software?
pio, il LISP (LISt Processing language) [24].
A quel tempo, i problemi significativi non...
RDBMS Rende lo Sviluppo Difficile
Relational
Database
Object Relational
Mapping
Application
Code XML Config DB Schema
E Ancora Più Difficile Evolverlo…
New
Table
New
Table
New
Column
Name Pet Phone Email
New
Column
3 months later…
RDBMS
Dalla Complessità alla Semplicità..
MongoDB
{
_id : ObjectId("4c4ba5e5e8aabf3"),
employee_name: "Dunham, Justin",
de...
Concetti Chiave
Lo Schema Design tradizionale
è focalizzato
sullo STORAGE dei dati
Lo Schema Design a documenti
è focalizzato
sull’USO dei dati
I 3 Elementi fondamentali dello
Schema Design Documentale
1 – Flessibilità
•  Scelte per lo schema design
•  Ogni documento può avere campi differenti
•  I nomi di campi sono consi...
2 – Arrays – Valori Multipli per Campo
•  Ogni campi può essere:
–  Assente
–  Settato a null
–  Settato a un valore singo...
3 – Documenti Incapsulati (embedded)
•  Un valore accettato è un documento
•  I documenti nidificati creano la struttura
• ...
Che cosa è un’Entità?
Un’Entità
•  Un Oggetto del vostro modello
•  Ci sono Associazioni con altre entità
Referencing (Relazionale) Embedding (D...
Modelliamo qualcosa assieme
Che ne dite di un biglietto
da visita?
Il nostro biglietto da visita….
Referencing
Indirizzi

{

“_id”: ,

“strada”:
,

“città”: ,

“stato”: ”,

“cap”: ,

“nazione”:
}
Contatti

{
“_id”: ,
“nom...
Embedding
Contatti

{
“_id”: ,
“nome”: ,
“titolo”:
,
“azienda”: ,
“indirizzi”: {

“strada”: ,

“città”: ,

“stato”: ,

“ca...
Schema Relazionale
Contatti
•  nome
•  azienda
•  titolo
•  telefono
Indirizzi
•  strada
•  città
•  stato
•  cap
Contatti
•  nome
•  azienda
•  adress
•  Street
•  City
•  State
•  Zip
•  titolo
•  telefono
•  indirizzi
•  strada
•  ci...
In cosa differiscono? E Perché?
Contact
•  name
•  company
•  title
•  phone
Address
•  street
•  city
•  state
•  zip_cod...
Flessibilità dello Schema

{
“name”: ,
“title”:
,
“company”: ,
“address”: {

“street”: ,

“city”: ,

“state”: ,

“zip_code...
Esempio
Guardiamo come è fatta una
Rubrica
Rubrica
•  Quali sono le mie entità?
•  Quali sono le mie associazioni?
Tipico ERD di una Rubrica
Contacts
•  name
•  company
•  title
Addresses
•  type
•  street
•  city
•  state
•  zip_code
Ph...
Associare le Entità
1-a-1
Contacts
•  name
•  company
•  title
Addresses
•  type
•  street
•  city
•  state
•  zip_code
Phones
•  type
•  numb...
1-a-1
Scelte di Schema Design
contact
•  twitter_id
twitter1 1
contact twitter
•  contact_id1 1
E’ ridondante tenere entra...
1-a-1
Consigli Generali
•  Tutto il contatto in un sol colpo
–  Il contatto embedda twitter
•  Relazione padre-figlio
–  “c...
1-a-molti
Contacts
•  name
•  company
•  title
Addresses
•  type
•  street
•  city
•  state
•  zip_code
Phones
•  type
•  ...
1-a-molti
Scelte di Schema Design
contact
•  phone_ids: [ ]
phone1 N
contact phone
•  contact_id1 N
E’ ridondante tenere e...
1-a-molti
Consigli Generali
•  Tutto il contatto in un sol colpo
–  Il contatto incapsula molteplici telefoni
•  Relazione...
molti-a-molti
Contacts
•  name
•  company
•  title
Addresses
•  type
•  street
•  city
•  state
•  zip_code
Phones
•  type...
Molti-a-molti
Associazione del mondo relazionale
Join table
Contacts
•  name
•  company
•  title
•  phone
Groups
•  name
G...
Molti-a-molti
Scelte di Schema Design
group
•  contact_ids: [ ]
contactN N
group contact
•  group_ids: [ ]N N
Redundant to...
Molti-a-Molti
Consigli Generali
•  Dipende dai casi
1.  Rubrica semplice
•  I contatti referenziano i gruppi
2.  Gruppi di...
Contacts
•  name
•  company
•  title
addresses
•  type
•  street
•  city
•  state
•  zip_code
phones
•  type
•  number
ema...
Esempio di documento di un contatto
{

“name” : “Gary J. Murakami, Ph.D.”,

“company” : “MongoDB, Inc.”,

“title” : “Lead ...
Working Set
Per ridurre le dimensioni del working set,considera
•  Referenzia i data grandi,e.g.,portrait
•  Referenzia i ...
Consigli Generali
Migrazione da schemi legacy
1.  Copiate lo schema esistente e qualche dato su
mongoDB
2.  Iterate lo sviluppo dello schema...
Embedding contro Referencing
•  Embedding è come fare un pre-join dei dati
–  Le operazioni su documenti BSON (Binary JSON...
E’ Tutto nella Vostra Applicazione
•  Programmi + Database = Applicazioni Big Data
•  Programmi×MongoDB = Grandi applicazi...
Casi d’Uso comuni
High Volume Data Feeds
•  More machine forms, sensors & data
•  Variably structured
Machine
Generated Data
•  High frequen...
Operational Intelligence
•  Large volume of users
•  Very strict latency requirements
•  Sentiment Analysis
Ad Targeting
•...
Metadata
•  Diverse product portfolio
•  Complex querying and filtering
•  Multi-faceted product attributes
Product
Catalog...
Content Management
•  Comments and user generated content
•  Personalization of content and layoutNews Site
•  Generate la...
Domande?
Grazie!!!
Senior Solution Architect, MongoDB Inc.
massimo@mongodb.com
Massimo Brignoli
@massimobrignoli
Schema Design
Upcoming SlideShare
Loading in …5
×

Schema Design

1,266 views
1,198 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,266
On SlideShare
0
From Embeds
0
Number of Embeds
582
Actions
Shares
0
Downloads
38
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Schema Design

  1. 1. Schema Design Senior Solution Architect, MongoDB Inc. Massimo Brignoli @massimobrignoli
  2. 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. 3. Agenda •  Che cos’è un Record? •  Concetti chiave •  Che cos’è un’Entità? •  Associazione tra Entità •  Suggerimenti generali
  4. 4. Tutto lo sviluppo di applicazioni richiede Schema Design
  5. 5. Il successo arriva da Una struttura dati appropriata
  6. 6. Che cos’è un Record?
  7. 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. 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. 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
  10. 10. Innovation
  11. 11. Tante grandi innovazioni dal 1970…
  12. 12. Ma usereste una di queste tecnologie per lanciare un nuovo business oggi?
  13. 13. Incluso il modello relazionale dei dati!
  14. 14. Per quali computer è stato pensato il modello relazionale?
  15. 15. Questi erano i computer!
  16. 16. E lo Storage?
  17. 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. 18. RDBMS Rende lo Sviluppo Difficile Relational Database Object Relational Mapping Application Code XML Config DB Schema
  19. 19. E Ancora Più Difficile Evolverlo… New Table New Table New Column Name Pet Phone Email New Column 3 months later…
  20. 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" } ] }
  21. 21. Concetti Chiave
  22. 22. Lo Schema Design tradizionale è focalizzato sullo STORAGE dei dati
  23. 23. Lo Schema Design a documenti è focalizzato sull’USO dei dati
  24. 24. I 3 Elementi fondamentali dello Schema Design Documentale
  25. 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. 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. 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
  28. 28. Che cosa è un’Entità?
  29. 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
  30. 30. Modelliamo qualcosa assieme Che ne dite di un biglietto da visita?
  31. 31. Il nostro biglietto da visita….
  32. 32. Referencing Indirizzi { “_id”: , “strada”: , “città”: , “stato”: ”, “cap”: , “nazione”: } Contatti { “_id”: , “nome”: , “titolo”: , “azienda”: ”, “telefono”: , “indirizzo_id”: }
  33. 33. Embedding Contatti { “_id”: , “nome”: , “titolo”: , “azienda”: , “indirizzi”: { “strada”: , “città”: , “stato”: , “cap”: , “nazione”: }, “telefono”: }
  34. 34. Schema Relazionale Contatti •  nome •  azienda •  titolo •  telefono Indirizzi •  strada •  città •  stato •  cap
  35. 35. Contatti •  nome •  azienda •  adress •  Street •  City •  State •  Zip •  titolo •  telefono •  indirizzi •  strada •  città •  stato •  cap Schema Documentale
  36. 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
  37. 37. Flessibilità dello Schema { “name”: , “title”: , “company”: , “address”: { “street”: , “city”: , “state”: , “zip_code”: }, “phone”: } { “name”: , “url”: , “title”: , “company”: , “email”: , “address”: { “street”: , “city”: , “state”: , “zip_code”: } “phone”: , “fax” }
  38. 38. Esempio
  39. 39. Guardiamo come è fatta una Rubrica
  40. 40. Rubrica •  Quali sono le mie entità? •  Quali sono le mie associazioni?
  41. 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
  42. 42. Associare le Entità
  43. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  56. 56. Consigli Generali
  57. 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. 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. 59. E’ Tutto nella Vostra Applicazione •  Programmi + Database = Applicazioni Big Data •  Programmi×MongoDB = Grandi applicazioni Big Data
  60. 60. Casi d’Uso comuni
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. Domande?
  66. 66. Grazie!!! Senior Solution Architect, MongoDB Inc. massimo@mongodb.com Massimo Brignoli @massimobrignoli

×