Re: SSD + RAID

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: SSD + RAID
Дата
Msg-id 4AFDCA4C.7090302@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: SSD + RAID  (Brad Nicholson <bnichols@ca.afilias.info>)
Ответы Re: SSD + RAID  (Merlin Moncure <mmoncure@gmail.com>)
Re: SSD + RAID  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-performance
Brad Nicholson wrote:
> Out of curiosity, what are those narrow use cases where you think
> SSD's are the correct technology?
Dave Crooke did a good summary already, I see things like this:

 * You need to have a read-heavy app that's bigger than RAM, but not too
big so it can still fit on SSD
 * You need reads to be dominated by random-access and uncached lookups,
so that system RAM used as a buffer cache doesn't help you much.
 * Writes have to be low to moderate, as the true write speed is much
lower for database use than you'd expect from benchmarks derived from
other apps.  And it's better if writes are biased toward adding data
rather than changing existing pages

As far as what real-world apps have that profile, I like SSDs for small
to medium web applications that have to be responsive, where the user
shows up and wants their randomly distributed and uncached data with
minimal latency.

SSDs can also be used effectively as second-tier targeted storage for
things that have a performance-critical but small and random bit as part
of a larger design that doesn't have those characteristics; putting
indexes on SSD can work out well for example (and there the write
durability stuff isn't quite as critical, as you can always drop an
index and rebuild if it gets corrupted).

--
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com


В списке pgsql-performance по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Why age (datfrozenxid) in postgres becomes 1073742202 not zero after each vacuum of database.
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: SSD + RAID