tl:dr
The SAME (Stripe And Mirror Everything - meaning RAID 1+0) configuration
produces close to optimal performance for ALL workloads (Juan Loiaza - Oracle database chief architect)
Sophisticated hybid solutions are not dealt with here (see below).
Introduction:
Anytime someone says to me that their organisation is implementing a database storage system using RAID 5, I just shake my head in pity and sadness and say "I hope you have a lot of time to spend listening to your users complaining about poor performance!".
RAID 5 is (IMHO - see below) a false economy, penny-pinching solution to storage. It ends up being far more costly in terms of wasted time and resources in the long run. This is despite the fact that it is initially cheaper than RAID 10 (which is what one should use for databases in a production environment).
The following is copied from here:
Let's say you have a 6 drive array and your drives can do 100 I/Os per
second (IOPS). If you have 100% reads, all six drives will be used and
you'll have about 600 IOPS for both RAID 10 and RAID 5.
The worst case scenario is 100% writes. In that scenario, RAID 10's
performance will be cut in half (since each write goes to two drives),
so it will get 300 IOPS. RAID-5 will convert each write into two reads
followed by two writes, so it will get 1/4 the performance or about
150 IOPS. That's a pretty big hit.
Your actual read/write pattern will be somewhere in-between these two
extremes, but this is why RAID 10 is usually recommended for databases.
i.e very poor write performance (corresponds to my personal experience with RAID 5)
That guy seems to know what he's talking about, however I have no idea who he is. Let's see what some well-known experts have to say, Juan Loaiza (Oracle database's chief architect - so you might expect him to know a thing or two about databases and disk arrays - paper available on baarf.dk - see below) says:
Storage configuration does not have to be this complicated.
A simple, efficient, and highly available storage configuration is
possible. The basic idea of this configuration is to make extensive
use of striping across large sets of disks using a methodology that we
will describe later. To achieve high availability the disks should be
mirrored. We call this methodology S.A.M.E. SAME stands for Stripe and
Mirror Everything.
This is NOT RAID 5 (which has parity bits, which are costly) - in fact it means RAID 10 (or 1+0).
From Wikipedia:
RAID 1+0: (see: RAID 10) creates a striped set from a series of
mirrored drives. The array can sustain multiple drive losses so long
as no mirror loses all its drives
(another quote from the Loaiza paper):
The SAME configuration produces close to optimal performance for ALL
workloads:
The quote continues:
OLTP, Warehouse, and Batch. We believe that the SAME
configuration will become the predominant configuration for Oracle
databases. Oracle is working with leading storage vendors to optimize
and automate this methodology
So, Oracle wants to implement automatic RAID 1+0!
From here:
RAID 10 provides better fault resilience and “rebuild” performance
than RAID 01. Both array types provide very good to excellent overall
performance by combining the speed of RAID 0 with the redundancy of
RAID 1 without requiring parity calculations.
From here:
RAID 10 fault tolerance is more. On RAID 10, since there are many
groups (as the individual group is only two disks), even if three
disks fails (one in each group), the RAID 10 is still functional. In
the above RAID 10 example, even if Disk 1, Disk 3, Disk 5 fails, the
RAID 10 will still be functional. So, given a choice between RAID 10
and RAID 01, always choose RAID 10.
From here (a guy with a 60K rep!):
Unless your circumstances are exceptional, you should never use 0+1.
From here (the Canonical question on ServerFault! Appears to be the same guy as the above quote)
RAID 01
It provides no additional speed over RAID 10, but substantially less
redundancy and should be avoided at all costs.
Kevin Kline author of SQL in a Nutshell wrote here (in dba.stackexchange):
was surprised that in a write-heavy scenario RAID5 was over 3x slower
than RAID10 (it was 319% slower, to be specific). Your mileage may
vary according to the actual ratio of reads versus writes in your
scenarios.
Finally, on a humourous note, take a quick look here at baarf.dk (site in English) - it's the "Battle Against Any Raid F" (F = four/five and others).
Take a look at the paper by Cary Millsap concerning the real economics of RAID 5. The word "barf" in English means to get sick - I don't think the acronym was chosen by accident! :-) Seriously, there are good papers on this site (see Juan Loaiza above) and the people behind it are all serious Oracle practictioners although the "organisation" per se appears defunct.
Summing up:
Now, there are many people recommending hybrid configurations out there (logs on RAID X, data on RAID Y, OS on RAID Z, Server software itself on ZFS, something else on SSD... the list goes on (and on...). Don't get me wrong, I'm not knocking those who make these recommendations and I don't have time or expertise to check them all out (i.e. read benchmarks by people whose reps I trust), but it's worth remembering what Juan Loaiza wrote:
The SAME configuration produces close to optimal performance for ALL
workloads
Having said all of the above, I wouldn't put the OS or server software (upgrades and the like) on the same disks as my data and I would separate my data from my WAL/Redo/Undo.
RAID 5 is meant to be good for read heavy workloads - why not just use the file system plus vi or possibly Git as your database server? :-)
Finally, remember that for really serious systems, you need to have a disk array which supports hot-pluggable spares.
