I have been paying close attention to the recent SSD performance/price changes with a keen eye to server performance on various workloads and applications.
The real barrier is in the controller design, and IP surrounding that. All flash products with any amount of wear-leveling map logical addresses to physical flash addresses dynamically. An intelligent controller, with enough processing power and RAM (Intel's drive has 16MB of DDR SDRAM) and an intelligent design can translate ALL random writes into a sequential stream. With enough overprovisioning, the erasing and cleaning that goes on in the background will have very minimal impact. One thing many people will claim about a SSD is that the erasing and block management will get slower as the drive becomes more full. This is incorrect -- from the point of view of any block device it is always 100% full, it is not privy to the file system notion of 'free space'. Addresses are simply overwritten, which makes blocks that previously mapped to those addresses available for writing. By definition, every write is an overwrite.
This paper, is very enlightening:
http://research.microsoft.com/users/vijayanp/papers/ssd-usenix08.pdf
Given Intel's particular strenghts and engineering resources, its not a surprise that they are among the first to make a design like this (FusioIO seems to have solved the random write performance issue as well ?). But as the review you provided links to demonstrates, it is this IP that will provide the performance gains necessary for flash performance to be hands down better than all drives, for all workloads, all the time. It is the same IP that will provide the most longevity and reliability.
Also of note for others reading this thread, the review was for Intel's "mainstream" device, not the "enterprise" one. The enterprise one claims 3300 random 4k writes/sec and over twice the write throughput. I'm sure it will also cost twice as much for less capacity.
Of particular interest in the short term may be using cheaper, read-biased flash drives for ZFS L2ARC caches for a database -- it may be like running with a couple hundred extra gigs of RAM, but you can still use slow, big drives for mass storage. The price is prohibitive for putting your whole db on flash if it is not a small one, but this is not true if you're just talking about cache devices or xlogs or temp space.
http://blogs.sun.com/brendan/entry/test
The real barrier is in the controller design, and IP surrounding that. All flash products with any amount of wear-leveling map logical addresses to physical flash addresses dynamically. An intelligent controller, with enough processing power and RAM (Intel's drive has 16MB of DDR SDRAM) and an intelligent design can translate ALL random writes into a sequential stream. With enough overprovisioning, the erasing and cleaning that goes on in the background will have very minimal impact. One thing many people will claim about a SSD is that the erasing and block management will get slower as the drive becomes more full. This is incorrect -- from the point of view of any block device it is always 100% full, it is not privy to the file system notion of 'free space'. Addresses are simply overwritten, which makes blocks that previously mapped to those addresses available for writing. By definition, every write is an overwrite.
This paper, is very enlightening:
http://research.microsoft.com/users/vijayanp/papers/ssd-usenix08.pdf
Given Intel's particular strenghts and engineering resources, its not a surprise that they are among the first to make a design like this (FusioIO seems to have solved the random write performance issue as well ?). But as the review you provided links to demonstrates, it is this IP that will provide the performance gains necessary for flash performance to be hands down better than all drives, for all workloads, all the time. It is the same IP that will provide the most longevity and reliability.
Also of note for others reading this thread, the review was for Intel's "mainstream" device, not the "enterprise" one. The enterprise one claims 3300 random 4k writes/sec and over twice the write throughput. I'm sure it will also cost twice as much for less capacity.
Of particular interest in the short term may be using cheaper, read-biased flash drives for ZFS L2ARC caches for a database -- it may be like running with a couple hundred extra gigs of RAM, but you can still use slow, big drives for mass storage. The price is prohibitive for putting your whole db on flash if it is not a small one, but this is not true if you're just talking about cache devices or xlogs or temp space.
http://blogs.sun.com/brendan/entry/test
On Mon, Sep 8, 2008 at 4:12 PM, Greg Smith <gsmith@xxxxxxxxxxxxx> wrote:
If like me you've been reading all the flash SSD drive reviews that come out, you might have also noticed that the performance on write-heavy workloads hasn't been too far ahead of traditional drives. It's typically been hit or miss as to whether the SDD would really be all that much faster on a real OLTP-ish database workload, compared to a good 10k or 15k drive (WD's Velociraptor is the usual comparison drive).
That's over as of today: http://techreport.com/articles.x/15433/9
You can see what I was talking about above in their Database graph: under heavy load, the Velociraptor pulls ahead of even a good performing flash product (Samsung's FlashSSD), and the latency curve on the next page shows something similar. But the Intel drive is obviously a whole different class of SSD implementation altogether. It's not clear yet if that's because of their NCQ support, or maybe the firmware just buffers writes better (they should have tested with NCQ disabled to nail that down).
With entry-level 64GB Flash drives now available for just under $200 ( http://www.newegg.com/Product/Product.aspx?Item=N82E16820227344 , price is so low because they're closing that model out for a better V2 product) this space is really getting interesting.
--
* Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
