I understand the appeal of saying something like “The reason we need to be aware of physical design is largely complex query performance. Complex query performance is an issue mainly because of I/O. If we have better storage technology, that problem goes away, and we can start ignoring physical design the way the theorists have always wanted us to.”

But I think we’re a long way from reaching that ideal, at best. Data warehouses are BIG, and getting bigger. They’ll push the limits of hardware technology for a long time to come.

The value of SSD is not going to be in highly redundant, flat-file (called whatever you want) style datastores; price will be too high. The value will be in high NF relational databases. Now, in my opinion (which you can read, and I am not alone), SSD will be the motivator that merges back OLTP with its various replicants. SSD, and the flash versions (both MLC and SLC) are only the latest low-end implementations (check Texas Memory Systems for one example of industrial strength SSD), removes the join penalty from 3/4/5NF databases.

The bottleneck will be in finding folks with enough smarts to embrace (again) Dr. Codd’s vision. The xml folk are not those kind of folk. My candidate is Larry Ellison. The reason is that the Oracle architecture, MVCC, is superior for OLTP (IBM finally just capitulated with entrpriseDB). With SSD, he can use the Oracle database, appropriately normalized, to support both without stars and snowflakes. A true one stop solution.

I agree with you that workload has something to do with performance. Ignore the poor wording. I mean that you won’t get 10X more MB/s or IOPs from 15k SAS versus 7200 RPM SATA. Teradata has done clever things with track aligned reads to optimize disk performance. I would much rather read about that.

Maybe the eBay guys diagnosed their situation correctly and maybe they didn’t, but I can’t begin to fathom your basis for saying that workload has nothing to do with it.

CAM

@Curt – workload has nothing to do with it. Oliver has made a controversial claim with no substantiation. That is marketing and nothing else.

When high session concurrency is factored into how the database operates, this results in a very large number of different IO paths in addition to the random placement of the data. There are certainly efforts by the entire tech stack to geographically colocate like data, but it is this random IO with concurrency environment which causes much, much greater head movement.

When you compute seek time and rotational time together in a 100% random block read environment – 10x is simple to see. At 7200 RPM, it takes 2x longer to read a track of data on a SATA drive – which also is likely to have several times more data per track, most of which is not needed for random IO.

With SATA Seek Latency of ~4x the FC drives, the two combine for something larger than 10x… this does not even count the compute and algorithmic issues or where in the tech stack the computation occurs. A highly simplistic and not entirely realistic example, but it should illustrate the point.

SATA disk systems compete very well in low concurrency large sequential block environments, which is entirely opposite the Teradata environment. So, the 10x number being quoted here is not a surprise.

I don’t understand why you’re extrapolating from your home system to eBay’s data warehouse. Are the workloads similar?

In particular, Oliver tells me the problem usually doesn’t arise when there’s only one query running, especially if the query can be satisfied by quasi-sequential scans. How many simultaneous queries did you run your test with?

Thanks,

CAM

I get 100+ IOPs and 50 MB/second from consumer grade 7200 RPM SATA disks at home, so a 15k disk needs to do 1000 IOPs and 500 MB/second to be 10X better or my cheap disk needs to do retries on almost every request. I don’t think that is typical. Maybe they had a bad batch of disks or very old disks.

There is SMART monitoring on disks that counts retries and other stats and there have been a few large scale studies based on this data. So the data is there, but it isn’t easy to accumulate at a large scale.

This paper is a good start and has references to other good papers.

http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Flabs.google.com%2Fpapers%2Fdisk_failures.pdf

I don’t have serious data beyond what I posted. I’m hoping other folks with information will jump into the discussion.