Strengths and Weaknesses of MongoDB

6,982 views
6,681 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,982
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
120
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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.

    ×