Of course, we can easily find some really accurate use of noSQL databases. But it's really important to understand why are you picking up a non-relational database. it's a huge decision, even to select which noSQL database you'll work with.
First thing to be clear is that we can implement everything on a noSQL or relational database. The overhead on processing the data, to develop and maintain the environment, and the final performance are the key factors. So, eventually, your final architecture may combine both relational and noSQL databases.
Another idea to keep in mind is that is pretty easy to setup either noSQL and relational databases for small tests/PoCs. The relational databases can be simple, just make it simple for your tests - you may not need to set up all constraints, normalize your tables, etc. You wouldn't be doing anything like that with a noSQL database.
In my opinion, the approach has to be reasonable. We also have to try to solve the problem in a simplistic way, and not create a beautiful and complex architecture to solve a small issue.
A good way to do that is iterate with your own solution: you get a problem, study the solution, put it in the context and question yourself if it fits on the big picture. Compare it against the whole scenario. If it makes sense, go ahead and attack the next problem. Sometimes you might step back and combine solutions into one.
For example, Riak is a known noSQL database that supports clustering out of the box. So, it's provides high availability, even in failure conditions. But you have to ask yourself if it's really necessary. If you pick the big players on relational database, they provide more than 99,999% of availability.
In other scenarios, it's easy to justify your decisions. If we're talking about document based databases, like blogs, you may consider a document based noSQL database, like MongoDB. Similar scenario for InfoGraph, if we are talking about graphic databases. And we can't forget about Hadoop for really big data if you need performance.
There are lots of matrix available on the web, pointing the databases and its usage. Also, lots of reports comparing the products. These materials are interesting, I recommend some research before defining your strategy.
Basically, there are lots of noSQL solutions available. We just have to understand well the problem we are dealing with, and pick a relational database or a specific noSQL database that solves this problem. There may not be a 100% correct solution in all cases. So, write on your notes your assumptions and the reasons you picked up some specific solution... and good luck!
