Re: Spindles and big disks

I'm not entirely an expert with databases & disks ... but I've dealt a fair bit with speeding up disk accesses (and I've studied the principles behind it). Here's the deal: RAID will dramatically increase your throughput, of course. You have a lot of cache on your RAID controller, even better. You have a lot of cache on your HD, sweet. The more places you have cache, the less the system needs to wait for disks to spin around and the less the system needs to wait for writes to complete (the RAID controller guarantees a write is complete, even if it isn't yet).

So, with that in mind ... taking a RAID controller w/ 128-256MB of cache memory, 15,000+RPM drives with a huge chunk (32MB?) of cache on-board, and making sure that your bus throughputs are high enough to accomodate, you've minimized the impact that spindles & groups will have.

The philosophy, quite simply, is that drives are slow as mud. So, let's interact with the drives as little as possible, let's interact with the abstraction of the drives and the abstraction of read/write operations, using fast memory so that the system *thinks* that it's accessing some blazing fast storage medium.

Make sense?
Disclaimer: I'm not an expert, but this is what I've picked up along the way.

Regards,
Brice

KineticGuy wrote:

> I grew up on the philosophy that databases perform better with more spindles
> and by isolating hot areas to their own groups. This concept still makes
> sense to me.
>
> Now the minimum disk sizes available are 9 GB and hardware caching is the
> hot thing. What are folks doing with this issue when sizing new systems.
> If you have a 40GB database, it's getting harder to justify the costs for as
> many spindles versus the old 1GB - 4GB days.
>
> I'm interested in thoughts that people have on this.
Received on Thu Mar 09 2000 - 00:00:00 CST