Re: Solid State Disks for Databases

  • From: Nuno Souto <dbvision@xxxxxxxxxxxx>
  • Date: Wed, 28 Sep 2005 01:31:26 +1000

Murching, Bob apparently said,on my timestamp of 28/09/2005 12:32 AM:

question.  I think it's available with the standard fiber channel interfaces
and you can cluster them, LUNs, etc.  I think I might be able to get a
Ferrari F430 for the price of one.

Not needed. That's not where they are useful.

16GB of RAM.  Even the solid state vendors will admit that real-time,
on-the-fly caching is going to use expensive RAM more efficiently than a RAM
disk; this always has been the case.

The problem with that is you cannot apportion cache the way you can apportion disk. Not with standard run of the mill disk farms. It costs a lot to do that.


1. I can't afford bigger iron --> then how can I afford solid state disk?
2. I'm short on rack space in the data center --> these solid state boxes
are rather big!
3. I need highly parallelized, compute-dense blade clusters --> then 32GB
solid state disk systems start to look really small if it's servicing a
dozen blades, each of which can be outfitted with, say, 4GB of cache.

You forgot the obvious fit: 4- I need to write my redo logs as fast as possible, in something other than vague cache shared with all the other disks in my disk farm.

That is the sole place where a solid state disk in its current
technical form is darn useful.  To try and run an entire database
in one is ludicrous and entirely not the proposed target market.

The current size of solid state disks is perfect for redo and a much
better use of storage space than a 6Gb slice of a dedicated 250Gb
disk drive, mirrored/cached or whatever.


Smaller solid state, only 2GB?  I'm hard-pressed to come up with a reason
why it would be better than tossing a few gigs of RAM into the box or SAN
and taking advantage of all the great tools we already have at our disposal
to optimize the usage of that RAM.

Unless you are running the top of the line disk farm h/w, you cannot adequately control and apportion the RAM in that cache. Anyways, you are still stuck with using a smal slice of a large disk. And the top of the line of that disk farm defeats the cost advantage, that's for sure...


the cost. Having to mirror solid state disk would 10x more painful.

No need. It's backed up by battery and disk. The memory is the cheap component of the solid state disk, it can cheaply be mirrored. In fact, the devices I saw four years ago all had mirrored memory and backup disks in a standard single slot rack mount. Oracle redo writes positively flew on them.

Of course, Texas might have a different way of packaging it
which makes it more costly. Anything is possible in market-land.
:)

--
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxx
--
http://www.freelists.org/webpage/oracle-l

Other related posts: