This document discusses schema design patterns for MongoDB. It begins by comparing terminology between relational databases and MongoDB. Common patterns for modeling one-to-one, one-to-many, and many-to-many relationships are presented using examples of patrons, books, authors, and publishers. Embedded documents are recommended when related data always appears together, while references are used when more flexibility is needed. The document emphasizes focusing on how the application accesses and manipulates data when deciding between embedded documents and references. It also stresses evolving schemas to meet changing requirements and application logic.

1. Emily Stolfo
#mongodbdays
Schema Design
Ruby Engineer/Evangelist, 10gen
@EmStolfo

2. Agenda
• Working with documents
• Common patterns
• Queries and Indexes

3. Terminology
RDBMS MongoDB
Database ➜ Database
Table ➜ Collection
Row ➜ Document
Index ➜ Index
Join ➜ Embedded Document
Foreign Key ➜ Reference

4. Working with Documents

5. Documents
Provide flexibility and
performance

6. Example Schema (MongoDB)

7. Embedding
Example Schema (MongoDB)

8. Embedding
Linking
Example Schema (MongoDB)

9. Relational Schema Design
Focuses on data storage

10. Document Schema Design
Focuses on data use

11. Schema Design Considerations
• What is a priority?
– High consistency
– High read performance
– High write performance
• How does the application access and manipulate
data?
– Read/Write Ratio
– Types of Queries / Updates
– Data life-cycle and growth
– Analytics (Map Reduce, Aggregation)

12. Tools for Data Access
• Flexible Schemas
• Embedded data structures
• Secondary Indexes
• Multi-Key Indexes
• Aggregation Framework
– Pipeline operators: $project, $match, $limit,
$skip, $sort, $group, $unwind
• No Joins

13. 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

14. Schema Design
Example

15. Library Management
Application
• Patrons
• Books
• Authors
• Publishers

16. One to One Relations
example

17. patron = {
_id: "joe"
name: "Joe Bookreader”
}
address = {
patron_id = "joe",
street: "123 Fake St. ",
city: "Faketon",
state: "MA",
zip: 12345
}
Modeling Patrons
patron = {
_id: "joe"
name: "Joe Bookreader",
address: {
street: "123 Fake St. ",
city: "Faketon",
state: "MA",
zip: 12345
}
}

18. One to One Relations
• “Contains” relationships are often
embedded.
• Document provides a holistic representation
of objects with embedded entities.
• Optimized read performance.

19. examples
One To Many Relations

20. 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", …},
]
}
Patrons with many addresses

21. example 2
Publishers and Books
One to Many Relations

22. Publishers and Books relation
• Publishers put out many books
• Books have one publisher

23. MongoDB: The Definitive Guide,
By Kristina Chodorow and Mike Dirolf
Published: 9/24/2010
Pages: 216
Language: English
Publisher: O’Reilly Media, CA
Book Data

24. 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"
}
}
Book Model with Embedded Publisher

25. 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"
}
Book Model with Normalized Publisher

26. 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"
}
Link with Publisher _id as a
Reference

27. 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"
}
Link with Book _ids as a Reference

28. Where do you put the reference?
• Reference to single publisher on books
– Use when items have unbounded growth (unlimited # of
books)
• Array of books in publisher document
– Optimal when many means a handful of items
– Use when there is a bound on potential growth

29. example 3
Books and Patrons
One to Many Relations

30. Books and Patrons
• Book can be checked out by one Patron at a
time
• Patrons can check out many books (but not
1000s)

31. 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

32. 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" },
...
]
}
Modeling Checkouts

33. De-normalization
Provides data locality

34. 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", ...
}, ...
]
}
Modeling Checkouts - de-normalized

35. Referencing vs. Embedding
• Embedding is a bit like pre-joining data
• Document level operations are easy for the
server to handle
• Embed when the “many” objects always
appear with (viewed in the context of) their
parents.
• Reference when you need more flexibility
How does your application access and
manipulate data?

36. example
Many to Many Relations

37. book = {
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"
}
Books and Authors

38. 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"
}
Relation stored in Book
document

39. book = {
_id: 123456789
title: "MongoDB: The Definitive Guide",
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English"
}
author = {
_id: "kchodorow",
name: "Kristina Chodorow",
hometown: "Cincinnati",
books: [ {book_id: 123456789, title : "MongoDB: The Definitive Guide" }]
}
Relation stored in Author
document

40. book = {
_id: 123456789
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",
books: [ 123456789, ... ]
}
author = {
_id: "mdirolf",
name: "Mike Dirolf",
hometown: "Albany",
books: [ 123456789, ... ]
}
Relation stored in both
documents

41. 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.books.find( { authors.name : "Kristina Chodorow" } )
Where do you put the reference?
Think about common queries

42. Where do you put the reference?
Think about indexes
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.books.createIndex( { authors.name : 1 } )

43. Summary
• Schema design is different in MongoDB
• Basic data design principals apply
• Focus on how application accesses and
manipulates data
• Evolve schema to meet changing
requirements
• Application-level logic is important!

44. Emily Stolfo
#mongodbdays
Thank You
Ruby Engineer/Evangelist, 10gen
@EmStolfo