Feeds

back to article Facebook smacks away hardness, sticks MySQL stash on flash

Facebook is using Fusion-io server flash cards in its datacentres to store MySQL data as well as process it faster because it's better than using disk drives. Piper Jaffray analyst Andrew Nowinski tells us that Facebook is using Fusion-io ioDrive PCIe flash cards for capacity as well as performance acceleration through flash …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

Turn off logging

....if you don't care about recovering your DB! FS journaling or any HW equivalent is missing the point. The figures given for space saving when turning off logging are also BS. The log file doesn't grow with the size of the DB!!!

Nothing against Fusion-io but if they really said this they know nothing about databases.

1
0
WTF?

math

4x the performance of Exadata and half the cost, which equates to a 16x cost/benefit advantage

can someone explain the math to me please?

0
0
Anonymous Coward

Re: math

Yes, it's complete BS, does that help?

I wish The Register would stop regurgitating PR crap as articles, must have been another slow real news day.

0
0
Flame

Tell me: how come half cost plus 4x performance = 16x price/performance?

Tell me: how come half cost plus 4x performance = 16x price/performance? Since he is an analyst he should understand at least the basics of math. I might be wrong, though - maybe being an analyst requires ablity to generate hype even if it clearly contradicts facts... And Chris, you could at least comment on this magic math he's breathlessly blessed us with.

0
0

Shudder

He says: "By leveraging Fusion-io cards.."

"leveraging"???

Doesn't he just mean "using", but wants it to sound like he's down wit da yoof in management bullshit?

0
0
Unhappy

50% space saving is stupid fiction

DB journaling will write the data twice for recovery, but the old journal will be dropped after a DB backup (or mirrored checkpoint), so the journal is never as big as the data… unless you never checkpoint or backup… in which case it will grow to 100%+ (but that’s academic ‘cus a recovery would fail anyway)

33% decrease in latency is also iffy because journal-write has almost no seek latency & a decent SAN will have NV write cache.. SSD will win big on random read.. but the rate depends workload.

For any workload more important than the musings of a spotty teenager, you’d want the journal anyway for replication.

2
0
Bronze badge

old news?

Facebook has been using Fusion IO for mysql for years now. Several years ago Facebook sent out a RFP to the big storage companies for a solution that could do 1 million IOPS. They got a bunch of demo systems, 3PAR among them, things were going well when fairly suddenly one of the 3PAR execs bailed and joined Fusion IO, he knew the pricing structure of what was going on and undercut the competition and won the deal. I did a bit of research on Linkedin and I think the guy that did that was someone named Steve Jackson who is the VP for North America sales at FIO. He was a Director of sales at 3PAR prior to that.

Given facebook is responsible for a big chunk of fusion io's revenue, if they weren't using it for mysql before what were they using it for? Certainly not memcache, not web servers.

0
0
FAIL

Over priced rubbish

With no idea of redundency/BCP..

0
0
Thumb Down

This doesn't make sense

If the largest part of the cost savings is from consolidating Oracle databases (and therefore licenses) on to fewer servers (cores), then this has nothing to do with Fusion-IO. Faster IO (and I would dispute that anyway) does not equate to fewer Oracle licenses. Faster clock speeds, and greater core counts combined with database instance consolidation is what reduces exposure to Oracle licensing.

0
0

Re: This doesn't make sense

If the database is CPU-bound, TheCreditCruncher's thoughts make perfect sense. But if the database is I/O-bound, switching to a faster storage medium could get more performance out of fewer CPU licenses. Most solid state storage basically makes I/O wait times disappear, so CPU utilization goes up, so overall database performance goes up beyond target metrics, so the number of CPU or server DB licenses required goes down. This doesn't apply to all workloads, of course, but many heavy-hit databases follow this pattern.

1
0

Re: This doesn't make sense

Good point.....well made.

0
0
This topic is closed for new posts.