This is my deck from Cloud Conference Torino 2013 (http://www.cloudconf.it). I was the post-lunch speaker, so this one is more silly and there was a lot of off-deck riffing, so this is here only for posterity. I initially planned to speak on cloud-specific stuff, this turned into an intro to MongoDB though.

1. Mitch Pirtle
Cloud Conference, Torino - May 2013

2. About me
• Moved from NYC to Turin in 2011
• CTO at Sounday Music
• Joomla founder
• Contributor to Lithium and other
frameworks
• MongoDB Master

3. About this talk
• Quickly cover cloud strategies
• Overview of the evolution of databases
• Introduction to MongoDB
• Example cloud deployments

7. Just checking.

8. And now, the cloud.

10. Somewhere up there.

11. What is the cloud?

12. What is the cloud?
• Where all the cool kids live?

13. What is the cloud?
• Where all the cool kids live?
• Where all your budgets go to die?

14. What is the cloud?
• Where all the cool kids live?
• Where all your budgets go to die?
• Where all the big projects have to go?

15. What is the cloud?
• Where all the cool kids live?
• Where all your budgets go to die?
• Where all the big projects have to go?
• All your base belong to us?

16. What is the cloud?
• Where all the cool kids live?
• Where all your budgets go to die?
• Where all the big projects have to go?
• All your base belong to us?
• The biggest marketing sham to hit IT?

17. The cloud is...

18. The cloud is...
• Quick deployment

19. The cloud is...
• Quick deployment
• Huge scale

20. The cloud is...
• Quick deployment
• Huge scale
• Potential economic benefit

21. The cloud is...
• Quick deployment
• Huge scale
• Potential economic benefit
• Can lower operational effort

22. Ok let’s do this.

24. Why does this have to
be so complicated?

25. Why does this have to
be so complicated?
• Cloud services are still relatively new, so
management tools can be lacking

26. Why does this have to
be so complicated?
• Cloud services are still relatively new, so
management tools can be lacking
• Taking technology that was not meant for
cloud deployment, and, well, deploying it in
the cloud

28. Cloud apps are easy,
what about data?

29. Cloud apps are easy,
what about data?
• MySQL is hard enough as it is.

30. Cloud apps are easy,
what about data?
• MySQL is hard enough as it is.
• Oracle is even harder.

31. Cloud apps are easy,
what about data?
• MySQL is hard enough as it is.
• Oracle is even harder.
• Even though PostgreSQL seems to be the
best of the bunch, nobody but me is using it

32. Cloud apps are easy,
what about data?
• MySQL is hard enough as it is.
• Oracle is even harder.
• Even though PostgreSQL seems to be the
best of the bunch, nobody but me is using it
• We need something better...

35. Why MongoDB

36. Why MongoDB
• Was born out of the need for cloud
computing

37. Why MongoDB
• Was born out of the need for cloud
computing
• Simplifies scale

38. Why MongoDB
• Was born out of the need for cloud
computing
• Simplifies scale
• Simplifies development

39. Why MongoDB
• Was born out of the need for cloud
computing
• Simplifies scale
• Simplifies development
• Presents new ways to access data from
apps

40. NOTE: Drop to console and demo
the shell, simple documents and
platform features

41. In the beginning...

43. Whups, wrong
beginning.

44. Relationship issues

45. Relationship issues
• Easy to scale reads, difficult to scale writes

46. Relationship issues
• Easy to scale reads, difficult to scale writes
• Requires custom hardware

47. Relationship issues
• Easy to scale reads, difficult to scale writes
• Requires custom hardware
• Expensive to host at scale

48. Relationship issues
• Easy to scale reads, difficult to scale writes
• Requires custom hardware
• Expensive to host at scale
• Usually requires significant customization
to apps

49. Oh we can shard,
it’s all good.

51. That went well.

52. That went well.
• Sharding sounds great on paper

53. That went well.
• Sharding sounds great on paper
• In practice it is EXTREMELY HARD

54. That went well.
• Sharding sounds great on paper
• In practice it is EXTREMELY HARD
• Adds significant complexity to your app
logic, operational needs

55. How MongoDB bosses.

56. MongoDB: Replication

57. MongoDB: Replication
• Replica Sets

58. MongoDB: Replication
• Replica Sets
• Distributed master

59. MongoDB: Replication
• Replica Sets
• Distributed master
• Voting/elections

60. MongoDB: Replication
• Replica Sets
• Distributed master
• Voting/elections
• Member priority

61. MongoDB: Clustering
• See Replica Sets!

62. MongoDB: Sharding

63. MongoDB: Sharding
• Has supported sharding since early
production release

64. MongoDB: Sharding
• Has supported sharding since early
production release
• Only significant change to app logic is some
queries needing map reduce

65. MongoDB: Sharding
• Has supported sharding since early
production release
• Only significant change to app logic is some
queries needing map reduce
• Only significant change to operations is
more hardware

66. MongoDB: Sharding 2

67. MongoDB: Sharding 2
• Can shard on internal ID, or you can define
with your own shard keys

68. MongoDB: Sharding 2
• Can shard on internal ID, or you can define
with your own shard keys
• You can tag to control what data goes into
what shard

69. MongoDB: Sharding 2
• Can shard on internal ID, or you can define
with your own shard keys
• You can tag to control what data goes into
what shard
• Many simple queries can still work across
sharded data

70. MongoDB: Sharding 3

71. MongoDB: Sharding 3
• Chunk size is user configurable, defaults to
64MB

72. MongoDB: Sharding 3
• Chunk size is user configurable, defaults to
64MB
• Sharding is at the collection layer

73. Some examples.

74. Getting started.
primary

75. Getting started.
• One node
primary

76. Getting started.
• One node
primary
• Single point of failure

77. Getting started.
• One node
primary
• Single point of failure
• Easy to manage

78. Getting started.
• One node
primary
• Single point of failure
• Easy to manage
• Cheap!

79. Getting better.
primary
secondary
arbiter

80. Getting better.
• One arbiter
primary
secondary
arbiter

81. Getting better.
• One arbiter
primary
• Two nodes
secondary
arbiter

82. Getting better.
• One arbiter
primary
• Two nodes
secondary
• Failover
arbiter

83. Getting better.
• One arbiter
primary
• Two nodes
secondary
• Failover
arbiter
• SPoF at datacenter level

84. Getting reliable.
primary primary
secondary secondary
arbiter arbiter

85. Getting reliable.
primary primary
• Two datacenters
secondary secondary
arbiter arbiter

86. Getting reliable.
primary primary
• Two datacenters
secondary secondary
• Fully redundant
arbiter arbiter

87. Here it comes.

88. (Wait for it.)

90. TO THE
CLOUD!

91. Getting cloudy.
US EAST EU (IR) AP TOKYO
primary primary primary
secondary secondary secondary
secondary secondary secondary
secondary secondary secondary
arbiter arbiter arbiter

92. This is your
app in the This is you.
cloud.
Ok so what’s the
difference?

93. Cloud benefits

94. Cloud benefits
• Growth is a lot easier - adding instances is
a lot simpler/faster than adding servers

95. Cloud benefits
• Growth is a lot easier - adding instances is
a lot simpler/faster than adding servers
• Geographic zones can be combined with
tags for logical data segregation and storage

96. Cloud benefits
• Growth is a lot easier - adding instances is
a lot simpler/faster than adding servers
• Geographic zones can be combined with
tags for logical data segregation and storage
• Automation of adding/removing instances,
no humans required

97. These guys will do it
for you.
• MongoHQ
• MongoLab
• Mongo Machine

98. Questions?

99. Thanks!
• @mitchitized
• about.me/mitchitized
• github.com/spacemonkey
• slideshare.net/spacemonkeylabs

100. Resources
• MongoDB on EC2 and EBS
• MongoDB Replication
• Data Center Awareness
• Advanced Replication
• Replication and Replica Sets

101. Credits
• Sleeping monkey • Clouds
• Green hills • Cloudy beach girl
• Octopus • Wonderland
• Polar facepalm • Curot Grass Sky
• Gladiator
• Mushroom