It's a familiar story at this point - trying out NoSQL, then moving back to relational databases - and the response is generally consistent as well: NoSQL will only be useful if you understand your individual problem and choose the appropriate solution. According to Matthew Mombrea at IT World, though, that doesn't quite cover it. In this recent article, he shares his own "NoSQL and back again" thoughts, which hinge on the idea that there are simply too many NoSQL solutions out there, preventing newcomers from jumping right in.
Mombrea acknowledges that there are use cases where NoSQL is ideal. However, he argues that there are some major drawbacks that require additional effort:
It’s helpful to think of NoSQL as a flat file storage system where the filename is the key and the file contents are the value. You can store whatever you want in these files and you can read/write to them very quickly, but . . . the brains of a relational database are gone and you’re left to implement everything you’ve taken for granted with SQL in your code . . . for every application. The overhead is not justifiable for most applications.
Beyond that, he argues that the advantages of NoSQL don't even apply to most use cases:
The big draw to NoSQL is it’s ability to scale out with ease and to provide very high throughput. While it would be really nice to have the same scalability with an RDBMS, the real world fact is that 99% of applications will never operate at a scale where it matters. Look at Stack Exchange. They are one of the most trafficked sites on the planet and they run on MSSQL using commodity servers.
Given these drawbacks, how is one to decide what solution is appropriate? If nothing else, NoSQL demands quite a bit more research, which is hard to justify when it's not even clear that it's necessary or beneficial. This is potentially an oversimplification, though, of the use cases that call for NoSQL solutions. According to Moshe Kaplan's list of times when one ought to choose MongoDB over MySQL, for example, there are quite a few other scenarios. Just a few ideas:
- If you need high availability in an unreliable environment
- If your data is location-based
- If you don't have a DBA
Mombrea's conclusion, though, still hits an interesting point: NoSQL is young, and adoption may become more practical as it matures, given that such a central aspect is understanding which solution is appropriate for any given job. That may be a more manageable task when the market has thinned a bit, leaving behind a handful of well-tested solutions to well-defined problems.