Pundit for a Day

I've been reading Cringely for decades, and especially, along with most who read him it turns out, his annual predictions.  Since leaving his PBS gig, he hasn't been doing them.  Sniff.  But today he announced that he would do another, and invited his readers to contribute same.  Well.  Not one to turn my nose up at the possibility of 15 seconds of fame (he allowed that any reader predictions would be printed with attribution, which he sort of has to do) I offered up what follows.


Just one, sort of.

I've been banging a drum for SSD for a number of years, at least since Intel released their flash version (in true Enterprise, Texas Memory has been shipping DRAM parts for decades, but that's another story).

When STEC, Violin, et al started to build "Enterprise" flash SSD those few years ago, the notion they promoted was that SSD would replace HDD, byte for byte.  That didn't happen, largely IMO because the storage vendors (SSD makers and storage OEMs) couldn't develop a value story.

There always was a story:  the Truly Relational RDBMS (not the flatfile dumps common in Fortune X00 companies which moved their COBOL/VSAM apps to some database) is (so far) the only thing which exercises the real strength of the SSD:  random IOPS.  But to get that benefit, you have to have a BCNF (or better) database, and join the shit out of it.  The COBOL/VSAM and java apps devs don't think that way; they love their bespoke written loops.

So, what we've got now is SSD as front end cache to HDD arrays.  And SSD as game machine and laptop speed up.  Enterprise hasn't yet bought SSD as primary storage.  Hmmm.

In 2011, we will see that.  My guess is Oracle will be the lead.  It works this way.  Larry wanted Sun, not for java or MySql, but the hardware stack.  What Larry needs is that last group of holdouts:  IBM mainframe apps.  To do that, he needs a credible alternative to the z machine ecosystem. 

He has that now, but it ain't COBOL.  He needs a value story to get those COBOL/VSAM apps.  Whether you buy that Oracle is the best RDBMS or not, Larry can make the case, particularly since his competitors (save IBM) have adopted the MVCC semantic of Oracle. 

Pushing highly normalized databases, with most/all of the business logic in the database (DRI and triggers and SP) running on SSD makes for a compelling story.  But you've got to spend some quality time building the story and a POC to go with it.  Larry's going to do it; he hasn't any choice.  And it makes sense, anyway.

Remember, a RDBMS running on SSD is just an RCH from running an in-memory database.  You don't need, or want, lots of intermediate caching between the user screen and the persistent store.  Larry's got the gonads to do it.

Regards,
Robert Young

Hand Over Your Cash, or I'll Shoot

The recent events led me to consider, yet again, the SSD landscape.  The point of this endeavor is to promote the use of SSD as sole repository/persistence for BCNF databases.  The reasons have been written to a great extent.

Since beginning this endeavor, there has been a clear shift in storage vendors' marketing of SSD, whether this shift was proactive or reactive, I do not know.  These days, there is much talk of tiering and SSD as cache, less talk of SSD as whole replacement of HDD.  Zolt, over at storage search still promotes the wholesale replacement angle, but he seems to be in the minority.  I stopped over to copy the URL, and there's an interesting piece from 7 December worth reading, the column headed "MLC inside financial servers new interview with Fusion-io's CEO" (the way the site works, the piece will likely be hard to find in a couple of weeks, so don't tarry).

So, I reveried into the middle of a thought experiment:  what difference, if any, does it make whether an SSD is used as sole/primary store or as cache?  Well, I concluded that as cache, dirt cheap SSDs are just as good as Roll Royce SSDs (i.e., STEC, Violin, Fusion-io, and the like) from one angle, for the simple reason that the data on the SSD is really short-term.  From another angle, those cache SSDs had better by really high quality, for the simple reason that the data is churned like a penny stock boiler room, and SSDs need robust design to survive such a pounding.

The OCZ contract announcement leans toward the first answer; $500 doesn't buy much (if any) STEC SSD.  With error detection and hot swapping in the array, just pull them as they die and toss 'em in the shredder.  I'd unload any STEC shares real soon now.  There'll still be full-blown SSD storage for my kind of databases, but the American Expresses are more likely to go the front-end caching route (they've no stomach for refactoring that 1970's data), and for that implementation, commodity (this soon???) SSD is sufficient.

Like a Rolling Stone

One Hit (To The Body), STEC's and Compellent's that is, appears to have happened today.  And, I'll 'fess up, I never saw it coming.  OCZ, which had looked like a mix of prosumer/consumer SSD builder, is now shipping Enterprise parts.  Who knew???  And the stated price is $300-$500.  Either some OEM is willing to take a really big chance, or the cost of Enterprise SSD just went over a cliff.

Here's hoping for the latter.  Do you get it?  SSD for only 2 to 3 times the cost up front!!  Not the 10 times (or more) it has been.  And if the buyer is EMC????  STEC's corporate sphincter just got puckered.

The devices are the Deneva line, which they only announced back in October?  They run SandForce's SF-2000 controllers, and will be shipping by February!!  "Watson, the game's afoot."


As I was composing this missive, came word of the Compellent smash, and it's not a technical problem.  Compellent is an early adopter of STEC SSD.  Months ago, you may remember, a rival, 3PAR, was the hockey puck in a takeover game.  Compellent's share rose, a lot, in sympathy, and kept going.  Today's story has it that the company is going to Dell, but for substantially less than the share bid up by all those plungers.  Irrational exuberance strikes again.

Simple Simon Met a Pie Man

Another case of an interesting thread and an interesting post (mine, of course).  And, once again, it's from Simple Talk; on this thread.

Since you mentioned it, I'll beat the drum, yet again, for the necessary paradigm shift (in many places, anyway) which small keyboardless (in practice, even when one exists) devices. 

- Mostly, it was seeing that the best existing tablet and smartphone apps do simple, intuitive things, using simple intuitive interfaces to solve single problems.

As I've said here and elsewhere for some time, by (re-)factoring databases to high normal form (narrow tables, specifically), one gains a number of advantages.

1) such schemas are inherently candidates for UI generation, due to DRI
2) they're inherently robust, due to DRI
3) they're likely most of the way to being "pickable", which is what tablets do
4) given the ability to host high normal form databases on SSD, then building them to such a UI is feasible

Tablets have a long history, in fact; the iPad is nothing new, except for its venue.  Those doing VAR systems that work in warehouses have been writing to RF tablets for a couple of decades, and designing to high normal form (or, as often, working around its absence).

Pink Floyd

For those following that other story, what's Larry up to with Sun, I've been in the it's-about-taking-down-the-mainframe camp from the first nanosecond.  It's been kind of a small camp, amongst the Usual Pundit Suspects.  But today comes a bit of news along that line of thinking.

It's becoming clearer that Larry wants a database machine that can slurp up all those renegade IBM mainframe folks.  He knows he's got to get them off COBOL, somehow too, but first he needs a credible stack.  Another brick in the wall.

Tin Man

I've met the Tin Man.  Whilst looking for some MVCC/Locker debate I happened onto a Sybase Evangelist blog.  Kind of like what I do, but he gets paid for it.  Sigh.  May be soon. 

Anyway, this post is his paen to SSD, and this:
How big is your database?? **light bulb** Those same 10 SSD's get you a whopping 300-600GB of storage. You could just put the whole shooting match on SSD and forget the IO problems. Rep Server stable queue speed issues - vaporized.

Be warned, he makes the leap from Amazon sourced SSD to enterprise database storage (he doesn't mention STEC or Violin, for instance, but appears to be aware of earlier Texas Memory DRAM units); not really going to happen, so his arithmetic is off by a decimal point.  But otherwise, he and I are on the same page, especially with skipping the "cache with SSD" silliness, and just storing to SSD.  Schweeet.  And he knows from schmere.

Now, hold Dorothy's hand.

Thanks for the Memory

AnandTech has an article about 25nm flash today.  Well worth the read.  I'm not sure how this affects this endeavor.  On the one hand, the physics of smaller feature makes flash less worthy of enterprise storage.  On the other, the increased density supports greater over-provisioning to solve, maybe, the problems.  A classic engineering problem. 

I stopped by Unity Semiconductor to see if there's any news on shipping of their "new" device.  They include this article.  If it works, SSD has some calm seas and wind at its back.