13 August 2009

Two steps forward (one step back?)

In order to reach nirvana, fully normalized databases blazing through joined rows, it is necessary that application users, hardware vendors, and those vendors' suppliers all be enamoured of SSD. The issue has always been: which end of the string is the head and which the tail. In normal life, one can't push a string, only pull it. This argues for the notion that users must demand SSD systems rather than vendors offering them unbidden.

It seems to be working out the other way. May be.

We're most of the way through earnings season, and some clues are now evident. STEC is, by all lights, the pioneer in SSD at the enterprise level. They've been working on these devices since 2005, and have only now had significant shipments. They have been qualified to EMC, HP, IBM, Compellent, Hitachi, Fujitsu, Sun (that we know about). They've announced a $120 million deal with one of these, assumed to be EMC, to ship starting 3rd quarter.

STEC continues to claim that they are alone as enterprise SSD vendor. Intel's X-25 parts are user PC oriented. Fusion-io's part runs through the PCIe slot, rather then in a separate storage array. Texas Memory Systems has been building SSD (with DRAM for most of the time; they now have NAND parts) for enterprise machines for years.

What's kind of interesting is that STEC has just announced MLC based parts since "...several of our price-sensitive OEM customers are now looking for SSD alternatives which only a true MLC-based SSD can deliver...". What makes this interesting is that until this announcement, STEC was only talking about its SLC parts. Note that the NAND chips are sourced, not built by STEC. Samsung is the likely vendor; in any case, the MLC chips, which were heretofor said to be inferior for enterprise SSD are now kosher. This sounds to me to be a retrenchment; the "enterprise SSD" market wasn't quite as big as thought, or not so price inelastic as thought or ...

The implication is that machine vendors are not flocking to SSD, which means that users are not either. SSD is the future, and the future is closer than it appears in the mirror, but for SSD to be widely (and wildly) successful, it has to be part of a refactoring of the supported datastore. SSD will never be price or data density competitive with spinning rust. Efficiency (an order of magnitude less data retrieved faster) is the big win.

EMC, IBM, and Compellent have reported, and gave guidance for 3rd quarter that isn't skyrocketing. Whether Sun will be serious in the hardware segment under Uncle Larry is still moot; I've bet that hardware is the reason for the purchase, but we'll see. If so, then STEC will benefit. In all for the near term STEC, Intel, Fusion-io, et al are not looking like saloons in a mining town.

Get out there and push for 3NF. It's the only way to fly.


Anonymous said...

I would really like to see how efficiency (for SSD's) can be achieved without being price and data density competitive with conventional hard discs.

Robert Young said...

The answer comes in two varities: conventional and not conventional.

Two conventional answers:

Use SSD as "Tier 0" storage ahead of the HDD, with the array controller moving hot data to SDD as needed. This makes it cheaper to use some SSD in place of lots of HDD in order to achieve a throughput level.

Use SSD in RAID 1. Thus 10,000 RAID 10 HDD get replaced by 1,000 (or so). No change in data store structure for either.

The non-conventional answer:

Replace massively redundant flat file data (stored in RDBMS anyway) with 3NF (or higher), which is what this endeavor aims at. Since joins no longer cost any more than denormalized sequential access, and pass an order of magnitude less data, one needs perhaps 100 SSDs.

The third aspect, common to all of the above, is the TCO argument based on lower direct power cost, and indirect power cost due to cooler running.

tikitodo said...

maybe the service of adobe reader repair tool better suits your needs? I have recently tested several data recovery applications and I think it is the easiest one