Re: w/c RAID on a SQL box
I have to disagree. These seem to be flipped around.
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.
Here's a good description of raid 5, and other raid types. (commercial
site) --> http://www.raid5.com/04_01_05.html <--
The more spindles you have, the faster your array, not vice-versa, as you
have multiple clunky mechanical spindles working at the same time.
However, the benefit decreases exponentially as you add drives.
For your description of many SELECTs and read operations, I would say RAID
5 is your better option of the two.
-Kevin
On Thu, Nov 16, 2000 at 10:19:06AM +0100, Santiago Palmier Campos wrote:
> Hi chad,
>
> As Rod said, RAID 1 is a mirroring solution and RAID 5 can be called
> something like "stripping with data recovery" ;)
>
> But what you must consider is...
> RAID 1 is faster for _reading_ data (as it uses only 1 disk for
> read)
> RAID 5 is faster for _writing_ data (as it distributes data across
> several disks)
> If you app __mainly_writes__ a lot of data (INSERTs & UPDATEs) RAID 5 _is_
> your solution
>
> OTOH you must have in mind that...
> RAID 1 is _slower_ for _writing_ (same info into 2 disks)
> RAID 5 is _slower_ for _reading_ (read info from several disks)
> If your app __mainly_reads__ a lot of data (SELECTs) RAID 1 is your solution
>
> What is "more secure"? Well...
> RAID 1: same info on 2 disks... as safe as at least 1 disk is OK ;o)
> RAID 5: safe if _only_ 1 disk fails. You can recover info on this
> disk with the info from the others, but if 2 disks fail at the same time
> =8-O ...
>
> IMHO RAID 5 is a better solution for "common apps", but for an DDBB app...
> you must evaluate the main operation you're doing: reading or writing, and
> then evaluate both options.
>
> I'll suggest RAID 5 for app files & RAID 1 for data storage, obviously with
> a good backup policy ;o) but I don't know if it's possible at your hosting
> company :o?
>
> Best regards
> Santy
>
> -----Original Message-----
> From: R. W. Rodolico [mailto:rodo@dailydatainc.com]
> Sent: jueves, 16 de noviembre de 2000 4:47
> To: debian-isp@lists.debian.org
> Subject: Re: w/c RAID on a SQL box
>
>
> RAID 5. Easy to set up, fast, and reliable. Uses more disks, however.
>
> RAID 1 is, I believe, mirroring. With that, all info must be written to
> two different disks. With RAID 5, the disks are "striped" (not really,
> but I don't remember the real name for it) and part of each byte, with a
> checksum, goes on each disk. So, your disk writes are actually being
> written to multiple disks, so they are faster (in theory). And, if one
> disk fails, you can recover because the failed disk can be rebuilt fro
> the others.
>
> Rod
>
> > hello,
> >
> > my hosting company told me that they only support either RAID 1 and
> RAID 5.
> >
> > so given this choice, w/c would you suggest?
> > i use a MySQL database for a bulletin board application w/c does
> _LOTS_ of
> > SELECTS and data lookup.
> >
> > thanks in advance,
> > chad
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Calendar - Get organized for the holidays!
> > http://calendar.yahoo.com/
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> >
> >
>
> R. W. Rodolico
> Daily Data, Inc.
> POB 140465
> Dallas TX 75214-0465
> 214.827.2170
>
> It appears I could be pursuing an untamed ornithoid to no purpose.
> --Brent Spiner as Data, Star Trek: The Next Generation
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: