What's an IOP you might ask? I wouldn't have known that acronym yesterday if you'd asked me since it's not one I see too often. However the boys a Big Blue are trying to get as many IOPs as they can. In fact, they've set a new record with more than 1 million input/outputs per second (IOP), sustained with a 1ms response time.
Now that might not be impressive, but consider this. It's a 4TB array, and it exceeds the previous benchmark by 250% with 5% of the previous response time. It also uses on-fifth of the floor space and just over half the power. That's quite an improvement, especially as we are more and more concerned about space, power, and heat loads.
How did they do it? They moved to a solid state array, essentially big, fast flash drives full of SSDs, solid state disks. They've built one heck of a large flash drive, though I'm not sure this one would fit in your pocket.
I think that at some point many of us will have SSDs backing our databases and then quite a few things change. Actually I've almost never needed 4TB of space for most of my databases. That 4.1TB array would work nicely for any of the instances I've managed in the past, and more than a few of them would benefit from the speed.
As I read this, however, I have two things that concern me. The first is that I wonder if all the query optimizer's various algorithms for read-ahead, costing, etc. will be rendered obsolete. I would imagine that they would still apply, but I hope that Microsoft Research or the SQL Server query processer teams are working on this and trying to determine if there are changes that should be made. Eventually it won't matter, but while some of us use SSDs, some of us don't, and some of us have mixed environments, it could be an issue. I hope we don't end up with more complicated tuning parameters that need to be set.
The other concern is that this advance in hardware reminds me of the hardware advances of the 90s as CPUs got faster and faster, moving from my 286 12Mhz to the current GHz processors we have today. While it certainly meant that we had better running computers, it also helped propagate one other thing:
Bad code.
If today's programmers can count on faster disk drives, essentially memory speed, are we going to see more and more bad SQL in tomorrow's databases? I certainly hope not.
Steve Jones
Steve's Pick of the Week
Inside the Ship Room - A video of the RTM, kind of silly, not great camera work, but still interesting to see the project managers signing off on a piece of paper.
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
Overall RSS Feed:
or now on iTunes!
Today's podcast features music by Incompetech. Kevin Macleod has some great compositions in all genres of music. Check him out at www.incompetech.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.
