What are some real use cases for going with a NoSQL Document Store db?

Question

I have been reading documentation and watching screencasts specific to Mongo DB over the past few days and I am at a loss for when a solution like this would be better than a typical pg or mysql environment.

Specifically, my question is under what circumstance (w/ use case would be nice) would you want to go the nosql route?

Thanks!

Answer 1

1. Many disparate writers. Especially when the writers can get segmented due to disconnections in the network, and will later need to resync data that has been written to on both sides of the bifurcation. This breaks ACID, and while you can solve the problem with explicit business logic, you're now in NoSQL territory. This is very common in military situations, but any system in which everyone is a prolific writer is going to have some write-contention lock on an ACID system.

2. Fluid schemas. Changing a schema in a traditional DB is an expensive operation that often requires some sort of server downtime or other complicated processes. With most NoSQL systems it's trivial. So if you've got data from a lot of disparate sources to merge and/or have situations where you may want to start tracking new information at a later date, NoSQL systems will be a lot easier to deal with. Merging two data sources so they can be charted with each other is a good example I can think of.

3. Low-bandwidth replication. Once you've broken ACID you can have readers and writers on leaf nodes of a network graph with partial data which don't need full replicas of the database. My own company's product, the Army's Command Post of the Future uses this.

4. Data interoperability. Most NoSQL databases allow you to introspect the data without knowing the schema ahead of time, allowing connections between disparate systems to happen easier.

5. Massive scaling. This is the one that is most-often debated, and most often abused by NoSQL proponents. If this is the only reason you're choosing NoSQL, start with MySQL instead and scale later.