Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switch Your Databases To Flash Storage

highscalability.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Switch Your Databases To Flash Storage

#41

Post by codemac »

bunderbunder wrote: post #14

Wear patterns and flash are an issue, although rotational drives fail too. There are several answers. When a flash drive fails, you can still read the data. A clustered database and multiple copies of the data, you gain reliability – a server level of RAID. As drives fail, you replace them. Unlike magnetic disks, SSDs have a tendency to fail at a really predictable rate. So predictably that if you've got two drives o…

> That said, if you're careful then that predictability should be a good thing.

Yes, it's a very good thing. In a high end SSD storage system, you predict early enough based on a calculation of how many drives there are, and what their current wear is, what type they are (SLC, eMLC, cMLC), etc. Then you phone home and have a drive delivered before the user even sees a disk failure.

With HDD's, the failure rate is so random that the disk completely failing is the signal that get's a replacement drive into the enclosure. S.M.A.R.T-type alert systems have been epic failures (too little info too late). The difference is because of the RAID rebuild having a lower probability of failure (let's set aside mulitple URE's for a second) that you can count on the mttf of the next drive failing being longer than the time it takes to get a drive out there.

However this is not much of a guarantee, so most people crazy over provision their storage.

SSDs let you predict this, thus provision correctly, and choose how to replace the drives to least impact the customer. It's win win to have predictable failure. I don't understand people who say otherwise.

Re: Switch Your Databases To Flash Storage

#42

Post by cioc »

Does anyone else find the section "Don’t use someone else’s file system" a bit confusing? It starts off by convincingly saying O_DIRECT shouldn't be used and then goes on to say O_DIRECT works very well.

Re: Switch Your Databases To Flash Storage

#43

Post by rxin »

ghshephard wrote: post #34

I'm surprised that the author didn't capture what I consider to be the most important component of HDD/Flash/Memory Balancing - frequency of access. The rule of thumb that I've heard thrown about is, "If you touch it more than once a day, move to flash. If you touch it more than once an hour, move to memory." While we can debate where that actual line falls based on both the price and performance of the various media…

Jim Gray wrote a classic paper about this. "The 5 Minute Rule for Trading Memory for Disc Accesses and the 5 Byte Rule for Trading Memory for CPU Time". http://www.hpl.hp.com/techreports/tandem/TR-86.1.pdf

There is an updated version that also talks about SSDs. http://cacm.acm.org/magazines/2009/7/32091-the-five-minute-r...

Re: Switch Your Databases To Flash Storage

#44

Post by jfb »

stcredzero wrote: post #33
ovi256 wrote: post #31

Earlier quoted context omitted.

NoSQL, making devs into DBAs since 2010: "But hey, look, we never hired any DBAs, that's a win right ?"

Object databases and ORM were trying to do that from at least the 90's.

And look how well that's worked out.

Re: Switch Your Databases To Flash Storage

#45

Post by trotsky »

I don't disagree with the conclusions, but don't you have to short stroke those ssds pretty significantly in a high transaction environment to avoid write amplification?

It's too bad longevity worries are keeping them out of the no commitment market.

Re: Switch Your Databases To Flash Storage

#46

Post by jasonkolb »

bunderbunder wrote: post #14

Wear patterns and flash are an issue, although rotational drives fail too. There are several answers. When a flash drive fails, you can still read the data. A clustered database and multiple copies of the data, you gain reliability – a server level of RAID. As drives fail, you replace them. Unlike magnetic disks, SSDs have a tendency to fail at a really predictable rate. So predictably that if you've got two drives o…

I wasn't aware of that... anyone know how that's handled when you're buying an SSD instance from say, Amazon? Do they predict failure and replace the drives before they go bad, or do you have to bake this into your deployment logic somehow?

Re: Switch Your Databases To Flash Storage

#47

Post by jeffdavis »

wmf wrote: post #35
otakucode wrote: post #23

Earlier quoted context omitted.

Since NAND flash is being price fixed, and likely will be for several more years to come (we're just now starting to see LCD prices drop to reasonable levels after years and years of price fixing, I expect it'll take a similar amount of time for the NAND fixing to get busted and the market to respond), I don't think a 10% premium will be at all possible for a very long time. NAND storage SHOULD be significantly cheap…

Note he didn't say 10% premium for the same capacity. It's possible for cloud providers to replace $50 hard disks with $64 SSDs today.

Does a $64 SSD have enough charge to flush pending writes after a power failure? If not, then be prepared for widespread corruption.

See comment by pjungwir.

Re: Switch Your Databases To Flash Storage

#48

Post by riobard »

cioc wrote: post #42

Does anyone else find the section "Don’t use someone else’s file system" a bit confusing? It starts off by convincingly saying O_DIRECT shouldn't be used and then goes on to say O_DIRECT works very well.

Linus Torvalds said O_DIRECT shouldn't be used because Linux's already implemented page cache and application developers should not bother to re-invent the wheel.

However page caching algorithms are pretty generic and database people think performance could be improved by using customized db caching routines instead of the generic OS one.

There are two ways to bypass OS page cache: 1) directly access the disk as a block device; or 2) use the O_DIRECT flag to disable page cache on a per-file/directory basis.

Direct access to disk as a block device would be ideal from the performance and flexibility point of view, but then you lose all the benefits and tools to manage databases as files. O_DIRECT flag seems to strike a sweet pot and that's what ended up being used most in the real world.

Then no body is really interested in improving the F_ADVISE interface, which is supposed to be a better than O_DIRECT from Linus's perspective. You know, the “worse is better” thing.

I'm not a db or kernel dev, but I've been watching this argument for a while, and so far that's my understanding. Very interesting.

Re: Switch Your Databases To Flash Storage

#49

Post by olgeni »

buro9 wrote: post #12

I would love if cloud providers offered SSD options for their full range of boxes. For example, to be able to get a Linode at only a fraction more of the cost (say, a 10% premium) with the disk being SSD (and obviously reduced capacity compared to HDD). I have seen the current offerings but found them to either be too costly (AWS, only one of the the largest instances), or too onerous (ssdnodes.com whose base product…

> I would love if cloud providers offered SSD options for their full range of boxes.

Both CloudSigma and ElasticHosts have SSD options.

On CloudSigma you can even grab a small SSD to use as a L2ARC or ZFS log device :)

Re: Switch Your Databases To Flash Storage

#50

Post by scoot »

bunderbunder wrote: post #14

Wear patterns and flash are an issue, although rotational drives fail too. There are several answers. When a flash drive fails, you can still read the data. A clustered database and multiple copies of the data, you gain reliability – a server level of RAID. As drives fail, you replace them. Unlike magnetic disks, SSDs have a tendency to fail at a really predictable rate. So predictably that if you've got two drives o…

With an SSD, though, once one drive goes there's a decent (perhaps small, but far from negligible) chance that a second drive will go out before you've had a chance to replace the first one. Which makes things complicated, but is much better than the similarly likely scenario that a second SSD fails shortly after you replace the first one. Because then it's possibly happening during the rebuild, and if that happens then it really will bring down the whole RAID array.

Not disputed that there's a slightly increased chance of concurrent disk failures with SSD, but on what basis is a second failure before rebuild any better than aduring it?

Also, I'm guessing you're referring to RAID5, as RAID6 / RAID DP is immune to double-disk failure, and RAID 10 and 0+1 are more tolerant of it.

Post reply on HN