MongoDB is our Best Friend
The rise of web services with millions of users like Facebook and Twitter has brought about the term “Internet scale.” At Cocoafish we’ve built a server platform for mobile apps that can automatically handle Internet scale traffic for app developers so they don’t have to put a second of thought or work into it.
When designing our fundamental architecture we needed to find a database that could deal with millions of users across thousands of apps that will use Cocoafish. I knew that we would need replication, sharding, read slaves, etc. Using the default SQL solution (MySQL) was out of the question since the administrative model for these kind of scaling features is difficult. Plus I found anecdotal evidence that performance hits a wall once you get to some millions of rows in a table. On top of that we wanted to handle flexible app data without predefining schemas or running database migrations from our Ruby on Rails stack.
I first looked at Apache Cassandra which introduced me to the concept of a high-performance, schema-less document store. It looked promising, but the state of RoR support for Cassandra in late 2010 wasn’t encouraging. Then some friends at large company told me that they were doing the same type of investigation into SQL and NoSQL solutions for a major project. They had found that Cassandra just fell over with too much load. However, MongoDB looked very promising. I think in the end they chose Oracle running on expensive hardware, presumably because they could get a large, established company to be on the hook when things went wrong. But for a new startup, MongoDB looked just right.
After getting over how ridiculous the name sounded, I checked out mongodb.org, browsed the docs, and tried the software. Wei and I also attended MongoSV 2010. We were impressed with how simple and straightforward it all was. Any software that’s just contained in a single binary instead of a multitude of libraries and config files gets lots of extra points in my book. 10gen makes money from consulting, but they sort of defeat their own purpose by making the software and docs so simple to use.
However, we have purchased two sessions of their $300/hr consulting services. At first it looks really pricey, but both sessions were totally worth it. Both times we talked to Kyle Banker who wrote and maintains their Ruby driver. He really helped us with in-depth design issues and kept us on the path to MongoDB awesomeness. I also gave a lightning talk at MongoSF 2011 which was a great chance to share our experience with using MongoDB for a multi-tenant service through Ruby on Rails.
At the risk of this sounding like a paid blog entry, our experience so far has been wonderful. We’re constantly expanding our data models, and MongoDB makes it totally easy to do that. While we haven’t yet pushed all the boundaries of their performance and features, we’re confident that MongoDB will handle what we throw at it. With the recent addition of features like journaling and spherical geospatial search, this is a great time to try it out for services large and small.