Learnings from MongoSV 2011

I attended mongoSV 2011 on Friday 12/09/2011. I’ve been to mongoDB Meetups before but this was my first large Mongo Conference. My overall impression of the conference was very positive. It was well run, they had relevant sessions, and the speakers were well prepared and knowledgable in their respective areas. I’ve attended many technical conferences and I have to say that the folks at 10Gen did a fantastic job with mongoSV 2011. I learned a lot and it was good to be around other folks deploying mongoDB in production environments, especially to AWS. They even had a session dedicated to this which is especially important to me because at mezz we are doing just that.

Here are just a few notes that I typed up during the conference that I thought were useful.

Tools:

At the Java Birds of a Feather group discussion 10Gen mongoDB developer, Antoine Girbal mentioned a GUI tool he built for interfacing with mongoDB called JMongobrowser

I downloaded and installed jmongobrowser and it seems like a good tool to have around. I’m pretty comfortable with the mongo command line shell so I doubt this will replace that for me, but it’s nice to have a GUI tool as well so I suspect that it will compliment my CLI needs as opposed to replace the CLI for me.

I still feel that the shortage good tools is an area that mongoDB and probably most NoSQL DBs suffer from. Hopefully this will change as the NoSQL momentum continues to build.

MongoDB on AWS:

Jared Rosoff did an excellent talk on running mongoDB on AWS. Here are some recommendations he made that I thought were particularly useful:

• Always choose a 64 bit instance. You’ll be stuck with storing max 2G on an individual mongoDB box with a 32 bit instance and will be very unhappy!
• Turn off atime and diratime in your Linux box. There’s some debate in the Linux community about the true performance gains of doing this, but for a DB server I think this makes sense considering all the read operations that occur and it can’t hurt to turn it off. Here’s an article that explains how to disable atime and diratime.
• Bump up max file descriptors to 64k. This one is a little more obvious but is something that can easily be overlooked.
• NEVER use the ext3 filesystem. Again obvious but worth pointing out. Use ext4 instead.
• Run EBS volumes in RAID 10. I thought this was particularly interesting as my initial thinking was that RAID 0 would be sufficient. In fact I attended a Foursquare presentation at mongoSV by a Foursquare site reliability engineer who said that Foursquare is deploying with RAID 0 and are now thinking about changing to RAID 10. The advantage of RAID 10 is that if one of the drives fails you don’t lose an entire server.

Replica-Sets

• There is the obvious tradeoff of read performance with the consistency model you chose. With strong consistency you won’t be able to take advantage of the read scaling from a Replica Set because all connections will be routed to the primary. In most cases you don’t need strong consistency and eventual consistency is good enough and well worth the tradeoff for the win you get  with scaling up reads.
• Use the “Slave Delay” feature and set it to like an hour so that if you accidentally run a db.MySuperImportantCollection.remove() it won’t be immediately replicated to all the DBs running in your RS thus causing a face palm of epic proportions! This way even if it’s late at night and you do make a stupid mistake you’ll still have an hour to recover (just take that slave offline right after you use your four-letter-word of choice).

There was definitely a lot more, but that’s all for now. I may in the future post some of my learnings from having mongoDB deployed in production on AWS.