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