Re: SSD + RAID

Itching to jump in here :-)

There are a lot of things to trade off when choosing storage for a
database: performance for different parts of the workload,
reliability, performance in degraded mode (when a disk dies), backup
methodologies, etc. ... the mistake many people make is to overlook
the sub-optimal operating conditions, dailure modes and recovery
paths.

Some thoughts:

- RAID-5 and RAID-6 have poor write performance, and terrible
performance in degraded mode - there are a few edge cases, but in
almost all cases you should be using RAID-10 for a database.

- Like most apps, the ultimate way to make a databse perform is to
have most of it (or at least the working set) in RAM, preferably the
DB server buffer cache. This is why big banks run Oracle on an HP
Superdome with 1TB of RAM ... the $15m Hitachi data array is just
backing store :-)

- Personally, I'm an SSD skeptic ... the technology just isn't mature
enough for the data center. If you apply a typical OLTP workload, they
are going to die early deaths. The only case in which they will
materially improve performance is where you have a large data set with
lots of **totally random** reads, i.e. where buffer cache is
ineffective. In the words of TurboTax, "this is not common".

- If you're going to use synchronous write with a significant amount
of small transactions, then you need some reliable RAM (not SSD) to
commit log files into, which means a proper battery-backed RAID
controller / external SAN with write-back cache. For many apps though,
a synchronous commit simply isn't necessary: losing a few rows of data
during a crash is relatively harmless. For these apps, turning off
synchronous writes is an often overlooked performance tweak.


In summary, don't get distracted by shiny new objects like SSD and RAID-6 :-)


2009/11/13 Brad Nicholson <bnichols@ca.afilias.info>:
> Greg Smith wrote:
>>
>> Karl Denninger wrote:
>>>
>>> With the write cache off on these disks they still are huge wins for
>>> very-heavy-read applications, which many are.
>>
>> Very read-heavy applications would do better to buy a ton of RAM instead
>> and just make sure they populate from permanent media (say by reading
>> everything in early at sequential rates to prime the cache).  There is an
>> extremely narrow use-case where SSDs are the right technology, and it's only
>> in a subset even of read-heavy apps where they make sense.
>
> Out of curiosity, what are those narrow use cases where you think SSD's are
> the correct technology?
>
> --
> Brad Nicholson  416-673-4106
> Database Administrator, Afilias Canada Corp.
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>