A Little Hard Drive History and the Big Data Problem

Most of the “Big Data Problems” I see are related to performance. Most often these are long running reports or batch processes, but also include data loads. I see a lot of these as one of my primary roles is in leading Exadata “Proof of Value” (POV) engagements with customers. It’s my observation that over 90% of the time, the I/O throughput of the existing system is grossly under-sized. To be fair, the drives themselves in a SAN or NAS are not the bottleneck, it’s the 2x 2 Gbps or 2x 4 Gbps Fibre channel connection to the SAN more often than not. However, the metrics for hard drive performance and capacity over the last 30 or so years were a lot easier to find so that’s what this post is about.

In short, our capacity to store data has far outpaced our ability to process that data. Here’s an example using “personal” class drives to illustrate the point. In the year 2000 I could by a Maxtor UDMA 20 GB hard drive connected locally via (P) ATA which provided roughly 11 MB/s of throughput (the drive might be limited to a bit less, but not much). Today, I can buy a 3 TB Seagate Barracuda XT ST32000641AS that can sustain 123 MB/s of throughput. So, lets say I need to scan (search) my whole drive. 21 years ago that would take 31 minutes. Today it would take 7 hours! What?!?! The time it takes to search the data I can store has increased by a factor of 14x. How can this be? What about Moore’s Law? Sorry, that only works for processors. Oh right, I meant Kryder’s Law. Kryder’s Law states that magnetic disk areal storage density doubles annually and has nothing to do with performance. Well, actually this phenomenon is half the problem since throughput isn’t doubling annually.

I did a little research and found some relevant data on seagate.com, tomshardware.com, and of course The Wayback Machine. Now on to the data and some graphs (click to enlarge graphs):

	Seagate ST506	Rodime R032	Seagate ST3550A	Quantum Fireball ST3 2A	IBM DTTA-351010	Seagate Cheetah X15	Seagate Cheetah X15.3	Seagate Cheetah 15k.6	Seagate Cheetah 15k.7	Seagate Pulsar XT.2 SSD
Year	1979	1983	1993	1998	1999	2001	2003	2008	2011	2011
Capacity (MB)	5	10	452	3276	10240	18432	36864	460800	614400	409600
Capacity (GB)	0.005	0.010	0.441	3.2	10	18	36	450	600	400
Throughput (MB/s)	5	0.6	11.1	7.6	9.5	29	63.6	164	204	360
Capacity Factor of Change	1x	2x	90x	655x	2,048x	3,686x	7,373x	92,160x	122,880x	81,920x
Throughput Factor of Change	1x	0.1x	2x	2x	2x	6x	13x	33x	41x	72x
Capacity Percent Change	0%	100%	8,940%	65,436%	204,700%	368,540%	737,180%	9,215,900%	12,287,900%	8,191,900%
Throughput Percent Change	0%	-88%	122%	52%	90%	480%	1,172%	3,180%	3,980%	7,100%
Time in Seconds to Read Full Drive	1	16	41	431	1078	636	580	2810	3012	1138

So, what does all of this mean? Well, to me it means if you’re architecting a data warehouse or even small data mart, make sure you focus on the storage. Over and over again I get drawn into discussions about the minutiae of chip speeds or whether Linux is faster than Solaris, yet when I ask about the storage the answer is almost universally “we’ll throw it on the SAN”. OK, how many HBAs and what speed? Is the SAN over-utilized already? etc, etc, etc.

So, how does this relate to Exadata? The central focus of Exadata is I/O throughput. By including processing power in the storage servers, Exadata has a fixed relationship between capacity and throughput. As you add capacity, you add throughput.