The Good and Bad of MongoDB
Since MongoDB and many other NoSQL options don’t allow for the native concept of a ‘JOIN’ they work best for data that isn’t highly relational. A good use case for NoSQL would be when it seems natural to store and load object graphs based on a particular ID or through more basic queries (though NoSQL queries will not be as fast as what you can get with a relational database). For example imagine you wanted to persist a document describing a “Web Page.” A “Web Page” might have some basic string based attributes like name, title, or last modified etc. but when you start to describe its structure it would contain things like an array of “widgets” in a particular container each with their own settings. The widgets in that container might contain other widgets etc. This could quickly turn into a table nightmare if you were trying to use a relational database but with NoSQL you could simply persist the “Web Page” in its entirety (the object graph you had in memory) and when you read it back out that object graph is restored.
On the flip side if your business domain were to say that a widget could be shared across multiple pages NoSQL becomes less attractive because cross document relationships exist. Within the same “collection” (type of ’thing’) Mongo offers the ability to map, reduce and otherwise aggregate documents so that might be an option for you. However when cross “collection” relationships exist the only option is to load each document separately with a separate round trip to the database. This is obviously quite bad for performance because you are essentially doing your JOINs manually on the client.
Using NoSQL vs. a traditional RDBMS isn’t a matter of what is trending or ‘cool’ right now. You need to take a hard look at your data and decide whether the relationships in your data look more like an object graph or more like a normalized structure of various related tables. In my experience NoSQL tends to work very well about 70% of the time but can be painful for relational data that is structured as such to avoid duplication. In general I think MongoDB has saved me a lot of time in the end, not to mention schema design headaches. Look at your data first and foremost, however!
My current use of MongoDB
I’m currently using MongoDB on a project where at its core we have the concept of a CheckIssue which could be of many different polymorphic derivations. We also have a property bag that allows the particular Issue to store things that are relevant at the time but might not be later on. Mongo works really well for this because there is no ‘schema’ that must be abided by. We are also using the awesome aggregation framework baked into Mongo to summarize information about CheckIssues that occur over time. The aggregation framework is very powerful and could be compared to a ‘live’ map reduce job that also has pretty good performance.
MongoDB vs RavenDB
I’ve also had the experience of using RavenDB pretty extensively. RavenDB has some pretty cool features like the ability to ‘JOIN’ on the server across multiple documents but suffered from bugs and a sub-par CLI/querying API (unless you were using C#). MongoDB has been very stable and surprisingly performant even when talking about millions of documents in a single database instance (and it does scale out/shard quite well but we haven’t had the need). My team is pretty happy with it especially the power/simplicity of the query language and performance. We will be using it for some time to come and I think that MongoDB is probably one of the best NoSQL products on the market right now for general purpose, multi-platform NoSQL.