Modeling Data in MongoDB
- 1. Modeling Data in MongoDB Luke Ehresman http://copperegg.com
- 3. Schema Design Wait, isn’t MongoDB schemaless?
- 4. Schema Design Wait, isn’t MongoDB schemaless? Nope! (just no predefined schema)
- 5. Schema Design Wait, isn’t MongoDB schemaless? Nope! (just no predefined schema) That means it’s up to your application.
- 6. Schema Design (Relational)
- 7. Schema Design (Relational) • Tabular data - Tables, Rows, Columns
- 8. Schema Design (Relational) • Tabular data - Tables, Rows, Columns • Normalized - flatten your data
- 9. Schema Design (Relational) • Tabular data - Tables, Rows, Columns • Normalized - flatten your data • Columns with simple values (int, varchar)
- 10. Schema Design (Relational) • Tabular data - Tables, Rows, Columns • Normalized - flatten your data • Columns with simple values (int, varchar) • Relate rows with foreign key references
- 11. Schema Design (Relational) • Tabular data - Tables, Rows, Columns • Normalized - flatten your data • Columns with simple values (int, varchar) • Relate rows with foreign key references • Reuse, don’t repeat (i.e. person)
- 12. Schema Design (Relational) • Tabular data - Tables, Rows, Columns • Normalized - flatten your data • Columns with simple values (int, varchar) • Relate rows with foreign key references • Reuse, don’t repeat (i.e. person) • Indexes on values
- 13. Schema Design (MongoDB - Non-Relational)
- 14. Schema Design (MongoDB - Non-Relational) • Databases > Collections > Documents
- 15. Schema Design (MongoDB - Non-Relational) • Databases > Collections > Documents • Simple or complex values (ints, strings, objects, arrays)
- 16. Schema Design (MongoDB - Non-Relational) • Databases > Collections > Documents • Simple or complex values (ints, strings, objects, arrays) • Documents are monolithic units
- 17. Schema Design (MongoDB - Non-Relational) • Databases > Collections > Documents • Simple or complex values (ints, strings, objects, arrays) • Documents are monolithic units • Embedded complex data structures
- 18. Schema Design (MongoDB - Non-Relational) • Databases > Collections > Documents • Simple or complex values (ints, strings, objects, arrays) • Documents are monolithic units • Embedded complex data structures • No joins - repeat data for faster access
- 19. Schema Design (MongoDB - Non-Relational) • Databases > Collections > Documents • Simple or complex values (ints, strings, objects, arrays) • Documents are monolithic units • Embedded complex data structures • No joins - repeat data for faster access • Difficult to relate documents together
- 20. How will you use it?
- 21. How will you use it? • The best way to use MongoDB is to tailor your schema to how it will be used
- 22. How will you use it? • The best way to use MongoDB is to tailor your schema to how it will be used • Things to consider:
- 23. How will you use it? • The best way to use MongoDB is to tailor your schema to how it will be used • Things to consider: • minimize reads and/or writes
- 24. How will you use it? • The best way to use MongoDB is to tailor your schema to how it will be used • Things to consider: • minimize reads and/or writes • more writes, fewer reads? (read heavy)
- 25. How will you use it? • The best way to use MongoDB is to tailor your schema to how it will be used • Things to consider: • minimize reads and/or writes • more writes, fewer reads? (read heavy) • more reads, fewer writes? (write heavy)
- 26. How will you use it?
- 27. How will you use it? • Combine objects into one document if you will use them together.
- 28. How will you use it? • Combine objects into one document if you will use them together. • Example: Authors and Books
- 29. How will you use it? • Combine objects into one document if you will use them together. • Example: Authors and Books • Separate them if they need to be used separately -- but beware, no joins!
- 30. How will you use it? • Combine objects into one document if you will use them together. • Example: Authors and Books • Separate them if they need to be used separately -- but beware, no joins! • Or duplicate the data -- but beware!
- 31. Precompute!
- 32. Precompute! • Philosophy: do work before reads occur
- 33. Precompute! • Philosophy: do work before reads occur • Disk space is cheap - compute time is not (it’s expensive because users wait)
- 34. Precompute! • Philosophy: do work before reads occur • Disk space is cheap - compute time is not (it’s expensive because users wait) • Do joins on write, not on read
- 35. Precompute! • Philosophy: do work before reads occur • Disk space is cheap - compute time is not (it’s expensive because users wait) • Do joins on write, not on read • Do complex aggregation ahead of time
- 36. Precompute! • Philosophy: do work before reads occur • Disk space is cheap - compute time is not (it’s expensive because users wait) • Do joins on write, not on read • Do complex aggregation ahead of time • Optimize for specific use cases
- 37. Precompute! • Philosophy: do work before reads occur • Disk space is cheap - compute time is not (it’s expensive because users wait) • Do joins on write, not on read • Do complex aggregation ahead of time • Optimize for specific use cases • Delayed data is not always bad in real life
- 38. Aggregation
- 40. Aggregation • Application • MapReduce (BEWARE!)
- 41. Aggregation • Application • MapReduce (BEWARE!) • Group
- 42. Aggregation • Application • MapReduce (BEWARE!) • Group • Aggregation framework (coming in 2.2)
- 43. Atomicity
- 44. Atomicity • MongoDB does have atomic transactions
- 45. Atomicity • MongoDB does have atomic transactions • Scope is a single document
- 46. Atomicity • MongoDB does have atomic transactions • Scope is a single document • Keep this in mind when designing schemas
- 47. Atomicity
- 48. Atomicity • $inc
- 50. Atomicity • $inc • $push • $addToSet
- 51. Atomicity • $inc • $push • $addToSet • upsert (create-if-none-else-update)
- 52. Atomicity • Upsert example db.stats.update({_id: ‘lehresman’}, {$inc: {logins: 1}, $set: {last_login: new Date()}}, true); • {_id:‘lehresman’, logins:1, last_login:A} • {_id:‘lehresman’, logins:2, last_login:B}
- 53. Example: Books • Many books • Many authors • Authors write many books
- 54. Example: Books Bad N oSQL • Many books Ex ample!! • Many authors • Authors write many books
- 55. Example: User Stats • You have users • Track what pages they visit
- 56. Example: User Stats “users” collection { _id: ‘lehresman’, first_name: ‘Luke’, last_name: ‘Ehresman’, page_visits: { ‘/’: 78, ‘/profile’: 33, ‘/blog/38919’: 2 } Problem: What if you want } aggregate stats across users?
- 57. Example: User Stats “visits” collection { _id: ‘/’, visits: 73889 } { _id: ‘/profile’, visits: 9341 } { _id: ‘/blog/38919’ visits: 1678 }
- 58. Example: User Stats “visits” collection { _id: ‘/’, visits: 73889 } { _id: ‘/profile’, visits: 9341 } { _id: ‘/blog/38919’ Problems: visits: 1678 } No user tracking; What if you want aggregate stats by day?
- 59. Example: User Stats “visits” collection { _id: ‘/’, visits: 73889, { ‘2012-06-01’: 839, ‘2012-06-02’: 767, ‘2012-06-03’: 881 }
- 60. Example: User Stats “visits” collection { _id: ‘/’, visits: 73889, { ‘2012-06-01’: 839, ‘2012-06-02’: 767, ‘2012-06-03’: 881 } Problems: No user tracking; Possibly too large eventually. Always grows.
- 61. Example: User Stats “visits” collection { date: ‘2012-06-01’, page: ‘/’, visits: 839, users: { ‘lehresman’: 78, ‘billybob’: 761 } }
- 62. Example: User Stats “visits” collection { date: ‘2012-06-01’, page: ‘/’, visits: 839, users: { ‘lehresman’: 78, ‘billybob’: 761 } } No relational integrity. (up to your application to handle null cases)
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: \n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: \n
- #47: \n
- #48: \n
- #49: \n
- #50: \n