In response to "Fernando Hevia" <fhevia@xxxxxxxxxxxxx>: > > > David Lang Wrote: > > > > with only four drives the space difference between raid 1+0 and raid 5 > > isn't that much, but when you do a write you must write to two drives (the > > drive holding the data you are changing, and the drive that holds the > > parity data for that stripe, possibly needing to read the old parity data > > first, resulting in stalling for seek/read/calculate/seek/write since > > the drive moves on after the read), when you read you must read _all_ > > drives in the set to check the data integrity. > > Thanks for the explanation David. It's good to know not only what but also > why. Still I wonder why reads do hit all drives. Shouldn't only 2 disks be > read: the one with the data and the parity disk? In order to recalculate the parity, it has to have data from all disks. Thus, if you have 4 disks, it has to read 2 (the unknown data blocks included in the parity calculation) then write 2 (the new data block and the new parity data) Caching can help some, but if your data ends up being any size at all, the cache misses become more frequent than the hits. Even when caching helps, you max speed is still only the speed of a single disk. > > for seek heavy workloads (which almost every database application is) the > > extra seeks involved can be murder on your performance. if your workload > > is large sequential reads/writes, and you can let the OS buffer things for > > you, the performance of raid 5 is much better. > > Well, actually most of my application involves large sequential > reads/writes. Will it? Will you be deleting or updating data? If so, you'll generate dead tuples, which vacuum will have to clean up, which means seeks, and means you new data isn't liable to be sequentially written. The chance that you actually have a workload that will result in consistently sequential writes at the disk level is very slim, in my experience. When vacuum is taking hours and hours, you'll understand the pain. > The memory available for buffering (4GB) isn't bad either, at > least for my scenario. On the other hand I have got such strong posts > against RAID 5 that I doubt to even consider it. If 4G is enough to buffer all your data, then why do you need the extra space of RAID 5? If you need the extra space of the RAID 5, then 4G isn't enough to buffer all your data, and that buffer will be of limited usefulness. In any event, even if you've got 300G of RAM to buffer data in, sooner or later you've got to write it to disk, and no matter how much RAM you have, your write speed will be limited by how fast your disks can commit. If you had a database multiple petabytes in size, you could worry about needing the extra space that RAID 5 gives you, but then you'd realize that the speed problems associated with RAID 5 will make a petabyte sized database completely unmanageable. There's just no scenario where RAID 5 is a win for database work. Period. Rationalize all you want. For those trying to defend RAID 5, I invite you to try it. When you're on the verge of suicide because you can't get any work done, don't say I didn't say so. > Well, here rises another doubt. Should I go for a single RAID 1+0 storing OS > + Data + WAL files or will I be better off with two RAID 1 separating data > from OS + Wal files? Generally speaking, if you want the absolute best performance, it's generally recommended to keep the WAL logs on one partition/controller and the remaining database files on a second one. However, with only 4 disks, you might get just as much out of a RAID 1+0. > > now, if you can afford solid-state drives which don't have noticable seek > > times, things are completely different ;-) > > Ha, sadly budget is very tight. :) Budget is always tight. That's why you don't want a RAID 5. Do a RAID 5 now thinking you'll save a few bucks, and you'll be spending twice that much later trying to fix your mistake. It's called tripping over a dime to pick up a nickel. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@xxxxxxxxxxxxxxxxxxxxxxx Phone: 412-422-3463x4023 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
