1.
Mitch PirtleCloud 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 THECLOUD!

80.
Getting cloudy.US EAST EU (IR) AP TOKYO primary primary primarysecondary secondary secondarysecondary secondary secondarysecondary 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