Green Technology, Toss out your Solid State Drive?
« previous entry | next entry »
Jul. 12th, 2007 | 04:01 pm
Hard drives are noisy, eat electric, getting slower, and might go the way of the Doo-Doo.
About four years ago I found a PCI card that had 256megs of memory on it, and a battery that let it last 48 hours with no power to the computer.
Innodb log files! Yes, put the log files on it and watch the performance go up. It was a neat hack but for $800 a card it wasn't all that practical. The performance was nice, but it wasn't worth the
additional investment per machine for the card.
A number of months ago Jeremy Cole blogged about some solid state cards he was looking at. At around the same time I noticed and commented on "IDE" solid state drives coming to market.
Dinner on Tuesday night with Kevin Burton pushed this into my mind again. What was he looking at going with for his data center?
Solid state drives.
This is smart thinking, it makes a lot of sense.
The performance gain for using solid state hard drives for any database, not only MySQL, is a "no argument". Buying performance like this does require some cost analysis. You balance performance with cost. Not everyone buys fiber channel even if it buys performance.
The performance gain does not outweigh the cost.
Capacity though is a requirement. By capacity I mean the ability to put X amount of CPU in a given space.
Data center capacity is not a growing concern, it is an active concern.
Data centers need power, a lot of power. Their capacity is constrained by available power.
Green technology is common sense. Hard drives have moving parts that generate heat, eat electric, and have high failure rates.
Green technology means capacity because data centers can pack in more hardware.
Tom's Hardware gave a price of $25 per gig almost a year ago. Tom was reviewing a 32 gig drive at the time (which... at 64 I don't need a hard drive in my laptop... I keep my mp3 on my iPod not my laptop).
Today we are looking at about $19 a gig, with 128gig drives coming to market.
This is a premium, when you consider SATA half terabyte disks are at $100 (which works out to 19 cents a gig!).
How much of a price tag do you put on capacity?

About four years ago I found a PCI card that had 256megs of memory on it, and a battery that let it last 48 hours with no power to the computer.
Innodb log files! Yes, put the log files on it and watch the performance go up. It was a neat hack but for $800 a card it wasn't all that practical. The performance was nice, but it wasn't worth the
additional investment per machine for the card.
A number of months ago Jeremy Cole blogged about some solid state cards he was looking at. At around the same time I noticed and commented on "IDE" solid state drives coming to market.
Dinner on Tuesday night with Kevin Burton pushed this into my mind again. What was he looking at going with for his data center?
Solid state drives.
This is smart thinking, it makes a lot of sense.
The performance gain for using solid state hard drives for any database, not only MySQL, is a "no argument". Buying performance like this does require some cost analysis. You balance performance with cost. Not everyone buys fiber channel even if it buys performance.
The performance gain does not outweigh the cost.
Capacity though is a requirement. By capacity I mean the ability to put X amount of CPU in a given space.
Data center capacity is not a growing concern, it is an active concern.
Data centers need power, a lot of power. Their capacity is constrained by available power.
Green technology is common sense. Hard drives have moving parts that generate heat, eat electric, and have high failure rates.
Green technology means capacity because data centers can pack in more hardware.
Tom's Hardware gave a price of $25 per gig almost a year ago. Tom was reviewing a 32 gig drive at the time (which... at 64 I don't need a hard drive in my laptop... I keep my mp3 on my iPod not my laptop).
Today we are looking at about $19 a gig, with 128gig drives coming to market.
This is a premium, when you consider SATA half terabyte disks are at $100 (which works out to 19 cents a gig!).
How much of a price tag do you put on capacity?
(no subject)
from:
woggie
date: Jul. 12th, 2007 11:42 pm (UTC)
Link
I could be wrong, of course. :)
Reply | Thread
(no subject)
from:
krow
date: Jul. 13th, 2007 12:01 am (UTC)
Link
Thank you google!
Or maybe Googoogle...
Reply | Parent | Thread
what he said
from:
jypsiedesign
date: Jul. 13th, 2007 02:45 am (UTC)
Link
Reply | Parent | Thread
Re: what he said
from:
krow
date: Jul. 13th, 2007 02:53 am (UTC)
Link
Reply | Parent | Thread
Re: what he said
from:
woggie
date: Jul. 13th, 2007 02:59 am (UTC)
Link
Reply | Parent | Thread
(no subject)
from:
woggie
date: Jul. 13th, 2007 12:13 am (UTC)
Link
Reply | Thread
Data set........
from:
burtonator
date: Jul. 13th, 2007 04:24 am (UTC)
Link
If you have a small data set that's being POUNDED with queries then putting the whole thing in memory or on SSDs could be a big win.
NDB is doing well here and this is at least the niche their searching.
And by 'well' I mean "once you get it working"
....
I think we'd still be using HDDs in other areas for the foreseeable future. We're considering building out a petabyte store for some fun projects we're thinking about and SSDs would just be far too expensive here.
Reply | Thread
Re: Data set........
from:
krow
date: Jul. 13th, 2007 04:34 am (UTC)
Link
My active databases for content I provide up to users is not all that large. Slashdot could easily fit on one of these drives, I suspect many of the popular sites could.
Reply | Parent | Thread
Re: Data set........
from:
burtonator
date: Jul. 13th, 2007 04:37 am (UTC)
Link
but yeah... I'd think that most DBs could easily fit on a 128G SSD.... the iops for these will be about 2k which is an order of magnitude over commodity SATA drives. You'd probably still need to shard the data and maybe even need to buffer in RAM but it would be a lot faster!
Reply | Parent | Thread
price prefromance of SSD
from:
wikiwikimoore
date: Jul. 13th, 2007 09:52 am (UTC)
Link
http://www.mtron.net/eng/sub_eb1.as
any way IOps are what you pay for with SSDs
Reply | Thread
another factor...
from:
_pollox
date: Jul. 15th, 2007 11:37 pm (UTC)
Link
http://www.bitmicro.com/press_resources
Longevity/Lifespan
Unlike DRAM, flash memory chips have a limited lifespan. Further, different flash chips have a different number of write cycles before errors start to occur. Flash chips with 300,000 write cycles are common, and currently the best flash chips are rated at 1,000,000 write cycles per block (with 8,000 blocks per chip). Now, just because a flash chip has a given write cycle rating, it doesn't mean that the chip will self-destruct as soon as that threshold is reached. It means that a flash chip with a 1 million Erase/Write endurance threshold limit will have only 0.02 percent of the sample population turn into a bad block when the write threshold is reached for that block. The better flash solid state flash drive manufacturers have two ways to increase the longevity of the drives: First, a "balancing" algorithm is used. This monitors how many times each disk block has been written. This will greatly extend the life of the drive. The better manufacturers have "wear-leveling" algorithms that balance the data intelligently, avoiding both exacerbating the wearing of the blocks and "thrashing" of the disk: When a given block has been written above a certain percentage threshold, the solid state flash drive will (in the background, avoiding performance decreases) swap the data in that block with the data in a block that has exhibited a "read-only-like" characteristic. Second, should bad blocks occur, they are mapped out as they would be on a rotating disk. With usage patterns of writing gigabytes per day, each flash-based solid state flash drive should last hundreds of years, depending on capacity. If it has a DRAM cache, it'll last even longer.
Reply | Thread
Re: another factor...
from:
kepeslap
date: Jan. 7th, 2008 03:07 pm (UTC)
Link
have been looking out for something like this for a while...
Képeslap
Reply | Parent | Thread