MySql and the death of RAID(feedblog.org)
feedblog.org
MySql and the death of RAID
http://feedblog.org/2007/06/06/mysql-and-the-the-death-of-raid/
3 comments
Now, I know this story has gotten a bunch of people's panties in a bunch. For a minute, ignore the RAID angle, hell - even ignore the RDBMS angle. IMHO, partitioning and replication is one of the cheapest and safest way to scale reads (and in some cases, writes).
It all sounds nice but my datacenter charges me $110 a month per U1 rack slot, making that famed "array of cheap disposable boxes" no so cheap in comparison to one beefy server with more cores, more drives, more RAM. I use software RAID 1 for reliability purposes.
With new quad core processors coming out from AMD I can see myself using 4x4 (16 cores) box with at least 32GB of RAM with My SQL DB sitting on one of those "solid state disks". This config should cost me no more than $3-4K and should be quite capable.
With new quad core processors coming out from AMD I can see myself using 4x4 (16 cores) box with at least 32GB of RAM with My SQL DB sitting on one of those "solid state disks". This config should cost me no more than $3-4K and should be quite capable.
Let me be a little more specific about what I mean -
I'm not saying that raid is bad, it has its issues, but it most certainly has its places. The issue that I see as most significant with raid is the "brain shut down" effect - i.e. once you know you're redundancy and performance is covered by RAID, you'll be less open to other possible methods that, while in no way mutually exclusive with raid, require a bigger picture perspective. One method that has shown to scale _extremely_ well is partition and replicate (and my point about ignoring rdbms's and raid in the article was to suggest that partition and replicate is a concept that is useful outside of outside of these domains).
Another point I want to clarify - I said partition and replicate is cheap. This statement is imprecise. Partition and replicate is cheap once you've reached the point where your thinking of spending $100k (to $1MM) on a single database instance.
In summary - I believe that it's wise to consider how you'd partition and replicate your app before you need to, because once it's needed, the pain you'll feel will be massive and (IMHO) unnecessary.
I'm not saying that raid is bad, it has its issues, but it most certainly has its places. The issue that I see as most significant with raid is the "brain shut down" effect - i.e. once you know you're redundancy and performance is covered by RAID, you'll be less open to other possible methods that, while in no way mutually exclusive with raid, require a bigger picture perspective. One method that has shown to scale _extremely_ well is partition and replicate (and my point about ignoring rdbms's and raid in the article was to suggest that partition and replicate is a concept that is useful outside of outside of these domains).
Another point I want to clarify - I said partition and replicate is cheap. This statement is imprecise. Partition and replicate is cheap once you've reached the point where your thinking of spending $100k (to $1MM) on a single database instance.
In summary - I believe that it's wise to consider how you'd partition and replicate your app before you need to, because once it's needed, the pain you'll feel will be massive and (IMHO) unnecessary.