• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Growing MongoDB on AWS
 

Growing MongoDB on AWS

on

  • 1,192 views

 

Statistics

Views

Total Views
1,192
Views on SlideShare
1,188
Embed Views
4

Actions

Likes
1
Downloads
26
Comments
0

2 Embeds 4

https://twitter.com 3
https://si0.twimg.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Growing MongoDB on AWS Growing MongoDB on AWS Presentation Transcript

    • Growing MongoDB on AWS Colin Howe @colinhowe
    • Who am I?I run engineering at Conversocial.We help companies do social customer service.http://www.conversocial.comLove coding, ultimate frisbee and pudding
    • Growing MongoDB on AWSTips for ensuring you can grow MongoDB onAWS as your business needs grow. Mandatory meaningless graph
    • Single Server - EphemeralSingle server with instance storage.Not really advised.Must haves:● Journalling http://www.mongodb.org/display/DOCS/Journaling● Regular backups http://www.mongodb.org/display/DOCS/Backups
    • Single Server - EphemeralPros:Easy to configure.Cheap.Cons:No redundancy.Data since last backup is lost on server death.
    • Single Server - EBSSame as the last but move storage over toEBS.EBS is slow.RAID 10 it.http://bit.ly/mongodb-raid10
    • Single Server - EBSPros:Easy to configure.Data should still be available on server death.Cheapish.Cons:No redundancy.
    • Single Server - No redundancy
    • Enter ReplicationPrimary server replicates to secondary serversUse multiple Availability Zones (AZs).
    • Two servers, one arbiterCheapest replica set configuration.Arbiter ensures an odd number of votes.The arbiter can be a micro instance.
    • Two servers, one arbiterPros:Cheapish.Some failover.Cons:Only one failover. What if you fail again?
    • Three serversStandard replica set configuration.
    • Three serversPros:Lots of redundancy.High read capacity when one server fails.Cons:Starts to get pricey.
    • Where next?Horizontal and vertical scaling.
    • Vertical scalingUse EBS boot.Turn the server off. Resize. Turn it back on.Seconds of downtime when using a replica set.Without replica sets you will have downtime
    • Vertical scaling - SSDsIf you can afford them SSDs are the King.● Conversocial got 43% faster.● 90% iowait went to ~3% user, 0% iowait.All numbers compared to instance with largestmemory (68.4gb)
    • Horizontal read scalingAdd more secondaries and use slave queries.Really easy.Make sure you have a hidden backup server.Backups kill read performance.Use write concerns for consistent reads.
    • Horizontal write scaling - ShardingFairly easy with MongoDB.Backups get harder.More to manage and configure. Automate it.
    • When to Shard?If you know your data structure then soonerIf you dont... laterChanging shard keys is not trivial
    • Enterprise AvailabilityIf youre hunting for the final decimal places ofavailability...Youre probably going to break your applicationmore frequently than Amazon has a wholeregion outage.But...
    • Enterprise AvailabilityMultiple regions are the next step.Harder as you go outside the firewall.VPNs or SSH tunnels are your friend here.
    • Tools to Help YouMMS - Mongos Monitoring System (FREE)Chef/Puppet - automate as much as you can#mongodb and MongoDB user group10gen
    • Thanks for Listening! Any questions? Feeling shy?You can always reach me on Twitter @colinhowe Slides will be put online