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@xxxxxxxxxxxxxxx>: > 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
