On 06/20/2012 10:51 AM, Michal Szymanski wrote:
We started to think about using SSD drive for our telco system DB.
> Because we have many "almost" read-only data I think SSD is good
candidate
for our task. We would like to speed up process of read operation.
Many read-only operations can be made as fast as possible just by
getting more RAM. SSD is only significantly faster than regular disk on
reads if the working set of data is bigger than you can fit in memory,
but you can fit it all on SSD. That's not as many workloads as you
might guess.
I've read post (http://blog.2ndquadrant.com/intel_ssd_now_off_the_sherr_sh/) about
> SSD which have write safe functionality and two drive are recommended
> Intel 320 and Vertex2 Pro. Both drive are rather inexpensive but both
using old SATA II.
Intel's 710 model is their more expensive one, but that's mainly due to
longer expected lifetime than speed:
http://blog.2ndquadrant.com/intel_ssds_lifetime_and_the_32/
I don't see a lot of need for a faster interface than SATA II on
database SSD yet. If you need the data really fast, it has to be in
RAM. And if it's so large that you can't fit it in RAM, you're likely
looking at random I/O against the SSD--where most are hard pressed to
saturate even a SATA II bus. Indexes for example can really benefit
from SSD instead of regular drives, but that's almost always random
access when you're in that situation.
There's not a lot of systems that are inside the narrow case where SATA
II SSD isn't fast enough, but similar performance per dollar SATA III
SSD is. Some of the PCI-E flash-based cards, like FusionIO's, can do a
lot better than SATA II. But they tend to use more flash in parallel
too, it's hard to get that much throughput out of most flash devices;
it's not just that they transfer to the host faster.
I'd build a prototype with whatever drives you have access to and try to
measure what you need here. I hate to see people jump right toward
leading edge SSD only to discover their real working set fits in memory
just fine, so it doesn't even matter. Or that the bottleneck is
somewhere else entirely.
--
Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support 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
