"HDD bound" here means that not all data fits into the cache.
Given the average RAM size on even an entry-level server (some 16 or maybe even 8 GB) and the average size of a database (same 8GB on http://musicbrainz.org/, the largest online music database), I wouldn't claim that it's "most workloads".
If we're comparing anecdotes, the smallest database I deal with on any given day is 50GB. Enterprise applications trap lots of data. I don't know that most of our queries are HDD bound, but a significant portion of them are.
I think while the most performance-critical portion of your data fits in memory you should be alright with this method. The rest of the data can be consumed using normal SQL approach.
Comments
"HDD bound" here means that not all data fits into the cache.
Given the average RAM size on even an entry-level server (some 16 or maybe even 8 GB) and the average size of a database (same 8GB on http://musicbrainz.org/, the largest online music database), I wouldn't claim that it's "most workloads".
If we're comparing anecdotes, the smallest database I deal with on any given day is 50GB. Enterprise applications trap lots of data. I don't know that most of our queries are HDD bound, but a significant portion of them are.
OK, OK. Most of your workloads are HDD bound.
Isn't that the definition of anecdote?
I think while the most performance-critical portion of your data fits in memory you should be alright with this method. The rest of the data can be consumed using normal SQL approach.