On Thu, 9 Aug 2007, Decibel! wrote:
> On Thu, Aug 09, 2007 at 08:58:19PM -0500, Scott Marlowe wrote:
>>> On Thu, Aug 09, 2007 at 05:29:18PM -0500, Scott Marlowe wrote:
>>>> On 8/9/07, Decibel! <decibel@decibel.org> wrote:
>>>>
>>>>> Also, a good RAID controller can spread reads out across both drives in
>>>>> each mirror on a RAID10. Though, there is an argument for not doing
>>>>> that... it makes it much less likely that both drives in a mirror will
>>>>> fail close enough to each other that you'd lose that chunk of data.
>>>>
>>>> I'd think that kind of failure mode is pretty uncommon, unless you're
>>>> in an environment where physical shocks are common. which is not a
>>>> typical database environment. (tell that to the guys writing a db for
>>>> a modern tank fire control system though :) )
>
> You'd be surprised. I've seen more than one case of a bunch of drives
> failing within a month, because they were all bought at the same time.
>
>>>>> while with RAID10 you can
>>>>> potentially lose half the array without losing any data.
>>>>
>>>> Yes, but the RIGHT two drives can kill EITHER RAID 5 or RAID10.
>
> Sure, but the odds of that with RAID5 are 100%, while they're much less
> in a RAID10.
so you go with Raid6, not Raid5.
>>>> While I agree with Merlin that for OLTP a faster drive is a must, for
>>>> OLAP, more drives is often the real key. The high aggregate bandwidth
>>>> of a large array of SATA drives is an amazing thing to watch when
>>>> running a reporting server with otherwise unimpressive specs.
>
> True. In this case, the OP will probably want to have one array for the
> OLTP stuff and one for the OLAP stuff.
one thing that's interesting is that the I/O throughlut on the large SATA
drives can actually be higher then the faster, but smaller SCSI drives.
the SCSI drives can win on seeking, but how much seeking you need to do
depends on how large the OLTP database ends up being
David Lang
