Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
MongoDB:Strengths & Weaknesses    Presented by Luke Ehresman       http://copperegg.com
A.K.A.“Knowing when to usea hammer, and when to  use a screwdriver.”
Where did we come from?
Where did we come from? The state of things a few years ago:
Where did we come from? The state of things a few years ago:  • Relational ruled
Where did we come from? The state of things a few years ago:  • Relational ruled  • Normalize everything
Where did we come from? The state of things a few years ago:  • Relational ruled  • Normalize everything  • Shove it into ...
Where did we come from? The state of things a few years ago:  • Relational ruled  • Normalize everything  • Shove it into ...
What is relational?      Normalized data that relates to each other
What is relational?               Normalized data that relates to each other id   name        family_id         id        ...
What is relational?               Normalized data that relates to each other id   name        family_id         id        ...
Example use cases
Example use cases• Users with Accounts that have  Transactions with Line Items
Example use cases• Users with Accounts that have  Transactions with Line Items• Person with Votes and Comments
Example use cases• Users with Accounts that have  Transactions with Line Items• Person with Votes and Comments• Blog with ...
Relational DBs give you
Relational DBs give you• Durability (guarantees that data is written)
Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)
Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)• Guarantees of ...
Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)• Guarantees of ...
Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)• Guarantees of ...
Sometimes you just   don’t care.
Sometimes you just   don’t care.
Sometimes you just       don’t care.•   Sometimes speed is more important
Sometimes you just       don’t care.•   Sometimes speed is more important•   Sometimes data is highly segmented
Sometimes you just       don’t care.•   Sometimes speed is more important•   Sometimes data is highly segmented•   Sometim...
Sometimes you just       don’t care.•   Sometimes speed is more important•   Sometimes data is highly segmented•   Sometim...
Sometimes you just       don’t care.•   Sometimes speed is more important•   Sometimes data is highly segmented•   Sometim...
Sometimes you just       don’t care.•   Sometimes speed is more important•   Sometimes data is highly segmented•   Sometim...
Example use cases
Example use cases• Blog with Comments (?? Really??)
Example use cases• Blog with Comments (?? Really??)• Logging tons of data
Example use cases• Blog with Comments (?? Really??)• Logging tons of data• Pre-processed data warehousing
Enter: NoSQL
Enter: NoSQL• These use cases are exactly why NoSQL  databases have become popular
Enter: NoSQL• These use cases are exactly why NoSQL  databases have become popular• Perhaps too popular (but we’ll get to ...
Enter: NoSQL• These use cases are exactly why NoSQL  databases have become popular• Perhaps too popular (but we’ll get to ...
Enter: NoSQL• These use cases are exactly why NoSQL  databases have become popular• Perhaps too popular (but we’ll get to ...
Enter: NoSQL• These use cases are exactly why NoSQL  databases have become popular• Perhaps too popular (but we’ll get to ...
Know Thyself   (and thy data)
Know Thyself   (and thy data)
Know Thyself              (and thy data)• Why are you considering MongoDB?
Know Thyself              (and thy data)• Why are you considering MongoDB?• How will your data be queried?
Know Thyself              (and thy data)• Why are you considering MongoDB?• How will your data be queried?• How big do you...
Know Thyself               (and thy data)• Why are you considering MongoDB?• How will your data be queried?• How big do yo...
Know Thyself   (and thy data)
Know Thyself           (and thy data)• Read-heavy data
Know Thyself           (and thy data)• Read-heavy data • Slave reads?
Know Thyself                (and thy data)• Read-heavy data • Slave reads? • Size of data? Store it all in RAM?
Know Thyself               (and thy data)• Read-heavy data • Slave reads? • Size of data? Store it all in RAM? • Covered i...
Know Thyself               (and thy data)• Read-heavy data • Slave reads? • Size of data? Store it all in RAM? • Covered i...
Know Thyself   (and thy data)
Know Thyself            (and thy data)• Write-heavy data
Know Thyself                (and thy data)• Write-heavy data • Insert vs. update/upsert?
Know Thyself                (and thy data)• Write-heavy data • Insert vs. update/upsert? • Number of indexes?
Know Thyself               (and thy data)• Write-heavy data • Insert vs. update/upsert? • Number of indexes? • Cluster des...
Know Thyself                (and thy data)• Write-heavy data • Insert vs. update/upsert? • Number of indexes? • Cluster de...
Not all created equal
Not all created equal• SQL (MySQL, Postgres, SQL Server, Oracle)
Not all created equal• SQL (MySQL, Postgres, SQL Server, Oracle)• MongoDB, Riak, Cassandra, ...
Not all created equal• SQL (MySQL, Postgres, SQL Server, Oracle)• MongoDB, Riak, Cassandra, ...• Key/Value (Redis, Tokyo T...
SQL IS DEAD!
far
  fromSQL IS DEAD!
far
Upcoming SlideShare
Loading in …5
×

Strengths and Weaknesses of MongoDB

10,790 views

Published on

Published in: Technology
  • Be the first to comment

Strengths and Weaknesses of MongoDB

  1. 1. MongoDB:Strengths & Weaknesses Presented by Luke Ehresman http://copperegg.com
  2. 2. A.K.A.“Knowing when to usea hammer, and when to use a screwdriver.”
  3. 3. Where did we come from?
  4. 4. Where did we come from? The state of things a few years ago:
  5. 5. Where did we come from? The state of things a few years ago: • Relational ruled
  6. 6. Where did we come from? The state of things a few years ago: • Relational ruled • Normalize everything
  7. 7. Where did we come from? The state of things a few years ago: • Relational ruled • Normalize everything • Shove it into a relational database
  8. 8. Where did we come 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. 9. What is relational? Normalized data that relates to each other
  10. 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. 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. 12. Example use cases
  13. 13. Example use cases• Users with Accounts that have Transactions with Line Items
  14. 14. Example use cases• Users with Accounts that have Transactions with Line Items• Person with Votes and Comments
  15. 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. 16. Relational DBs give you
  17. 17. Relational DBs give you• Durability (guarantees that data is written)
  18. 18. Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)
  19. 19. Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)• Guarantees of atomicity
  20. 20. Relational DBs give you• Durability (guarantees that data is written)• Consistency (enforcing constraints)• Guarantees of atomicity• Data portability (with modern SQL dbs)
  21. 21. Relational DBs give you• 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)
  22. 22. Sometimes you just don’t care.
  23. 23. Sometimes you just don’t care.
  24. 24. Sometimes you just don’t care.• Sometimes speed is more important
  25. 25. Sometimes you just don’t care.• Sometimes speed is more important• Sometimes data is highly segmented
  26. 26. Sometimes you just don’t care.• Sometimes speed is more important• Sometimes data is highly segmented• Sometimes you can trust your app
  27. 27. 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
  28. 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• Sometimes you don’t need everything that normalization and relational DBs give you
  29. 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• Sometimes it’s not the end of the world if you lose some of your data
  30. 30. Example use cases
  31. 31. Example use cases• Blog with Comments (?? Really??)
  32. 32. Example use cases• Blog with Comments (?? Really??)• Logging tons of data
  33. 33. Example use cases• Blog with Comments (?? Really??)• Logging tons of data• Pre-processed data warehousing
  34. 34. Enter: NoSQL
  35. 35. Enter: NoSQL• These use cases are exactly why NoSQL databases have become popular
  36. 36. Enter: NoSQL• These use cases are exactly why NoSQL databases have become popular• Perhaps too popular (but we’ll get to that)
  37. 37. Enter: NoSQL• These use cases are exactly why NoSQL databases have become popular• Perhaps too popular (but we’ll get to that)• Store MASSIVE amounts of data
  38. 38. Enter: NoSQL• These use 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
  39. 39. Enter: NoSQL• These use 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
  40. 40. Know Thyself (and thy data)
  41. 41. Know Thyself (and thy data)
  42. 42. Know Thyself (and thy data)• Why are you considering MongoDB?
  43. 43. Know Thyself (and thy data)• Why are you considering MongoDB?• How will your data be queried?
  44. 44. Know Thyself (and thy data)• Why are you considering MongoDB?• How will your data be queried?• How big do you need to scale?
  45. 45. 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?
  46. 46. Know Thyself (and thy data)
  47. 47. Know Thyself (and thy data)• Read-heavy data
  48. 48. Know Thyself (and thy data)• Read-heavy data • Slave reads?
  49. 49. Know Thyself (and thy data)• Read-heavy data • Slave reads? • Size of data? Store it all in RAM?
  50. 50. Know Thyself (and thy data)• Read-heavy data • Slave reads? • Size of data? Store it all in RAM? • Covered indexes for subset queries?
  51. 51. 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?
  52. 52. Know Thyself (and thy data)
  53. 53. Know Thyself (and thy data)• Write-heavy data
  54. 54. Know Thyself (and thy data)• Write-heavy data • Insert vs. update/upsert?
  55. 55. Know Thyself (and thy data)• Write-heavy data • Insert vs. update/upsert? • Number of indexes?
  56. 56. Know Thyself (and thy data)• Write-heavy data • Insert vs. update/upsert? • Number of indexes? • Cluster design (many small shards)?
  57. 57. 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?
  58. 58. Not all created equal
  59. 59. Not all created equal• SQL (MySQL, Postgres, SQL Server, Oracle)
  60. 60. Not all created equal• SQL (MySQL, Postgres, SQL Server, Oracle)• MongoDB, Riak, Cassandra, ...
  61. 61. Not all created equal• SQL (MySQL, Postgres, SQL Server, Oracle)• MongoDB, Riak, Cassandra, ...• Key/Value (Redis, Tokyo Tyrant)
  62. 62. SQL IS DEAD!
  63. 63. far
  64. 64.   fromSQL IS DEAD!
  65. 65. far
  66. 66.   fromSQL IS DEAD! NoSQL and MongoDB are great additions to your toolbox. Use as needed.

×