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.
Although, you could argue that the business use defines the technology use case which, in turn, informs the decision to use "nosql".
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).
While the first and third are legitimate the second point regarding Digg isn't so clear.
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.
While I know very little about MySQL, I was surprised by that example too. How a relational join could be slower than that couple of query's? Moreover, at first glance, why didn't do exactly the same with a subselect(MySQL supports them now, right)? The second query seems to me a performance killer (dynamic by nature, has to be parsed every time).
I checked the link to the digg case myself, and then I found this:
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.
After some significant work with Google App Engine's data store, I can't help but think that the question "What are use cases for No SQL technologies?" should be turned on its head. Instead, ask yourself "Do I need full SQL database"?
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.
[+] [-] ams6110|16 years ago|reply
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.
[+] [-] milestinsley|16 years ago|reply
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).
[+] [-] newhouseb|16 years ago|reply
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.
[+] [-] samuel|16 years ago|reply
[+] [-] mhmt|16 years ago|reply
[+] [-] trezor|16 years ago|reply
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.
[+] [-] snprbob86|16 years ago|reply
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.
[+] [-] ct4ul4u|16 years ago|reply