The Digg example could have used MySQL without modification had they added the correct indexes. And if they didn't want to do that, they could have heavily cached queries in Memcache (or something) and performed the join on the fly. And before get flamed for speculating, I know this because I was responsible for the same feature on another Top 100 site of similar scale.
Getting performance out of MySQL might not be as simple as it is in a key/value store, but scalability isn't a new issue, and MySQL is decent at doing it efficiently (although in a way only DBAs would know/understand). It could have saved Digg 3TB of disks to maintain.
Computing the intersection with a JOIN is much too slow in MySQL, so we have to do it in PHP.
If they claim that doing any heavy computation is faster in PHP than in MySQL they are obviously 100% incompetent at dealing with databases. And I say that as someone generally laughing at MySQL compared to other database-engines. They actually prove this in their explanation:
Query Friends for all my friends. With a cold cache, this takes around 1.5 seconds to complete.
With proper indexes this should take 100ms at most.
Not saying that non-relational databases don't have uses, but every single case I've seen the specifics of where a NoSQL solution is proposed as a better alternative with regard to performance and scalability has so far been rooted in incompetence. Make of that what you like.
Agree. There are still cases where assembly language is the appropriate choice. That doesn't mean those generalize to "business" use cases.
Sure there are cases where a "nosql" approach makes sense. But the examples cited (Google, Digg) bear little similarity to a typical "business" use case, and I'd claim that for "business" applications RDBMS is generally the best solution.
For example, key/value DB's have enabled me to better implement features of a enterprise web app I am working on. The lack of a defined schema, in particular, was a strong business case for deciding to use key/value DB's. This document-based app can now store arbitrary fields on a per user basis (which was a headache with SQL!), which is a key USP for the app.
Although, I agree, these points are tech-related. It would be nice to see the article mention true business use cases, such as transactions (i.e for financial, sensitive data applications).
For the typical web app, you can't really go wrong selecting MySQL or Postgres. However, you also can't really go wrong to pick something like GAE's data store either. Unless you need sophisticated dynamic reporting capabilities, a key/value store is actually easier to work with than a relational database. A static schema slows you down, but it is a price worth paying if you need to a powerful query language and aren't concerned about scaling.
