I’ve read countless articles and posts in my quest to understand the nuances of storage.
I’ll add the useful links I have now, and will update this post over time.
General
These first three posts cover many aspects of storage, so they’re a great start:
- http://www.networkcomputing.com/storage-networking-management/ssds-and-understanding-storage-performan/240004957
- http://www.networkcomputing.com/servers-storage/more-on-performance-metrics-the-relation/240005213
- http://www.networkcomputing.com/servers-storage/of-iops-and-raid-how-raid-affects-applic/240007859
Some important excerpts from above:
For databases and other random-access applications, throughput is much less important than I/O latency and the number of I/O operations per second (IOPS) the storage system can perform.
So does it make sense to add SSDs to a storage system with 1-Gbps connections? Sure does, if that storage system is going to run a database application like Oracle, MySQL or even Exchange, all of which manage data in small pages. To saturate even one 1-Gbps connection would take 15,000 8K IOPS, while a 12-drive SATA system without SSD would struggle to deliver 1,500.
This relationship between IOPS and latency is one very good reason to pay more attention to published results from benchmarks like JetStress, TPC-C and SPC-1 rather than simple performance tests like Iometer.
In the real world many RAID controllers don’t have the bandwidth or CPU horsepower to achieve total parallelization, so a 14+1 RAID 5 set will do small I/Os significantly slower than a 5+1 RAID set.
While an oversimplification–as all rules of thumb are–the storage admin’s rule of thumb to use RAID 10 for random I/O workloads and parity RAID for sequential workloads does hold water. Of course, sequential workloads, other than backups, are becoming rare in today’s virtualized data center.
