Schema Design
 

Schema Design

on

  • 832 views

 

Statistics

Views

Total Views
832
Slideshare-icon Views on SlideShare
436
Embed Views
396

Actions

Likes
2
Downloads
28
Comments
0

4 Embeds 396

http://www.mongodb.com 368
https://www.mongodb.com 25
https://live.mongodb.com 2
https://corpwww-dev-drupal.10gen.com 1

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

    Schema Design Schema Design Presentation Transcript

    • 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 sviluppo software •  Ex dipendente di MySQL •  In precedenza: web,web,web
    • Agenda •  Che cos’è un Record? •  Concetti chiave •  Che cos’è un’Entità? •  Associazione tra Entità •  Suggerimenti generali
    • 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 schema •  I valore non può essere aggiornato ma solamente sovrascritto Key Blob
    • 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
    • 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
    • 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 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
    • 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", department : "Marketing", title : "Product Manager, Web", report_up: "Neray, Graham", pay_band: “C", benefits : [ { type : "Health", plan : "PPO Plus" }, { type : "Dental", plan : "Standard" } ] }
    • 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 consistenti per la programmazione •  La struttura può essere forzata dall’applicazione •  Facile da evolvere secondo necessità
    • 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
    • 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
    • Che cosa è un’Entità?
    • 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
    • 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”: , “nome”: , “titolo”: , “azienda”: ”, “telefono”: , “indirizzo_id”: }
    • Embedding Contatti { “_id”: , “nome”: , “titolo”: , “azienda”: , “indirizzi”: { “strada”: , “città”: , “stato”: , “cap”: , “nazione”: }, “telefono”: }
    • Schema Relazionale Contatti •  nome •  azienda •  titolo •  telefono Indirizzi •  strada •  città •  stato •  cap
    • Contatti •  nome •  azienda •  adress •  Street •  City •  State •  Zip •  titolo •  telefono •  indirizzi •  strada •  città •  stato •  cap Schema Documentale
    • 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
    • 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” }
    • 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 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
    • Associare le Entità
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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” : }
    • 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
    • Consigli Generali
    • 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
    • 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.
    • E’ Tutto nella Vostra Applicazione •  Programmi + Database = Applicazioni Big Data •  Programmi×MongoDB = Grandi applicazioni Big Data
    • Casi d’Uso comuni
    • 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
    • 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
    • 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
    • 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
    • Domande?
    • Grazie!!! Senior Solution Architect, MongoDB Inc. massimo@mongodb.com Massimo Brignoli @massimobrignoli