In the spin of SSDs on database servers
The future is static
Interest in solid state drives (SSDs) is growing as their initially terrifying price plummets: Intel recently announced a 60 per-cent reduction in the cost of its X25-M Mainstream SATA SSD since its launch last year.
SSDs are attractive because they radiate less heat than traditional spinning disks, they're smaller, quieter and consume less energy. And, of course, they're fast. So naturally we bung them into laptops.
However, there's growing use of SSDs in servers, and particularly database servers. Teradata, one of the world's leading business intelligence companies, recently unveiled a prototype data warehouse running entirely on SSDs.
Do the same reasons reasons for using SSDs on a laptop also apply to database servers? And what do SSDs mean for the applications that will access the data they hold?
Performance improvement is certainly top of the list of appealing factors, but uptake is also being driven by energy issues. Keeping servers cool is an ongoing battle so anything that reduces the heat generation is welcome, so how do the two technologies stack up?
A 600GB HDD might use about 16 watts when active: that's about 30W per terabyte. The X-25M has an active power consumption of 150mW. Running six of the 160GB SSDs gives a figure of about 1W/TB - 30 times less. If that wasn't reason enough, the cooler disks can be packed more closely together saving space, another server-room plus point.
So, what of the speed? To read from a particular place on disk the read/write head in an HDD must move to the right position, which takes "seek" time - quite variable but let's say an average of four milliseconds. Once the head is in position there is a "latency" as the sector containing the data crawls painfully around to it's appointed position under the head.
A 15,000 rpm HDD might have an average latency of two milliseconds. An SSD with no moving parts doesn't really have equivalents but latency may be quoted - for example a recent SSD was rated at 65 microseconds.
All the advantages of using SSDs for general servers hold true for database use, but there are other potential advantages. Databases have always, if you ignore punched cards, used rotating media and whilst HDDs aren't serial access, they certainly aren't random access either, so all manner of database mechanisms have been developed to improve data access performance. I'll pick on just two: indexing and column/row oriented databases.
A non-clustered index is often a sorted list of pointers to data and for performance reasons should be kept on a separate spindle. Of course if the table is small enough, and particularly if it's marked as read-only - as it may well be for analysis - any database engine worth its salt will run a full table scan, pop the table into memory and ignore the index. Why? Because memory is much faster than disk. Intelligent DBAs understand all this and modify their indexing strategies accordingly.
Moving down the scale, there are doubtless DBAs who index all fields needing fast access regardless of table size, those who do this and keep the indexes on the same disk as the data and even those who don't know about indexes.