Well, there probably is, but I’d love to see the technical scenarios behind which the 4 companies referenced in the article claim that much of a benefit.  None of my projects are yet to the point of scale where it would be likely, but I hope they will be soon.  I could probably learn a LOT from setting up informal interviews with the engineers behind those architectures.

Then I got to thinking about MySQL database server architecture and some consulting I’ve been doing for a friend of mine.  He’s running a fairly popular web forum based on raising chickens in your backyard.  Go ahead and pop over to www.backyardchickens.com if you’re interested in the topic.  He’s been facing some load problems with his database and his server environment he’s using.  He has some architectural decisions to make soon that have been heavily weighing on him lately, not the least of which deal with the size and structure of his MySQL database.

My thinking in his scenario where his load has gotten high enough to warrant fairly advanced performance tuning of his database, leaned me to thinking about one tunes a MySQL database, specifically when running the InnoDB or in-memory table engines.  Basically, the more memory you can throw at the system (and assign to MySQL for in-memory caching), the better it’s going to perform.  (Tuning gets much more advanced than that, but that’s the main portion of it).  It’s imperative these days that you use a 64-bit processor and matching OS and software if you have any sort of size on your database, lest you run into the 2GB process memory limit of 32-bit systems.

However, the reason that caching mechanism works so well is that it reduces the number of reads from disk that need to be executed.  It stands to reason, thinking logically anyway, that if you can get the read to write ratio down far enough, the disk subsystem will be spending most of it’s time writing.  If SSDs are supposed to perform much better than their standard disk counterparts, than the little time MySQL spends reading from the disks would be even faster, and the write performance would be even less, leaving much more time to spend answering queries from memory cache.

Of course, this is all hypothesis on my part since I am not deeply skilled in the arts of MySQL performance tuning.  Nor do I know a significant amount about SSDs, definitely not enough to say for certain whether their performance attributes would definitely be of benefit to specific MySQL architectures and design use cases.