

Beyond RAID - jbyers
http://www.codinghorror.com/blog/archives/001233.html

======
jbyers
This article advises the use of RAID in all servers:

"But on the server, RAID is a definite must."

I submit it as a warning to startups who value their time and money: treat
unqualified technology advice with skepticism.

RAID has costs in time and complexity. In some cases, you will spend that
money because the alternatives cost more. A write-heavy MySQL server is
constrained by IOPS. Ignoring SSD for a moment, the two ways to get more IOPS
are faster spindles and more spindles. This is why RAID 10 on 15K SAS disks
wind up in database servers. Once you have exhausted other solutions and are
truly IOPS-bound, the cost of adding expensive disks to your database server
is likely much less than the alternatives.

Let's take a case where RAID does not make sense. On our site, our webservers
are predominantly CPU bound. Aside from reading code and writing temporary
files, the only disk access on these servers is HTTP logs. Every night, we
sync the logs, process them, and store the on S3. RAID would at best save one
day's worth of logs in case of catastrophic disk failure. If we could not
tolerate the loss of even a few minutes of logs, there are a variety of
software solutions that would accomplish this goal without spending money on
RAID controllers and disks. Our MogileFS storage nodes also do not benefit
from RAID, where we save many thousands of dollars a month by pushing
availability up the stack into inexpensive software. (Brad and the Danga crew,
we thank you.)

------
michael_dorfman
Wow, a big week for Atwood-- first he discovers floating point arithmetic, now
RAID. Somebody wake me when he hits "recursion"...

