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.
mezz is now available in the App Store!
After several months of blood sweat and tears, our app is now available in the App Store! The app is FREE so give it a whirl. Let us know what you think and help us out by spreading the word and posting great content in your local area.
Building a RESTful Service that returns JSONP using the Spring Framework
This is not a duplicate of my previous blog entry of Building a RESTful Service that returns JSON using the Spring Framework. In this blog post I’m going to show how you can return JSONP so that you can call your REST APIs directly from your Javascript functions. If you are wondering why you can’t just simply use your existing REST APIs with Javascript then you will want to read up on JSONP. The basic idea is that the caller will pass a “callback” parameter to your API which is essentially a JSON function name. You then have to wrap your return within open and close parens and the callback function name so that it makes the Javascript runtime environment get tricked into thinking that it is running a local JS function.
So Here’s some code that will do this. Building on the SimpleRestController from the previous blog posts:
@RequestMapping(value = "/simple/pojo_hashmap/jsonp", method = RequestMethod.GET)
public ResponseEntity handleSimpleJsonp(@RequestParam("callback") String inCallback) {
StringBuffer theStringBuffer = new StringBuffer();
HashMap theHashMap = new HashMap();
theHashMap.put("Great Coffee", "Barefoot");
theHashMap.put("Bad Coffee", "Starbucks");
// add the callback function name and open paren
theStringBuffer.append(inCallback);
theStringBuffer.append("(");
// serialize the POJO to JSON
String theResponseString = serializeToJson(theHashMap);
// add the JSON string and close parens
theStringBuffer.append(theResponseString);
theStringBuffer.append(")");
return new ResponseEntity(theStringBuffer.toString(), new HttpHeaders(), HttpStatus.OK);
}
private String serializeToJson(Object theObject) {
String theJsonString = null;
try {
ObjectMapper theObjectMapper = new ObjectMapper();
ByteArrayOutputStream theJsonOutputStream = new ByteArrayOutputStream();
theObjectMapper.writeValue(theJsonOutputStream, theObject);
theJsonString = theJsonOutputStream.toString("UTF-8");
} catch (Exception theException) {
theException.printStackTrace();
}
return theJsonString;
}
Here we are including a callback input parameter to our controller method handleSimpleJsonP(). This is the Javascript function name that we will have to wrap the return with. In the previous blog post we didn’t have to worry about any callbacks so we could just return the POJO right away however now we need the intermediary step of getting the serialized version of the POJO. We accomplish this with the new serializeToJson() method that we added. We just pass it in a POJO and get back a UTF-8 JSON String. Now we can just wrap this string with the callback and the open and close parens and return it. Thats all there is to it and now you can have your Javascript functions making direct API calls into your RESTful Service.
Now when you call your service with a call like:
http://localhost:8080/simple/pojo_hashmap/jsonp?callback=getCoffeeAdvice
You will get a result like this:
getCoffeeAdvice({"Great Coffee":"Barefoot","Bad Coffee":"Starbucks"})