SlideShare ist ein Scribd-Unternehmen logo
1 von 48
#MongoBoston




Schema Design
Chad Tindel
Senior Solution Architect, 10gen
Agenda
• Working with documents
• Evolving a Schema
• Queries and Indexes
• Common Patterns




                      Single Table En
RDBMS                MongoDB
Database      ➜ Database
Table         ➜ Collection
Row           ➜ Document
Index         ➜ Index
Join          ➜ Embedded Document
Foreign Key   ➜ Reference

Terminology
Working with
Documents
Modeling Data
Documents
Provide flexibility and
performance
Normalized Data
Disk seeks and data locality

    Seek = 5+ ms          Read = really really fast




                   Post

                                  Comment
    Author                                            Tags
De-Normalized (embedded)
Data
Disk seeks and data locality
           Article


             Author


              Comment
               Tag


             Comment
              Comment
               Comment
                Comment
                Comment
Relational Schema Design
Focus on data storage
Document Schema Design
Focus on data use
Schema Design
Considerations
• How do we manipulate the data?
   – Dynamic Ad-Hoc Queries
   – Atomic Updates
   – Map Reduce

• What are the access patterns of the application?
   – Read/Write Ratio
   – Types of Queries / Updates
   – Data life-cycle and growth rate
Data Manipulation
• Conditional Query Operators
  – Scalar: $ne, $mod, $exists, $type, $lt, $lte, $gt, $gte, $ne
  – Vector: $in, $nin, $all, $size

• Atomic Update Operators
  – Scalar: $inc, $set, $unset
  – Vector: $push, $pop, $pull, $pushAll, $pullAll, $addToSet
Data Access
• Flexible Schemas
• Ability to embed complex data structures
• Secondary Indexes
• Compound Indexes
• Multi-Value Indexes (Indexes on Arrays)
• Aggregation Framework
   – $project, $match, $limit, $skip, $sort, $group, $unwind

• No Joins
Getting Started
Library Management
Application
• Patrons
• Books
• Authors
• Publishers
An Example
One to One Relations
Modeling Patrons

patron = {                   patron = {
  _id: "joe"                   _id: "joe"
  name: "Joe Bookreader”       name: "Joe Bookreader",
}                              address: {
                                  street: "123 Fake St. ",
address = {                       city: "Faketon",
  patron_id = "joe",
                                  state: "MA",
  street: "123 Fake St. ",
  city: "Faketon",                zip: 12345
  state: "MA",                 }
  zip: 12345                 }
}
One to One Relations
• Mostly the same as the relational approach
• Generally good idea to embed “contains”
 relationships
• Document model provides a holistic
 representation of objects
An Example
One To Many Relations
Modeling Patrons

patron = {
  _id: "joe"
  name: "Joe Bookreader",
  join_date: ISODate("2011-10-15"),
  addresses: [
    {street: "1 Vernon St.", city: "Newton", state: "MA", …},
    {street: "52 Main St.", city: "Boston", state: "MA", …},
  ]
}
Publishers and Books
• Publishers put out many books
• Books have one publisher
Book


MongoDB: The Definitive Guide,
By Kristina Chodorow and Mike Dirolf
Published: 9/24/2010
Pages: 216
Language: English

Publisher: O’Reilly Media, CA
Modeling Books – Embedded
Publisher

book = {
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ]
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English",
  publisher: {
      name: "O’Reilly Media",
      founded: "1980",
      location: "CA"
  }
}
Modeling Books & Publisher
Relationship
publisher = {
  name: "O’Reilly Media",
  founded: "1980",
  location: "CA"
}

book = {
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ]
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English"
}
Publisher _id as a Foreign
Key
publisher = {
  _id: "oreilly",
  name: "O’Reilly Media",
  founded: "1980",
  location: "CA"
}

book = {
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ]
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English",
  publisher_id: "oreilly"
}
Book _id as a Foreign Key
publisher = {
  name: "O’Reilly Media",
  founded: "1980",
  location: "CA"
  books: [ "123456789", ... ]
}

book = {
  _id: "123456789",
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ]
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English"
}
Where do you put the foreign
Key?
• Array of books inside of publisher
   – Makes sense when many means a handful of items
   – Useful when items have bound on potential growth

• Reference to single publisher on books
   – Useful when items have unbounded growth (unlimited # of
    books)
• SQL doesn’t give you a choice, no arrays
Another Example
One to Many Relations
Books and Patrons
• Book can be checked out by one Patron at a
 time
• Patrons can check out many books (but not
 1000s)
Modeling Checkouts
patron = {
  _id: "joe"
  name: "Joe Bookreader",
  join_date: ISODate("2011-10-15"),
  address: { ... }
}

book = {
  _id: "123456789"
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ],
  ...
}
Modeling Checkouts
patron = {
    _id: "joe"
    name: "Joe Bookreader",
    join_date: ISODate("2011-10-15"),
    address: { ... },
    checked_out: [
        { _id: "123456789", checked_out: "2012-10-15" },
        { _id: "987654321", checked_out: "2012-09-12" },
        ...
    ]
}
De-normalization
Provides data locality




           De-normalize for speed
Modeling Checkouts -- de-
normalized
patron = {
  _id: "joe"
  name: "Joe Bookreader",
  join_date: ISODate("2011-10-15"),
  address: { ... },
  checked_out: [
     { _id: "123456789",
        title: "MongoDB: The Definitive Guide",
        authors: [ "Kristina Chodorow", "Mike Dirolf" ],
        checked_out: ISODate("2012-10-15")
     },
     { _id: "987654321"
        title: "MongoDB: The Scaling Adventure", ...
     }, ...
  ]
}
Referencing vs. Embedding
• Embedding is a bit like pre-joined data
• Document level ops are easy for server to
 handle
• Embed when the “many” objects always appear
 with (viewed in the context of) their parents.
• Reference when you need more flexibility
An Example
Single Table Inheritance
Single Table Inheritance

book = {
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ]
  published_date: ISODate("2010-09-24"),
  kind: ”loanable"
  locations: [ ... ]
  pages: 216,
  language: "English",
  publisher: {
      name: "O’Reilly Media",
      founded: "1980",
      location: "CA"
  }
}
An Example
Many to Many Relations
Books and Authors
book = {
  title: "MongoDB: The Definitive Guide",
  authors = [
      { _id: "kchodorow", name: ”Kristina Chodorow” },
      { _id: "mdirolf", name: ”Mike Dirolf” }
  ]
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English"
}

author = {
  _id: "kchodorow",
  name: "Kristina Chodorow",
  hometown: "New York"
}

db.authors.find ( { _id : ‘kchodorow’ } )
db.books.find( { authors.id : ‘kchodorow’ } )
An Example
Trees
Modeling Trees
• Parent Links
  - Each node is stored as a document
  - Contains the id of the parent
• Child Links
  - Each node contains the id’s of the children
  - Can support graphs (multiple parents / child)
Parent Links

book = {
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ],
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English",
  category: "MongoDB"
}

category = { _id: MongoDB, parent: Databases }
category = { _id: Databases, parent: Programming }
category = { _id: Programming }
Child Links

book = {
  _id: 123456789,
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ],
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English"
}

category = { _id: MongoDB, children: [ 123456789, … ] }
category = { _id: Databases, children: [ MongoDB, Postgres }
category = { _id: Programming, children: [ DB, Languages ] }
Array of Ancestors
book = {
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ],
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English",
  parent: ”MongoDB”,
  categories: [ Programming, Databases, MongoDB ]
}

book = {
  title: "MySQL: The Definitive Guide",
  authors: [ ”Michael Kofler" ],
  published_date: ISODate("2010-09-24"),
  pages: 320,
  language: "English",
  parent: ”MySQL",
  categories: [ Programming, Databases, MySQL ]
}

db.books.find( { categories : MongoDB } )
An Example
Queues
Book Document

book = {
  _id: 123456789,
  title: "MongoDB: The Definitive Guide",
  authors: [ "Kristina Chodorow", "Mike Dirolf" ],
  published_date: ISODate("2010-09-24"),
  pages: 216,
  language: "English",
  available: 3
}

db.books.findAndModify({
   query: { _id: 123456789, available: { "$gt": 0 } },
   update: { $inc: { available: -1 } }
})
#ConferenceHashTag




Thank You
Speaker Name
Job Title, 10gen

Weitere ähnliche Inhalte

Was ist angesagt?

Schema design
Schema designSchema design
Schema design
MongoDB
 
Schema Design
Schema DesignSchema Design
Schema Design
MongoDB
 
MongoDB Schema Design
MongoDB Schema DesignMongoDB Schema Design
MongoDB Schema Design
aaronheckmann
 
Schema Design
Schema Design Schema Design
Schema Design
MongoDB
 
Back to Basics 1: Thinking in documents
Back to Basics 1: Thinking in documentsBack to Basics 1: Thinking in documents
Back to Basics 1: Thinking in documents
MongoDB
 
Schema Design
Schema DesignSchema Design
Schema Design
MongoDB
 
Building Your First App with MongoDB
Building Your First App with MongoDBBuilding Your First App with MongoDB
Building Your First App with MongoDB
MongoDB
 
Building web applications with mongo db presentation
Building web applications with mongo db presentationBuilding web applications with mongo db presentation
Building web applications with mongo db presentation
Murat Çakal
 
MongoDB Schema Design
MongoDB Schema DesignMongoDB Schema Design
MongoDB Schema Design
Alex Litvinok
 

Was ist angesagt? (20)

Schema design
Schema designSchema design
Schema design
 
Schema Design
Schema DesignSchema Design
Schema Design
 
MongoDB Schema Design
MongoDB Schema DesignMongoDB Schema Design
MongoDB Schema Design
 
Schema Design
Schema Design Schema Design
Schema Design
 
MongoDB Schema Design
MongoDB Schema DesignMongoDB Schema Design
MongoDB Schema Design
 
Schema Design
Schema DesignSchema Design
Schema Design
 
Back to Basics 1: Thinking in documents
Back to Basics 1: Thinking in documentsBack to Basics 1: Thinking in documents
Back to Basics 1: Thinking in documents
 
Schema Design
Schema DesignSchema Design
Schema Design
 
Jumpstart: Schema Design
Jumpstart: Schema DesignJumpstart: Schema Design
Jumpstart: Schema Design
 
MongoDB San Francisco 2013: Schema design presented by Jason Zucchetto, Consu...
MongoDB San Francisco 2013: Schema design presented by Jason Zucchetto, Consu...MongoDB San Francisco 2013: Schema design presented by Jason Zucchetto, Consu...
MongoDB San Francisco 2013: Schema design presented by Jason Zucchetto, Consu...
 
Mongo DB schema design patterns
Mongo DB schema design patternsMongo DB schema design patterns
Mongo DB schema design patterns
 
MongoDB Schema Design: Four Real-World Examples
MongoDB Schema Design: Four Real-World ExamplesMongoDB Schema Design: Four Real-World Examples
MongoDB Schema Design: Four Real-World Examples
 
MongoDB Schema Design (Event: An Evening with MongoDB Houston 3/11/15)
MongoDB Schema Design (Event: An Evening with MongoDB Houston 3/11/15)MongoDB Schema Design (Event: An Evening with MongoDB Houston 3/11/15)
MongoDB Schema Design (Event: An Evening with MongoDB Houston 3/11/15)
 
Dev Jumpstart: Schema Design Best Practices
Dev Jumpstart: Schema Design Best PracticesDev Jumpstart: Schema Design Best Practices
Dev Jumpstart: Schema Design Best Practices
 
Building Your First App with MongoDB
Building Your First App with MongoDBBuilding Your First App with MongoDB
Building Your First App with MongoDB
 
Webinar: Schema Design
Webinar: Schema DesignWebinar: Schema Design
Webinar: Schema Design
 
Schema Design by Example ~ MongoSF 2012
Schema Design by Example ~ MongoSF 2012Schema Design by Example ~ MongoSF 2012
Schema Design by Example ~ MongoSF 2012
 
Schema Design
Schema DesignSchema Design
Schema Design
 
Building web applications with mongo db presentation
Building web applications with mongo db presentationBuilding web applications with mongo db presentation
Building web applications with mongo db presentation
 
MongoDB Schema Design
MongoDB Schema DesignMongoDB Schema Design
MongoDB Schema Design
 

Ähnlich wie Schema design mongo_boston

Schema Design
Schema DesignSchema Design
Schema Design
MongoDB
 
10gen Presents Schema Design and Data Modeling
10gen Presents Schema Design and Data Modeling10gen Presents Schema Design and Data Modeling
10gen Presents Schema Design and Data Modeling
DATAVERSITY
 

Ähnlich wie Schema design mongo_boston (19)

Schema Design
Schema DesignSchema Design
Schema Design
 
Webinar: Back to Basics: Thinking in Documents
Webinar: Back to Basics: Thinking in DocumentsWebinar: Back to Basics: Thinking in Documents
Webinar: Back to Basics: Thinking in Documents
 
Modeling JSON data for NoSQL document databases
Modeling JSON data for NoSQL document databasesModeling JSON data for NoSQL document databases
Modeling JSON data for NoSQL document databases
 
Schema design
Schema designSchema design
Schema design
 
Webinar: General Technical Overview of MongoDB for Dev Teams
Webinar: General Technical Overview of MongoDB for Dev TeamsWebinar: General Technical Overview of MongoDB for Dev Teams
Webinar: General Technical Overview of MongoDB for Dev Teams
 
Conceptos básicos. seminario web 3 : Diseño de esquema pensado para documentos
Conceptos básicos. seminario web 3 : Diseño de esquema pensado para documentosConceptos básicos. seminario web 3 : Diseño de esquema pensado para documentos
Conceptos básicos. seminario web 3 : Diseño de esquema pensado para documentos
 
Managing Social Content with MongoDB
Managing Social Content with MongoDBManaging Social Content with MongoDB
Managing Social Content with MongoDB
 
10gen Presents Schema Design and Data Modeling
10gen Presents Schema Design and Data Modeling10gen Presents Schema Design and Data Modeling
10gen Presents Schema Design and Data Modeling
 
Building your first app with mongo db
Building your first app with mongo dbBuilding your first app with mongo db
Building your first app with mongo db
 
Mongodb intro
Mongodb introMongodb intro
Mongodb intro
 
10gen MongoDB Video Presentation at WebGeek DevCup
10gen MongoDB Video Presentation at WebGeek DevCup10gen MongoDB Video Presentation at WebGeek DevCup
10gen MongoDB Video Presentation at WebGeek DevCup
 
MongoDB
MongoDBMongoDB
MongoDB
 
MongoDB Hadoop DC
MongoDB Hadoop DCMongoDB Hadoop DC
MongoDB Hadoop DC
 
MongoDB at RuPy
MongoDB at RuPyMongoDB at RuPy
MongoDB at RuPy
 
lecture_34e.pptx
lecture_34e.pptxlecture_34e.pptx
lecture_34e.pptx
 
Schema Design
Schema DesignSchema Design
Schema Design
 
Inferring Versioned Schemas from NoSQL Databases and its Applications
Inferring Versioned Schemas from NoSQL Databases and its ApplicationsInferring Versioned Schemas from NoSQL Databases and its Applications
Inferring Versioned Schemas from NoSQL Databases and its Applications
 
MongoDB at GUL
MongoDB at GULMongoDB at GUL
MongoDB at GUL
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
 

Mehr von MongoDB

Mehr von MongoDB (20)

MongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
MongoDB SoCal 2020: Migrate Anything* to MongoDB AtlasMongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
MongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
 
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
 
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
 
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDBMongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
 
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
 
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series DataMongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
 
MongoDB SoCal 2020: MongoDB Atlas Jump Start
 MongoDB SoCal 2020: MongoDB Atlas Jump Start MongoDB SoCal 2020: MongoDB Atlas Jump Start
MongoDB SoCal 2020: MongoDB Atlas Jump Start
 
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
 
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
 
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
 
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
 
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your MindsetMongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
 
MongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
MongoDB .local San Francisco 2020: MongoDB Atlas JumpstartMongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
MongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
 
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
 
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
 
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
 
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep DiveMongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
 
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & GolangMongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
 
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
 
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
 

Schema design mongo_boston

  • 2. Agenda • Working with documents • Evolving a Schema • Queries and Indexes • Common Patterns Single Table En
  • 3. RDBMS MongoDB Database ➜ Database Table ➜ Collection Row ➜ Document Index ➜ Index Join ➜ Embedded Document Foreign Key ➜ Reference Terminology
  • 8. Disk seeks and data locality Seek = 5+ ms Read = really really fast Post Comment Author Tags
  • 10. Disk seeks and data locality Article Author Comment Tag Comment Comment Comment Comment Comment
  • 13. Schema Design Considerations • How do we manipulate the data? – Dynamic Ad-Hoc Queries – Atomic Updates – Map Reduce • What are the access patterns of the application? – Read/Write Ratio – Types of Queries / Updates – Data life-cycle and growth rate
  • 14. Data Manipulation • Conditional Query Operators – Scalar: $ne, $mod, $exists, $type, $lt, $lte, $gt, $gte, $ne – Vector: $in, $nin, $all, $size • Atomic Update Operators – Scalar: $inc, $set, $unset – Vector: $push, $pop, $pull, $pushAll, $pullAll, $addToSet
  • 15. Data Access • Flexible Schemas • Ability to embed complex data structures • Secondary Indexes • Compound Indexes • Multi-Value Indexes (Indexes on Arrays) • Aggregation Framework – $project, $match, $limit, $skip, $sort, $group, $unwind • No Joins
  • 17. Library Management Application • Patrons • Books • Authors • Publishers
  • 18. An Example One to One Relations
  • 19. Modeling Patrons patron = { patron = { _id: "joe" _id: "joe" name: "Joe Bookreader” name: "Joe Bookreader", } address: { street: "123 Fake St. ", address = { city: "Faketon", patron_id = "joe", state: "MA", street: "123 Fake St. ", city: "Faketon", zip: 12345 state: "MA", } zip: 12345 } }
  • 20. One to One Relations • Mostly the same as the relational approach • Generally good idea to embed “contains” relationships • Document model provides a holistic representation of objects
  • 21. An Example One To Many Relations
  • 22. Modeling Patrons patron = { _id: "joe" name: "Joe Bookreader", join_date: ISODate("2011-10-15"), addresses: [ {street: "1 Vernon St.", city: "Newton", state: "MA", …}, {street: "52 Main St.", city: "Boston", state: "MA", …}, ] }
  • 23. Publishers and Books • Publishers put out many books • Books have one publisher
  • 24. Book MongoDB: The Definitive Guide, By Kristina Chodorow and Mike Dirolf Published: 9/24/2010 Pages: 216 Language: English Publisher: O’Reilly Media, CA
  • 25. Modeling Books – Embedded Publisher book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ] published_date: ISODate("2010-09-24"), pages: 216, language: "English", publisher: { name: "O’Reilly Media", founded: "1980", location: "CA" } }
  • 26. Modeling Books & Publisher Relationship publisher = { name: "O’Reilly Media", founded: "1980", location: "CA" } book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ] published_date: ISODate("2010-09-24"), pages: 216, language: "English" }
  • 27. Publisher _id as a Foreign Key publisher = { _id: "oreilly", name: "O’Reilly Media", founded: "1980", location: "CA" } book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ] published_date: ISODate("2010-09-24"), pages: 216, language: "English", publisher_id: "oreilly" }
  • 28. Book _id as a Foreign Key publisher = { name: "O’Reilly Media", founded: "1980", location: "CA" books: [ "123456789", ... ] } book = { _id: "123456789", title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ] published_date: ISODate("2010-09-24"), pages: 216, language: "English" }
  • 29. Where do you put the foreign Key? • Array of books inside of publisher – Makes sense when many means a handful of items – Useful when items have bound on potential growth • Reference to single publisher on books – Useful when items have unbounded growth (unlimited # of books) • SQL doesn’t give you a choice, no arrays
  • 30. Another Example One to Many Relations
  • 31. Books and Patrons • Book can be checked out by one Patron at a time • Patrons can check out many books (but not 1000s)
  • 32. Modeling Checkouts patron = { _id: "joe" name: "Joe Bookreader", join_date: ISODate("2011-10-15"), address: { ... } } book = { _id: "123456789" title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], ... }
  • 33. Modeling Checkouts patron = { _id: "joe" name: "Joe Bookreader", join_date: ISODate("2011-10-15"), address: { ... }, checked_out: [ { _id: "123456789", checked_out: "2012-10-15" }, { _id: "987654321", checked_out: "2012-09-12" }, ... ] }
  • 34. De-normalization Provides data locality De-normalize for speed
  • 35. Modeling Checkouts -- de- normalized patron = { _id: "joe" name: "Joe Bookreader", join_date: ISODate("2011-10-15"), address: { ... }, checked_out: [ { _id: "123456789", title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], checked_out: ISODate("2012-10-15") }, { _id: "987654321" title: "MongoDB: The Scaling Adventure", ... }, ... ] }
  • 36. Referencing vs. Embedding • Embedding is a bit like pre-joined data • Document level ops are easy for server to handle • Embed when the “many” objects always appear with (viewed in the context of) their parents. • Reference when you need more flexibility
  • 37. An Example Single Table Inheritance
  • 38. Single Table Inheritance book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ] published_date: ISODate("2010-09-24"), kind: ”loanable" locations: [ ... ] pages: 216, language: "English", publisher: { name: "O’Reilly Media", founded: "1980", location: "CA" } }
  • 39. An Example Many to Many Relations
  • 40. Books and Authors book = { title: "MongoDB: The Definitive Guide", authors = [ { _id: "kchodorow", name: ”Kristina Chodorow” }, { _id: "mdirolf", name: ”Mike Dirolf” } ] published_date: ISODate("2010-09-24"), pages: 216, language: "English" } author = { _id: "kchodorow", name: "Kristina Chodorow", hometown: "New York" } db.authors.find ( { _id : ‘kchodorow’ } ) db.books.find( { authors.id : ‘kchodorow’ } )
  • 42. Modeling Trees • Parent Links - Each node is stored as a document - Contains the id of the parent • Child Links - Each node contains the id’s of the children - Can support graphs (multiple parents / child)
  • 43. Parent Links book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English", category: "MongoDB" } category = { _id: MongoDB, parent: Databases } category = { _id: Databases, parent: Programming } category = { _id: Programming }
  • 44. Child Links book = { _id: 123456789, title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English" } category = { _id: MongoDB, children: [ 123456789, … ] } category = { _id: Databases, children: [ MongoDB, Postgres } category = { _id: Programming, children: [ DB, Languages ] }
  • 45. Array of Ancestors book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English", parent: ”MongoDB”, categories: [ Programming, Databases, MongoDB ] } book = { title: "MySQL: The Definitive Guide", authors: [ ”Michael Kofler" ], published_date: ISODate("2010-09-24"), pages: 320, language: "English", parent: ”MySQL", categories: [ Programming, Databases, MySQL ] } db.books.find( { categories : MongoDB } )
  • 47. Book Document book = { _id: 123456789, title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English", available: 3 } db.books.findAndModify({ query: { _id: 123456789, available: { "$gt": 0 } }, update: { $inc: { available: -1 } } })

Hinweis der Redaktion

  1. In the filing cabinet model, the patient’s x-rays, checkups, and allergies are stored in separate drawers and pulled together (like an RDBMS)In the file folder model, we store all of the patient information in a single folder (like MongoDB)
  2. Flexibility – Ability to represent rich data structuresPerformance – Benefit from data locality
  3. Concrete example of typical blog in typical relational normalized form
  4. Concrete example of typical blog in typical relational normalized form
  5. Concrete example of typical blog using a document oriented de-normalized approach
  6. Concrete example of typical blog in typical relational normalized form
  7. Tools for data manipulation
  8. Tools for data access
  9. Slow to get address data every time you query for a user. Requires an extra operation.
  10. Patron may have two addresses, in this case, you would need a separate table in a relation databaseWith MongoDB, you simply start storing the address field as an arrayOnly patrons which have multiple addresses could have this schema!No migration necessary! but Caution: Additional application logic required!
  11. Publisher is repeated for every book, data duplication!
  12. Publisher is better being a separate entity and having its own collection.
  13. Now to create a relation between the two entities, you can choose to reference the publisher from the book document.This is similar to the relational approach for this very same problem.
  14. OR: because we are using MongoDB and documents can have arrays you can choose to model the relation by creating and maintaining an array of books within each publisher entity.Careful with mutable, growing arrays. See next slide.
  15. Costly for a small number of books because to get the publisher
  16. And data locality provides speed
  17. Book’s kind attribute could be local or loanableNote that we have locations for loanable books but not for localNote that these two separate schemas can co-exist (loanable books / local books are both books)
  18. Note that we partially de-normalize here.To get books by a particular author: - get the author - get books that have that author id in array
  19. Simple solution. The biggest problem with this approach is getting an entire subtree requires several query turnarounds to the database
  20. It may also be good for storing graphs where a node has multiple parents.