RE: Solid State Drives

It is likely that eventually the price per GB on a SSD will get close to that 
of a traditional drive.  However, it is also likely that the sizes available 
for the traditional disks will continue to be larger for quite a while.  So, my 
instinct is that you'll see a similar split as there was up until recently 
between FC and SATA disks.  On the high end, you had ~300GB 15k RPM FC drives 
for high-performance objects, and then for less-frequently used items you'd 
have 1TB SATA drives.

So, perhaps your high-performnace objects will go on 2TB SSDs, and your regular 
data will go on 8TB SAS drives.  

As far as database-level optimizations, read-ahead may still make sense on 
SSDs, simply because it will reduce the need to generate IOs to the storage 
array, even if those IOs no longer have any concept of locality.

I should get someone to donate to me some "smart" arrays with SSDs built in, so 
we can test this stuff.

Thanks,
Matt


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Mathias Magnusson
Sent: Sun 5/3/2009 5:38 AM
To: vishal@xxxxxxxxxxxxxxx
Cc: tanel@xxxxxxxxxx; dofreeman@xxxxxxxxxxx; Oracle-L
Subject: Re: Solid State Drives
 
I think we all can agree that the cost/benefit right now is hard to define. I'm 
guessing that thought advanced ILM there are som use on the few blocks in a 
database that gets the most activity.

Still the part of the OP's question I am most interested in, is the future 
vision. How will the database world change when the price of SSD matches that 
of harddisks? That day is sure to be here fairly soon and when that day comes 
there will be probably few reasons to buy new harddisks,

The SAN cache changed some of the impact distribution on disk had for some 
systems, the SSD will definately change a lot of things as all blocks on them 
are created equal. The time cost for random versus sequential read will 
probably not matter as much. My understanding is that all blocks are placed in 
a somewhat random fashion on an SSD and new writes makes the block move to a 
different physical location.

So does anyone have an idea for how old truths will change or even how 
databases will adjust their algorithms for a day when harddisks are no longer 
the cheapest way to store data? Or is the conclusion that SSD is a fad that 
will fade into history over time? I cannot see that, but it would be 
interesting to hear som arguments for it.  

Mathias
http://mathiasmagnusson.com
http://blog.mathiasmagnusson.com
http://photo.mathiasmagnusson.com
http://oradbdev.mathiasmagnusson.com



On Sun, May 3, 2009 at 10:36 AM, Vishal Gupta <vishal@xxxxxxxxxxxxxxx> wrote:


        Tanel,

         

        I would agree. SAN cache does a pretty good job, even with RAID-5 as we 
have it in our bank. 

         

        Since most of the data, most of time is getting written to memory (RAM) 
in SAN. And it offloaded to disk in the background by SAN. So database gets a 
success handshake as soon as data is written to SAN cache. And with combination 
of server RAM (i.e db cache) and SAN cache and RAID-5, reads are also lot 
faster. As Tanel, suggests idead should be to optimize your SQLs so they do 
less IO. But even if they cant, a full tablescan might get repeatedly served 
from SAN cache. 

         

        Only problem I see with SAN cache is, there is no resource scheduling. 
Its all shared. So if you have too many system on same SAN cache, then one 
rouge system can bring down the entire company's systems. I have seen that 
happening. If there is too much written to SAN cache and writes are coming fast 
and thick. Then SAN does not get time to offload this dirty cache to disk,and 
this write pending goes above your set threshold,  it starts throttling writes 
from all the sources. And we had a linux kernel where it eventually made all 
the SAN connected mount point read-only. OUCH.. Major downtime on all systems. 
Now linux kernels have been patches so that mount point does not become 
read-only under such conditions.

         

        But SAN administrators really needs the understanding of databases IO, 
and also needs to be contain busy system to their own front end ports (Fibre 
channel ports) and their own disk and controllers. 

         

        But still they don't have the ability provided by SAN to isolate cache 
for a particular system. Or ability to throttle only selected systems/FC ports. 

         

         

         

        Regards,

        Vishal Gupta

         

        From: oracle-l-bounce@xxxxxxxxxxxxx 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tanel Poder
        Sent: 01 May 2009 18:22
        To: dofreeman@xxxxxxxxxxx; 'Oracle-L'

        Subject: RE: Solid State Drives
        
         

        Once they get cheap and big then there would be a business case for 
them for regular shops.

         

        But right now, if you want to reduce the time spent waiting for 
physical reads in your database - one way is buy faster IO subsystem which SSD 
may give, another way is to just buy more memory for your server and do less 
physical reads. The same is with writes, consider whether its cheaper to 
buy/deploy/maintain the SSDs or just to have more write cache in your storage 
array (and again, if you buy more RAM into your server for caching read data 
then you can allocate even more of the storage cache for caching writes).

         

        So the question should be what's the most cost-effective option for 
achieving the result - reducing TIME spent doing physical IO. Given the 
write-caching of large storage arrays already in use in todays enterprises I 
don't think adding SSDs make sense from cost/performance perspective. Of course 
when the technology gets cheaper then the potential power savings and lesser 
drive dying rate will be another factor to consider.

         

        So my prediction is that, unless some other major new technology 
emerges in coming few years, SSDs will replace disk spindles for online 
"active" data just like (remote) disk spindles have replaced tape backups in 
some enterprises (btw I'm not saying that I like this approach entirely - tapes 
have the benefit of being physically disconnected from any servers, in a 
guarded safe in a bank in another city or so).

         

        In addition to backups, the disk spindles will still be used for 
archived data as well (lots of storage which is rarely accessed), they are 
faster than tape but cheaper per gigabyte than SSDs. Long term backups are kept 
on tapes, but some companies will completely throw away their tape systems to 
cut costs & complexity and keep all backups on disk spindles.

         

        After saying all that - currently I don't see much reason for buying 
SSDs for database solutions which are already deployed on mid/high-end storage 
arrays.

         

        --
        Regards,
        Tanel Poder
        http://blog.tanelpoder.com <http://blog.tanelpoder.com/>  

         

                 

                ________________________________

                                From: oracle-l-bounce@xxxxxxxxxxxxx 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Freeman, Donald
                Sent: 01 May 2009 16:09
                To: Oracle-L (oracle-l@xxxxxxxxxxxxx)
                Subject: Solid State Drives

                Has anybody given any thought to where we are going as SSD's 
get cheaper and bigger?   We've been going round and round at my shop with 
discussions about RAID, other disk allocation issues, fights over storage.  I 
mean we seem to spend a lot of time on that issue. I saw that IBM is testing a 
4 TB SSD.   I was wondering if you'd have to mirror that, What kind of 
reliability we would be getting.   No more RAID discussions?   I've heard there 
is a finite number of times you can write to it.  What's the upgrade path here?

Other related posts: