Re: w/c RAID on a SQL box
> Raid 1 is faster than a single drive for reads, but about the same for
> writes. To get more speed, use raid 0+1, striping plus mirroring. That
> wastes a lot of disk, but is faster than level 5 for writes. Keep in
> mind, RAID 1 is only mirroring using two disks (typical).
>
> Raid 5 is slower for writes because for every operation it needs to
> calculate parity. If you're using a screaming controller (such as Mylex
> ExtremeRAID w/ 233MHz StrongARM) the impact is far less. However, reads
> are going to be comparable, if not faster, than raid level 1. It depends
> on how many spindles you have in the array. Raid level 5 has a minimum of
> three disks. Data is striped across all three, with the parity
> information also striped along with it.
Agree with this, but there's more to it!
What kind of reads? Are they large sequential with OS read ahead, or random
access?
As RAID5 reads need all disk arms to get data, because it is striped across
the disks, if there are other read/writes going on there may be considerable
contention. The reading may get held up, by a long wait for one particular
arm.
If that doesn't make immediate sense, think of a kid's board game, where
they have to throw a particular number to make progress. Often leads to
frustration, as the number just won't come up.
RAID1 reads, have a choice of disk, as data is on both, additionally you may
have a 3-way mirror, giving the driver yet more opportunity for
optimisations, and clever use of disk elevator algorithms.
Not all implementations will actually do this in practice, but the chance is
there.
Now on RAID5, large sequential writes, there's no contention, as a group of
blocks is written, and the parity block can be calculated immediately from
all the blocks written. Now imagine if you have a Random Access Write of
just one block, what does it have to do?
To change one block RAID5 has actualy to go and read the other blocks in the
stripe of the other disks, in order to caculate the parity block!
This is what makes RAID5 unsuitable for Database applications. It's a
great reliability/space trade off, and works very well for general file
system applications, in I/O there's just no one size fits all solution.
Yes, a large cache in the controller reduces, but doesn't solve the problem,
it only helps with the hot spots, and of course Database's tend to be very
random in their access *evil grin*
Rob
Reply to: