This document discusses MongoDB and compares it to relational databases. It notes that MongoDB is a NoSQL database that is very fast, can store massive amounts of data, and usually scales better than relational databases. However, it also lacks some of the consistency, durability and other guarantees provided by relational databases. The document emphasizes knowing your data and use cases to determine when a document database like MongoDB may be better suited than a relational database.

1. MongoDB:
Strengths & Weaknesses
Presented by Luke Ehresman
http://copperegg.com

2. A.K.A.
“Knowing when to use
a hammer, and when to
use a screwdriver.”

3. Where did we come from?

4. Where did we come from?
The state of things a few years ago:

5. Where did we come from?
The state of things a few years ago:
• Relational ruled

6. Where did we come from?
The state of things a few years ago:
• Relational ruled
• Normalize everything

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. 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. 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. Example use cases

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. Relational DBs give you

17. Relational DBs give you
• Durability (guarantees that data is written)

18. Relational DBs give you
• Durability (guarantees that data is written)
• Consistency (enforcing constraints)

19. Relational DBs give you
• Durability (guarantees that data is written)
• Consistency (enforcing constraints)
• Guarantees of atomicity

20. Relational DBs give you
• Durability (guarantees that data is written)
• Consistency (enforcing constraints)
• Guarantees of atomicity
• Data portability (with modern SQL dbs)

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)

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. Example use cases

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. Enter: NoSQL

36. Enter: NoSQL
• These use cases are exactly why NoSQL
databases have become popular

37. Enter: NoSQL
• These use cases are exactly why NoSQL
databases have become popular
• Perhaps too popular (but we’ll get to that)

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

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

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

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 created equal

60. Not all created equal
• SQL (MySQL, Postgres, SQL Server, Oracle)

61. Not all created equal
• SQL (MySQL, Postgres, SQL Server, Oracle)
• MongoDB, Riak, Cassandra, ...

62. Not all created equal
• SQL (MySQL, Postgres, SQL Server, Oracle)
• MongoDB, Riak, Cassandra, ...
• Key/Value (Redis, Tokyo Tyrant)

63. SQL IS DEAD!

64. far

65. from
SQL IS DEAD!

66. far

67. from
SQL IS DEAD!
NoSQL and MongoDB are
great additions to your
toolbox. Use as needed.