MongoDB Rocks My World

I am delighted to announce that I'll be speaking at several MongoDB-related events over the next couple of months. So if you're in or near Dallas, Seattle, or Silicon Valley, I'd love it if you could make it to one of my talks. 10gen (the makers of MongoDB) do a great job of putting on regional conferences that are extremely reasonably priced (typically $30 student and $50 early bird), and there's usually a nice after-party for each one, so there's no excuse not to go.

So anyway, here are the conferences I'll be speaking at:

• November 17: MongoDallas 
• December 1: MongoSeattle 
• December 9: MongoSV (Santa Clara, CA) 

I also wanted to say a few words on why I enjoy using MongoDB and why it is such a good fit for a lot of the problems I face...

MongoDB is Flexible

You probably expected me to say something about MongoDB being web-scale, and while that's true, it's not the biggest reason I use it. What I like the most is that you can organize your data the way you want to without a lot of restrictions forced on you by the DBMS you're using. For those who don't know, MongoDB is what's called a 'document-oriented' database. Rather than storing "rows" in "tables" like you do in a relational database, you store "documents" in "collections."

What is a document? Well, in MongoDB is basically a JSON object. (I'm actually lying. It's technically called BSON because it's a binary format and you get a couple of extra data types for 'free' in MongoDB including datetimes, ObjectIds, and regular expressions, but it's basically JSON.) So if your RDBMS-based application is doing some queries, and every query has a one-to-many type join (or worse yet you're doing several queries to grab all the data you need to render a page), in MongoDB you would just store all the data you need in a single document, which can be retrieved by a single query. Fast and flexible.

Another way MongoDB is flexible is that it allows you to use ad-hoc queries and indexes. In some NoSQL solutions, you need to define views or map-reduce jobs to get at your data. Rather than forcing you to define all that up-front (or pay a penalty at runtime), MongoDB includes a BSON-based query language and indexes. What this means is that you don't have to clutter your data model with every possible path someone might want to use someday to access your data. For me, MongoDB strikes a sweet spot between explicit query models like Hadoop or CouchDB and a full query compiler like SQL databases.

MongoDB is Fast

Ok, so there is a little bit about "web-scale." MongoDB supports both replication and sharding, which means that it scales really well over several servers. But that's not really what I'm talking about. What I'm talking about it single-server speed. MongoDB uses a nifty little trick (mmap) to map its entire database into memory, where it can treat reads and writes to the database as reads and writes to RAM. For many common operations, this is really fast. Like tens of thousands of writes per second fast. This means that for a site like SourceForge, which is getting millions of hits a day, we're comfortable serving the majority of requests off a single MongoDB server. And by setting up replication (which we have now) and journalling (which we plan on adding Real Soon Now) with MongoDB, you can be quite safe as well. Replication also means that backups are a snap and don't require our server to go through any downtime.

So great, it's fast in production. But it's also fast (and easy to set up) for development. The MongoDB server is just a single binary application that you can run yourself from the command line, and it keeps all its data in a single directory. This is really nice for a development setup like mine, where I'm running everything needed for an Allura (the SF.net platform) on a VMWare virtual machine. It's just plain simple to set up a single node, and setting up larger systems with replication and sharding isn't *that* much harder.

MongoDB is Simple

While there are many parts of MongoDB that I'm sure took a good bit of complexity in the server to get right (shard migration, journalling, and the new aggregation framework come to mind), the basic ideas are easy to get your mind around. Some of the other NoSQL solutions do some really mind-stretchingly awesome stuff (Cassandra's write scaling and CouchDB's multi-master replication come to mind). MongoDB has some nice and interesting features, as well, but its real strength is that it does what it does really well. It's fast (performance wise and development wise), flexible, stable, and scalable. And because a) the 10gen engineers are awesome and b) it's open source, when there is a feature or technique enough people want/need, MongoDB grows that feature. But historically, it has grown that feature in a way that fits in really well with the existing feature set and doesn't require an enormous cognitive leap to grasp.

10gen

MongoDB's creators are an awesome group of folks. They're throwing conferences every 6 weeks or more frequently somewhere, they're incredibly responsive to support questions, they're actually really smart, and they've developed an incredible community around MongoDB. And just for fun, they've decided to single-handedly support the coffee mug industry. Seriously, though, the support they provide for MongoDB is nothing short of stellar, from n00b to Mongo master, and that's probably the biggest reason MongoDB has seen the kind of uptake it has.

So if you haven't ever had the chance to use MongoDB, I'd urge you to grab a copy and start playing around with it. And if you're curious, try to make it out to one of the MongoDB conferences or user groups. All the folks I've met at these are quite friendly and love to help newer users along. So yeah, I guess I'm a MongoDB fanboy. Think I've gone off the deep end? Any other features of MongoDB you love? Please let me know in the comments. I'd love to hear from you!


Source: http://blog.pythonisito.com/2011/10/mongodb-rocks-my-world.html