Solid-state disk stands to help DBMS-based systems in a big way, whether used in PCIe cards or otherwise.
It's quite remarkable how quickly flash memory has changed the computing scene in just a few short years. For example, back in 2008, an article in ACM Queue, openly wondered, "What if flash disks delivered thousands of IOPS and were big?" Looking ahead to 2012, the authors speculate that they might "replace a $44,000 disk array with a few (say, 10) $400 flash disks (maybe)."
By 2010, Andy Novick at Novick Software was writing on the website of his firm about getting a single flash PCIe accelerator board to hit 70,000 IOPS. Unfortunately, to hit that number, Novick wrote, he had to reduce each of those IOs to a size -- he doesn't state a number -- that was too small to be of much help in speeding up the SQL Server database. But progress was being made, it was clear.
And now, at SQLblog.com, which is devoted to technical talk about Microsoft's flagship DBMS, a certain Joe Chang, who appears to be quite the SQL Server expert, writes in great depth about the advantages of using SSD with that DBMS. It's a given, now, that SSD can be a big help in DBMS performance.
Chang's article is not specifically about SSD, but for anyone involved with SQL Server and wondering about how to navigate the fast-changing storage scene right now, I cannot imagine a better discussion than this one. The title is simply "Storage Peformance," but Chang looks into all sorts of options in great detail, weighing SSD against SAN, considering various SSD form factors (SAS, PCIe, etc.), and looking at everything with considerable technical skill. It's very impressive work, not least for the wealth of illustrations, as many of the comments the piece has received readily make clear.
Chang finds much to admire in SSDs -- low latency, high bandwidth, the usual parameters -- but he doesn't recommend just swapping hard drives for flash wholesale:
I believe that the all-SSD idea is misguided. SSDs are wonderful, but HDD still have an important role. One example is having the HDDs available for backup and restores. I want local HDD for backups because so very few people know how to configure for multiple parallel 10GbE network transmission, not to mention IO bandwidth on the backup system.
And clearly, backup is important:
A database backup that has not been actually verified to restore (with recovery) is a potentially useless backup. Having HDDs for backup and restore verification preserves the write endurance on the SSD. This allows the use of high-endurance MLC instead of SLC. In some cases, it might even be possible to use consumer grade MLC if and only if the database organization maintenance strategy is architected to minimize wear on the SSD.
Chang is particularly enthusiastic about PCIe-based flash acceleration, which brings the high-speed, non-volatile memory very close to the processor. "As is, today," he writes, "a PCI-E SSD can achieve maximum bandwidth at lower NAND capacity and in a more compact form factor than with SAS SSD."
On the other hand, he notes, SAS is more flexible in terms of expansion. But "PCI-E slot SSDs are highly suitable for high density requirements with limited expansion needs. One database server example is tempdb on SSD."
Upcoming extensions to the PCIe format will help, Chang notes. These include PCIe switches, the Express Bay plug-in scheme, and the NVM Express protocol designed specifically to help move data in and out of flash memory on PCIe boards.
If SQL Server's your game, and SSD is on your mind, check out Chang's discussion. You're sure to learn something. And my educated guess is, what he has to say is valid for more database management systems than SQL Server alone.