what InnoDB config you use to get sustained 10K+ transactions/sec? Are you using XtraDB?

Do you put transaction logs on a separate HDD or do you put it on FusionIO as well?

Do you use binlog? Group commit is reportedly to be still broken when binlog is enabled (http://kristiannielsen.livejournal.com/12254.html) so don’t know if it’s possible to get sustained 10K+ trans/sec if binlog is enabled.

With build-in InnoDB you really would not see difference between SSD cards.
To see improvement you should try InnoDB-plugin, or XtraDB for even better performance.

Update from the field, we have gone through extensive testing 08-09 with FusionIO and even Violin Memory in terms of SSD / RAM based systems for our very large InnoDB-based database (dataset about 100 GB).

We have tested extensively with these products, and eventually settled on OCZ Z-Drive R2′s which we put into production last week.

Our testing revealed not much difference between the three vendors, what we really discovered was that InnoDB’s built in deficiencies / problems at scale are the slowest common dominator in the entire equation.

So there’s no reason to spend the big bucks on the Fusion IO — the OCZ R2 is 1/3 of the price and well worth it.

1) FusionIO has been impeccable at support. If a cards fails (as I mentioned there were some early manufacturing defects), we page them in the middle of the night and they find a way to get us a replacement card (we’ve had sales reps drive to meet us somewhere with a replacement card).

2) After being in the industry a long time, I demand single vendor support. I no longer am willing to buy whitebox hardware. We’ve had too many issues that require too much time and resources to diagnose parts made by different folks (RAID card, drive, backplane, etc) that isn’t integrated by a single vendor into a single hardware monitoring/diagnostics package. So, we buy HP so we can sleep at night. And that means the Intel and other SSD’s are out because HP isn’t going to support us taking their hot-swap drive sleds and screwing in SSD’s and expecting the HP RAID controller to properly support it.

With the FusionIO cards + drivers, we do constant monitoring of estimated remaining life (based on number of writes to each cell), free LEB’s, and other important data so we can predict any bad behavior or data loss. You can also down-format the usable NAND flash on the FusionIO cards to improve write performance during emergency groomer maintenance when the card is out of free LEB’s, which makes the card perform better during these situations (all flash devices slow down by orders of magnitude during LEB exhaustion unless you build in a ton of intelligence and a very large LEB pool to move around in). In fact, we have a few systems that run so hot at writes 24×7 that after a week of uptime, we always out pace the groomer, and we’re always out of free LEB’s, and we don’t notice any performance degradation. In those systems we down format the cards by 25-35% to get that performance during LEB exhaustion.

As for redundancy and stripping FIO cards, outside of a few hardware failures on the cards in early manufacturing, and the driver instabilities that have been worked out that we went through 2 years ago, our systems run at 2-10k IOPS/sec 24×7 100% stable. We use all HP Proliant servers with our FusionIO cards. Every once in a great while we’ll see a server crash, usually unrelated to FusionIO, like a kernel panic or something, and the FusionIO cards will do their unsafe shutdown scans (7 minutes on first boot per 160GB of FusionIO), and then we’re able to run fsck just fine and bring the file system and MySQL back online.

Because we stripe the data across two cards with no redundancy in the system, we used a percentage of the money we saved to just buy more systems with more FusionIO cards and add more MySQL replication slaves =) So, IE, instead of 2 servers each with $200,000 storage arrays, we have 6 servers each with 2x160GB FusionIO cards, and we still saved money in the end, not to mention the power, rack space, cooling, etc.

Are there other competitors trying to get into the market? Yes. Are there applications where cheaper SSD solutions (IE, the mustang) will probably make better monetary sense than FusionIO (IE, the ferrari)? Yes. Competition is good. And it all depends on your application. In our case, we run very high transaction rate databases that would knock just about every other flash solution on the market on it’s rear end.

Did you test X25-E/M in production? Percona’s benchmarks showed them to have even better ROI than FusionIO – 50-60% of FusionIO’s performance at 10-20% of its cost. But I wondered if they could maintain their performance level when they’re no longer new.

Isn’t it dangerous to stripe data on 2 FusionIO cards? Has that caused any data loss?

*drools*

Thanks for the info.

Did you test X25-E/M in production? Just wondered how they would hold up after some aging. From benchmark (like this: http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-vs-fusionio/) they seem to represent a even better ROI then FusionIO – 50-60% of FusionIO’s performance at 10-20% of its cost. Don’t know if they could sustain that performance after they’re no longer new.

Also isn’t striping your data over 2 cards a bit dangerous? Has that caused any data loss?

Andy – You asked why nobody else is in the market. The answer is because it’s not easy to build this thing, and for anyone entering the market, FusionIO is at least 1.5 years ahead on development (and that doesn’t just mean performance). We’ve been able to make incredible progress on shrinking our MySQL environment, getting rid of piles of SAN arrays we spent $50k-$500k on just for IOPS performance, with just 2x160GB cards per system (and we only do 2 so that we can stripe them to fit our entire dataset on them, otherwise 1 would be plenty.)