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

4.
Just checking.

5.
And now, the cloud.

6.
Somewhere up there.

7.
What is the cloud?

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

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

10.
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?

11.
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?

12.
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?

13.
The cloud is...

14.
The cloud is...
• Quick deployment

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

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

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

18.
Ok let’s do this.

19.
Why does this have to
be so complicated?

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

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

22.
Cloud apps are easy,
what about data?

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

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

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

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

27.
Why MongoDB

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

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

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

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

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

33.
In the beginning...

34.
Whups, wrong
beginning.

35.
Relationship issues

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

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

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

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

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

41.
That went well.

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

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

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

45.
How MongoDB bosses.

46.
MongoDB: Replication

47.
MongoDB: Replication
• Replica Sets

48.
MongoDB: Replication
• Replica Sets
• Distributed master

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

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

51.
MongoDB: Clustering
• See Replica Sets!

52.
MongoDB: Sharding

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

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

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

56.
MongoDB: Sharding 2

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

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

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

60.
MongoDB: Sharding 3

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

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

63.
Some examples.

64.
Getting started.
primary

65.
Getting started.
• One node
primary

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

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

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

69.
Getting better.
primary
secondary
arbiter

70.
Getting better.
• One arbiter
primary
secondary
arbiter

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

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

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

74.
Getting reliable.
primary primary
secondary secondary
arbiter arbiter

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

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

77.
Here it comes.

78.
(Wait for it.)

79.
TO THE
CLOUD!

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

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

82.
Cloud benefits

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

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

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

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

87.
Questions?

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

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

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