Schema Design
Download as PPTX, PDF2 likes809 views
This document discusses schema design in MongoDB. It provides examples of embedding documents versus linking between collections to model one-to-one and one-to-many relationships. Common patterns like modeling trees with parent links or arrays of ancestors are demonstrated. The document also discusses single table inheritance in MongoDB by storing different types of documents in a single collection.
![Modeling Patrons
patron = { patron = {
_id: "joe", _id: "joe",
name: "Joe Bookreader", name: "Joe Bookreader",
address: { join_date: ISODate("2011-10-15"),
addresses: [
street: "123 Fake St. ",
{street: "1 Vernon St.", city: "Newton", …},
city: "Faketon", {street: "52 Main St.", city: "Boston", …},
state: "MA", ]
zip: 12345 }
}
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-20-320.jpg)
![Book Model with Embedded
Publisher
book = {
_id: “123”,
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"
}
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-24-320.jpg)
![Book Model with a Publisher
Link
publisher = {
_id: “oreilly”,
name: "O’Reilly Media",
founded: "1980",
location: "CA"
}
book = {
_id: “123”,
publisher_id: “oreilly”,
title: "MongoDB: The Definitive Guide",
authors: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English"
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-27-320.jpg)
![Publisher Model with Book
Links
publisher = {
_id: “oreilly”,
name: "O’Reilly Media",
founded: "1980",
location: "CA“,
books: [“123”,…]
}
book = {
_id: “123”,
title: "MongoDB: The Definitive Guide",
authors: [ "Kristina Chodorow", "Mike Dirolf" ]
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English"
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-29-320.jpg)
![Relation stored on book end
book = {
title: "MongoDB: The Definitive Guide",
authors = ["kchodorow", "mdirolf“],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English"
}
author = {
_id: "kchodorow",
name: "Kristina Chodorow",
hometown: "New York"
}
author = {
_id: “mdirolf”,
name: “Mike Dirolf",
hometown: “Albany"
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-32-320.jpg)
![Relation stored on book end
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"
}
author = {
_id: “mdirolf”,
name: “Mike Dirolf",
hometown: “Albany"
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-33-320.jpg)
![Relation stored on author end
book = {
_id: “123”,
title: "MongoDB: The Definitive Guide",
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English"
}
author = {
_id: "kchodorow",
name: "Kristina Chodorow",
hometown: "Cincinnati",
books: [ {id: “123”, title : "MongoDB: The Definitive Guide“ } ]
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-35-320.jpg)
![Relation stored on both sides
book = {
_id: “123”,
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: "Cincinnati",
books: [ {id: “123”, title : "MongoDB: The Definitive Guide“ } ]
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-36-320.jpg)
![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” }](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-40-320.jpg)
![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: ["MongoDB", "Databases", "Programming" ]
}
book = {
title: "MySQL: The Definitive Guide",
authors: [ ”Michael Kofler" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English",
parent: "MySQL",
categories : ["MySQL", "Databases", "Programming" ]
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-41-320.jpg)
![Ancestors as path
book = {
title: "MongoDB: The Definitive Guide",
authors: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English",
category: "MongoDB/Databases/Programming"
}
book = {
title: "MySQL: The Definitive Guide",
authors: [ ”Michael Kofler" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English",
parent: "MySQL",
category: "MySQL/Databases/Programming"
}](https://image.slidesharecdn.com/schemadesign-130306113422-phpapp01/85/Schema-Design-42-320.jpg)
Ad
More Related Content
What's hot (19)
Similar to Schema Design (20)
Ad
More from MongoDB (20)
![MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]](https://cdn.slidesharecdn.com/ss_thumbnails/315pminfosysfinalsfoversionvocalpart1-200120221508-thumbnail.jpg?width=560&fit=bounds)
Ad
Schema Design
- 1. #MongoDBDays Schema Design Craig Wilson Software Engineer, 10gen @craiggwilson
- 2. Agenda • Working with Documents • Schema Design by Example • Common Patterns Single Table En
- 3. RDBMS MongoDB Database ➜ Database Table ➜ Collection Row ➜ Document Index ➜ Index Join ➜ Embedding & Linking Terminology
- 6. Embedding Linking Example Schema (MongoDB)
- 9. Traditional Schema Design Focuses on data storage
- 10. Document Schema Design Focuses on data use
- 11. Document Schema Design • Read Heavy? • Write Heavy? – Document Growth • Analytics – Map Reduce – External System
- 12. Tools for Working with Data • Dynamic Schemas • Embedded data structures • Ad-hoc queries – Simple Queries – Aggregation Framework • Secondary indexes • Multi-Key indexes
- 13. Tools for Manipulating Data • On the way out – Scalar: $ne, $mod, $exists, $type, $lt, $lte, $gt, $gte, $ne – Vector: $in, $nin, $all, $size • On the way in – Scalar: $inc, $set, $unset – Vector: $push, $pop, $pull, $pushAll, $pullAll, $addToSet
- 15. Library Management Application • Patrons • Books • Authors • Publishers
- 16. Use Case #1 As a Librarian, when I swipe a patron’s card, I need to verify their address.
- 17. Modeling Patrons patron = { patron = { _id: "joe“, _id: "joe", name: "Joe Bookreader” name: "Joe Bookreader", } address: { street: "123 Fake St. ", address = { city: "Faketon", _id = "joe“, state: "MA", street: "123 Fake St. ", city: "Faketon", zip: 12345 state: "MA", } zip: 12345 } }
- 18. One to One Relations • “Belongs to” relationships are often embedded • Document model provides a holistic representation of objects with embedded entities • Optimized for read performance
- 19. Use Case #2 As a Librarian, I want to store multiple addresses so I have a better chance of getting my book back.
- 20. Modeling Patrons patron = { patron = { _id: "joe", _id: "joe", name: "Joe Bookreader", name: "Joe Bookreader", address: { join_date: ISODate("2011-10-15"), addresses: [ street: "123 Fake St. ", {street: "1 Vernon St.", city: "Newton", …}, city: "Faketon", {street: "52 Main St.", city: "Boston", …}, state: "MA", ] zip: 12345 } } }
- 21. Use Case #3 As a Librarian, I want to see to the publisher of a book.
- 22. Publishers and Books • Publishers put out many books • Books have one publisher
- 23. Book Data MongoDB: The Definitive Guide, By Kristina Chodorow and Mike Dirolf Published: 9/24/2010 Pages: 216 Language: English Publisher: O’Reilly Media, CA
- 24. Book Model with Embedded Publisher book = { _id: “123”, 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" } }
- 25. Book Model with Embedded Publisher • Optimized for read performance of Books • Other queries are difficult – All publishers
- 26. Use Case #4 As a Librarian, I want to see all the publishers in the system.
- 27. Book Model with a Publisher Link publisher = { _id: “oreilly”, name: "O’Reilly Media", founded: "1980", location: "CA" } book = { _id: “123”, publisher_id: “oreilly”, title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English" }
- 28. Use Case #5 As a Librarian, I want to see all the books a publisher has published.
- 29. Publisher Model with Book Links publisher = { _id: “oreilly”, name: "O’Reilly Media", founded: "1980", location: "CA“, books: [“123”,…] } book = { _id: “123”, title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ] published_date: ISODate("2010-09-24"), pages: 216, language: "English" }
- 30. Use Case #6 As a Librarian, I want to find the author(s) of book “Foo”.
- 31. Books and Authors book = { _id: “123”, title: "MongoDB: The Definitive Guide", published_date: ISODate("2010-09-24"), pages: 216, language: "English" } author = { _id: “kchodorow”, name: "Kristina Chodorow", hometown: "New York" } author = { _id: “mdirolf”, name: “Mike Dirolf", hometown: “Albany" }
- 32. Relation stored on book end book = { title: "MongoDB: The Definitive Guide", authors = ["kchodorow", "mdirolf“], published_date: ISODate("2010-09-24"), pages: 216, language: "English" } author = { _id: "kchodorow", name: "Kristina Chodorow", hometown: "New York" } author = { _id: “mdirolf”, name: “Mike Dirolf", hometown: “Albany" }
- 33. Relation stored on book end 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" } author = { _id: “mdirolf”, name: “Mike Dirolf", hometown: “Albany" }
- 34. Use Case #7 As a Librarian, I want to find other books written by the same author.
- 35. Relation stored on author end book = { _id: “123”, title: "MongoDB: The Definitive Guide", published_date: ISODate("2010-09-24"), pages: 216, language: "English" } author = { _id: "kchodorow", name: "Kristina Chodorow", hometown: "Cincinnati", books: [ {id: “123”, title : "MongoDB: The Definitive Guide“ } ] }
- 36. Relation stored on both sides book = { _id: “123”, 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: "Cincinnati", books: [ {id: “123”, title : "MongoDB: The Definitive Guide“ } ] }
- 37. Linking vs. Embedding • Embedding – Great for read performance • One seek to load entire object • One roundtrip to database – Writes can be slow – Maintaining data integrity • Linking – More flexibility – Data integrity is maintained – Work is done during reads
- 38. Common Patterns
- 39. An Example Trees
- 40. 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” }
- 41. 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: ["MongoDB", "Databases", "Programming" ] } book = { title: "MySQL: The Definitive Guide", authors: [ ”Michael Kofler" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English", parent: "MySQL", categories : ["MySQL", "Databases", "Programming" ] }
- 42. Ancestors as path book = { title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English", category: "MongoDB/Databases/Programming" } book = { title: "MySQL: The Definitive Guide", authors: [ ”Michael Kofler" ], published_date: ISODate("2010-09-24"), pages: 216, language: "English", parent: "MySQL", category: "MySQL/Databases/Programming" }
- 44. Single Table Inheritance id type area radius length width 1 circle 3.14 1 2 square 4 2 3 rect 10 5 2 • Sparse data • Is missing value not required or an error?
- 45. Single collection (table) inheritance - MongoDB > db.shapes.find() { _id : 1, type: "circle", area : 3.14, radius : 1 } { _id : 2, type: "square", area : 4, length : 2 } { _id : 3, type: "rect", area : 10, length : 5, width : 2 }
- 46. Summary • Schema design is different in MongoDB • Basic data design principals stay the same • Focus on how application accesses/manipulates data • Rapidly evolve schema to meet your requirements
- 47. #MongoDBDays Thank You Craig Wilson Software Engineer, 10gen @craiggwilson
Editor's Notes
- #5: Concrete example of typical blog using a document oriented de-normalized approach
- #9: Represent rich data structures and complex relationships while keeping that data together on disk.
- #10: Focus on the way we store our data, neglecting the way we use it.
- #11: Document design cares first about how it’s used and we let that drive how we store the data.
- #13: Tools for data access
- #18: Slow to get address data every time you query for a user. Requires an extra operation.
- #21: Patron may have multiple addressesWith MongoDB, you simply start storing the address field as an array
- #25: Data duplication is OK!Publisher is immutable.
- #26: Best way to figure out something is going to perform is to measure.
- #28: What happens when oreilly moves? Do all the books have their publisher location changed?
- #30: Keep in mind that consistently growing documents is not good.
- #32: To get the authors given a book:- Single queryTo get books by a particular author: - get the author id - get books that have that author id in array
- #33: To get the authors given a book:- Single queryTo get books by a particular author: - get the author id - get books that have that author id in array
- #34: To get the authors given a book:- Single queryTo get books by a particular author: - get the author id - get books that have that author id in array
- #36: Getting the title of book published by an author is a single queryGetting the authors of a book. 2 queriesGet the book idQuery the author for books in the id
- #38: Rule is to measure.
- #41: Easy to query by parent category.Hard to find in subcategories.
- #43: Immediate parent is regexp query that is anchored to beginningAnywhere in the hierarchy is a regexp query.Not indexedHierachy information cannot be changed