We don't have a NoSQL in General forum (maybe we should) so I picked this forum to ask my question:
I remember several years ago when digg.com's CTO made the decision to move pieces of their system to a NoSQL solution and it was a complete failure. I don't believe this is because the NoSQL solution they chose was bad. But clearly something went wrong with that decision.
How do you decide that a NoSQL solution is the right call? What are some of the determining factors in saying "for this project or this module, NoSQL is a better fit than standard relational databases" ?
I have no experience of NoSQL, apart from a bit of tinkering with MongoDB and some of the exercises from the book Seven Databases In Seven Weeks (the web page includes interview with the authors), but here's a couple of thoughts to kick things off.
From watching the video and reading the Seven DBs book, I get the impression it depends on a variety of factors, and there isn't really a single "NoSQL" model to compare with the relational model.
So one factor will be the extent to which your data fits one of the various NoSQL models. For example, MongoDB and CouchDB are document-oriented, Neo4j is a graph database, while HBase is a column-oriented DB. I guess it's a case of looking at your data and deciding if it naturally fits one of these models e.g. the Guardian's web publishing application suited the document-oriented approach which was presumably one of the reasons they chose MongoDB.
Also, it will depend on your application's requirements in terms of its ACID properties (Atomicity, Consistency, Isolation and Durability). Different NoSQL DBs seem to have different approaches to each of these, with different ways of handling transactions, replication, failure/restore, redundancy etc. So I guess you would have to look at how you feel about losing a few transactions if a server goes down, or having to wait for data to sync itself after changes, and so on.
And you'd probably have to think carefully about how far you are prepared to give up the benefits of the relational approach - availability of skills and tools, robustness and reliability, highly structured data, how you might want to modify/extend/re-use your data model for different applications, etc.
Eventually, when all the hype subsides, I suspect that we will probably end up seeing something a bit like the common relational/star schema symbiosis, where transactional (relational) operational data stores live alongside data warehouses that are optimised for reporting i.e. you might have one part of your overall system using one model, and another part using a different model, perhaps with data being moved between them periodically as required.
Anyway, that grinding noise you can hear right now is me scraping the bottom of my own barrel of ignorance! But I recommend the Seven Databases book as a quick way to get a handle on all these issues.
Have you watched the video of Craigslist successful move to MongoDB? The video is linked in this blog post and they make some interesting points and go over some of the reasoning behind the move. It has been awhile since I watched but you might find some answers there.