Downloaded 178 times
More Related Content
Similar to Strengths and Weaknesses of MongoDB
Strengths and Weaknesses of MongoDB
- 1. MongoDB: Strengths & Weaknesses Presented by Luke Ehresman http://copperegg.com
- 2. A.K.A. “Knowing when touse a hammer, and when to use a screwdriver.”
- 3. Where did wecome from?
- 4. Where did wecome from? The state of things a few years ago:
- 5. Where did wecome from? The state of things a few years ago: • Relational ruled
- 6. Where did wecome from? The state of things a few years ago: • Relational ruled • Normalize everything
- 7. Where did wecome from? The state of things a few years ago: • Relational ruled • Normalize everything • Shove it into a relational database
- 8. Where did wecome from? The state of things a few years ago: • Relational ruled • Normalize everything • Shove it into a relational database • The web grew, very large sites are common
- 9. What is relational? Normalized data that relates to each other
- 10. What is relational? Normalized data that relates to each other id name family_id id Family 1 Luke 1 1 Ehresman 2 Jetson 2 Fred 4 3 Smurf 3 George 2 4 Flintstone 4 Elroy 2 5 Papa 3
- 11. What is relational? Normalized data that relates to each other id name family_id id Family 1 Luke 1 1 Ehresman 2 Jetson 2 Fred 4 3 Smurf 3 George 2 4 Flintstone 4 Elroy 2 5 Papa 3 Great for: • data reuse • data integrity • enforcing constraints • enforcing schema
- 12.
- 13. Example use cases •Users with Accounts that have Transactions with Line Items
- 14. Example use cases •Users with Accounts that have Transactions with Line Items • Person with Votes and Comments
- 15. Example use cases •Users with Accounts that have Transactions with Line Items • Person with Votes and Comments • Blog with Articles and Users who Vote and leave Comments
- 16.
- 17. Relational DBs giveyou • Durability (guarantees that data is written)
- 18. Relational DBs giveyou • Durability (guarantees that data is written) • Consistency (enforcing constraints)
- 19. Relational DBs giveyou • Durability (guarantees that data is written) • Consistency (enforcing constraints) • Guarantees of atomicity
- 20. Relational DBs giveyou • Durability (guarantees that data is written) • Consistency (enforcing constraints) • Guarantees of atomicity • Data portability (with modern SQL dbs)
- 21. Relational DBs giveyou • Durability (guarantees that data is written) • Consistency (enforcing constraints) • Guarantees of atomicity • Data portability (with modern SQL dbs) • Slice and dice data, willy-nilly (SQL)
- 23. Sometimes you just don’t care.
- 24. Sometimes you just don’t care.
- 25. Sometimes you just don’t care. • Sometimes speed is more important
- 26. Sometimes you just don’t care. • Sometimes speed is more important • Sometimes data is highly segmented
- 27. Sometimes you just don’t care. • Sometimes speed is more important • Sometimes data is highly segmented • Sometimes you can trust your app
- 28. Sometimes you just don’t care. • Sometimes speed is more important • Sometimes data is highly segmented • Sometimes you can trust your app • Sometimes you know how data will be queried
- 29. Sometimes you just don’t care. • Sometimes speed is more important • Sometimes data is highly segmented • Sometimes you can trust your app • Sometimes you know how data will be queried • Sometimes you don’t need everything that normalization and relational DBs give you
- 30. Sometimes you just don’t care. • Sometimes speed is more important • Sometimes data is highly segmented • Sometimes you can trust your app • Sometimes you know how data will be queried • Sometimes you don’t need everything that normalization and relational DBs give you • Sometimes it’s not the end of the world if you lose some of your data
- 31.
- 32. Example use cases •Blog with Comments (?? Really??)
- 33. Example use cases •Blog with Comments (?? Really??) • Logging tons of data
- 34. Example use cases •Blog with Comments (?? Really??) • Logging tons of data • Pre-processed data warehousing
- 35.
- 36. Enter: NoSQL • Theseuse cases are exactly why NoSQL databases have become popular
- 37. Enter: NoSQL • Theseuse cases are exactly why NoSQL databases have become popular • Perhaps too popular (but we’ll get to that)
- 38. Enter: NoSQL • Theseuse cases are exactly why NoSQL databases have become popular • Perhaps too popular (but we’ll get to that) • Store MASSIVE amounts of data
- 39. Enter: NoSQL • Theseuse cases are exactly why NoSQL databases have become popular • Perhaps too popular (but we’ll get to that) • Store MASSIVE amounts of data • Very (VERY) fast retrieval
- 40. Enter: NoSQL • Theseuse cases are exactly why NoSQL databases have become popular • Perhaps too popular (but we’ll get to that) • Store MASSIVE amounts of data • Very (VERY) fast retrieval • Usually better scalability than RDBMS
- 41. Know Thyself (and thy data)
- 42. Know Thyself (and thy data)
- 43. Know Thyself (and thy data) • Why are you considering MongoDB?
- 44. Know Thyself (and thy data) • Why are you considering MongoDB? • How will your data be queried?
- 45. Know Thyself (and thy data) • Why are you considering MongoDB? • How will your data be queried? • How big do you need to scale?
- 46. Know Thyself (and thy data) • Why are you considering MongoDB? • How will your data be queried? • How big do you need to scale? • Are you read-heavy, or write-heavy?
- 47. Know Thyself (and thy data)
- 48. Know Thyself (and thy data) • Read-heavy data
- 49. Know Thyself (and thy data) • Read-heavy data • Slave reads?
- 50. Know Thyself (and thy data) • Read-heavy data • Slave reads? • Size of data? Store it all in RAM?
- 51. Know Thyself (and thy data) • Read-heavy data • Slave reads? • Size of data? Store it all in RAM? • Covered indexes for subset queries?
- 52. Know Thyself (and thy data) • Read-heavy data • Slave reads? • Size of data? Store it all in RAM? • Covered indexes for subset queries? • How will you be querying?
- 53. Know Thyself (and thy data)
- 54. Know Thyself (and thy data) • Write-heavy data
- 55. Know Thyself (and thy data) • Write-heavy data • Insert vs. update/upsert?
- 56. Know Thyself (and thy data) • Write-heavy data • Insert vs. update/upsert? • Number of indexes?
- 57. Know Thyself (and thy data) • Write-heavy data • Insert vs. update/upsert? • Number of indexes? • Cluster design (many small shards)?
- 58. Know Thyself (and thy data) • Write-heavy data • Insert vs. update/upsert? • Number of indexes? • Cluster design (many small shards)? • Durability? Safe writes, or not? Journaling?
- 59. Not all createdequal
- 60. Not all createdequal • SQL (MySQL, Postgres, SQL Server, Oracle)
- 61. Not all createdequal • SQL (MySQL, Postgres, SQL Server, Oracle) • MongoDB, Riak, Cassandra, ...
- 62. Not all createdequal • SQL (MySQL, Postgres, SQL Server, Oracle) • MongoDB, Riak, Cassandra, ... • Key/Value (Redis, Tokyo Tyrant)
- 63.
- 64.
- 65. from SQL ISDEAD!
- 66.
- 67. from SQL ISDEAD! NoSQL and MongoDB are great additions to your toolbox. Use as needed.
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
- #51 \n
- #52 \n
- #53 \n
- #54 \n