MongoDB and NoSQL - when to use or not use it?

[chris webster]

Hi Kyle,

I'm an Oracle developer but I've looked at some of the "NoSQL" discussions, including Oracle's entertaining volte-face on whether NoSQL is a good idea or not. It all sounds interesting, but I'm still struggling to get a handle on where I might want to use something like MongoDB rather than the more structured relational/star schema models that seem to fit the large-scale enterprise applications I usually work on.

I've also learned the hard way that a lot of people in Java-Land find databases "difficult", so rather than learn how to use them properly, they often look for ways to avoid doing so, either by delegating everything blindly to an ORM and hoping for the best (works for a while but doesn't always scale well to high volumes/complex data-sets), or by coming up with ways to avoid having a database at all (nasty flat-file solutions and so on). Indeed, a Java developer of my acquaintance has already mentioned possibly using a NoSQL database simply as a way to avoid having to learn SQL!

So can you reassure this grumpy old database developer that MongoDB and NoSQL is not just another way for people to avoid thinking hard about the structure/purpose of their data, even though data is often the key asset in many enterprise applications? And what are the application areas where you would - or would not - choose a NoSQL database? Where would you pick a relational DB instead?

Best of luck with the book.

Chris

[Andrew Moko]

Good post Chris.

Not long ago i ran into a mongoDB article on the serverside.com, installed the "database" and skimmed through the quick-start tutorials. Sadly i had to drop the "concept" since i couldnt figure how JSON can be used in large enterprise complex data structures. ORMs (hibernate, toplink etc) have their own downsides BUT we can't overlook the simple, easy code integration, organized, benefits they come along with.

To add on to Chris Question List. What are the benefits of changing technologies to mongoDB?? Is there a way to port code/ apps from convention sql/ ORMapping to mongoDB?? Does it have an easy to integrate "ORM Concept"???

Andrew

[Orjan Petersson]

Very good questions. I would like to add the following: How do I integrate a MongoDB application into an existing environment with loads of data already stored in (one or multiple) relational databases? Can I for example easily get to the existing customer data that the new MongoDB application also needs?
--
Örjan

[Aaron Jones]

Further to Orjan's post: Hibernate OGM seems to be in its infancy where it comes to support for NoSQL outside of Infinispan. What other ORM's are out there that provide broader NoSQL DB support?

[Kyle Banker]

Hi Chris,

Thanks for the question.

I cannot completely assure you that people aren't learning MongoDB at least in part because they don't want to learn or use SQL. MongoDB has a fairly intuitive query language, and it's a small reason why people gravitate toward it.

As with any database, success with MongoDB does depend on being able to think critically about how you're going to use your data. MongoDB supports rich, dynamic data structures, and you can change them on the fly without having to issue ALTER TABLE statements, but this does not mean that you can get away with sloppy data modeling.

We've seen the same problem of people wanting to use ORMs to hide the realities of the database, but this doesn't work for non-trivial applications, just as it doesn't for SQL databases.

As for use cases, I'd say that MongoDB is ideal for these situations:

1. When the application's data is inherently unstructured. Think products in an e-commerce site. Each product can have an arbitrary set of attributes. MongoDB documents make this pretty easy to model.

2. Rich data models that don't require joins. You'll often see relational schemas that break a single "object" into a dozen different tables. If the object in question has to be constructed using a SQL join every time it's displayed, and if there's no ancillary benefit to having the data modeled in this way, then there's a lot of unnecessary added complexity there. Consider a page in a content management system. Why does each individual element need to be in separate record or table? A MongoDB document can typically store all these elements in a structured way while still facilitating sophisticated queries over them. This has the added benefit of providing good locality.

3. Analytics. I won't go into detail now, but there are certain types of analytics applications (think website activity tracking) that MongoDB has been optimized for.

4. High availability. MongoDB's replication system provides automated failover.

5. Sharding. If you have a lot of data but want to run on commodity hardware, MongoDB 's sharding can be quite compelling.

Hope that helps!

Kyle

[chris webster]

Thanks for the detailed reply, Kyle, that gives me food for thought on how to start out with MongoDB.