pgsql@mohawksoft.com wrote:
>>pgsql@mohawksoft.com wrote:
>>
>>
>>
>>>What you are missing is that the RAID is dealing with the multiple drives
>>>as one drive. Two operations have to happen serially,
>>>
>>>
>>>
>>You're kidding or vastly underestimating raid controllers. The average
>>db access is well served with a single block of data, stored on a single
>>drive. Nicely parallelizable by a raid controller if it has a minimum of
>>smartness.
>>
>>
>>
>
>The data contained on a RAID is spread across all the drives in the raid,
>is this not true?
>
>
Data is spread *blockwise*, usually 32k or 64k blocks of data. This
means, that typically 8 to 16 database blocks will reside on a *single*
disk, with additional parity data on other disks.
>To access data on a drive, one must get the data off all of the drives at
>the same time, is this not true?
>
The data is usually completely on a single drive.
>
>If you perform two different operations on the RAID, you must access each
>RAID drive twice.
>
>If you perform different operations on multiple different drives, you can
>access the same amount of data as you would with the RAID, but have
>parallelized operations.
>
>This is a fact. It is *the* drawback to RAID system. If you do not
>understand this, then you do not understand RAID systems.
>
>
>
You indicate clearly that it's you having strange opinions of raid
controller/subsystem functionality executing multiple commands.
>Perform any benchmark you want. Take any RAID system you want. Or,
>actually, I have a factual reason why RAID systems perform worse than
>multiple single drives, I have written a quick program to show it. I have
>even double checked on my own RAID system here.
>
As I said, the "benchmark" you wrote does by no means simulate DBMS
access patterns, it might be good to show video streaming performance or
so.
Please do read dbms disk io white papers, e.g.
http://msdn.microsoft.com/archive/en-us/dnarsqlsg/html/sqlperftune.asp
Teaching hardware issues is OT for this list.
Regards,
Andreas