A Better Mousetrap

Here (scroll to 6 May) is an assessment of STEC in the SSD space. Not surprisingly, to me at least, is that Zsolt reaches the same conclusion I have: SSD vendors have to make the case for the device. Just saying that "it's faster" will never cut it unless (very low probability) and until NAND, or its successor, reaches physical density commensurate with rotating rust.

As this endeavor postulates, BCNF relational databases for transactional systems on pure SSD storage is the sweet spot for vendors. The "Tier-0" approach au courant with storage vendors only consumes a pittance of drives. I'm getting closer to volunteering to head STEC's marketing department.

iPad, There for I Yam What I Yam

The Apple vs. Flash situation has led to many threads on many sites asserting many points of view as What It All Means. I follow Seeking Alpha, came across this one. Which led me to concoct a reply, which is below, although I'd recommend reading the whole thread, as there are some insights in the comments.


[A commenter] got close to the root issue: the iPad (generically) means a complete semantic shift for applications, which shift came (but was largely ignored) with the first GUI. Those GUI's re-implemented the Menu Interface of VT-100/*nix/database applications (think, Progress, Unify, etc.). It was just pixels rather than characters. Most GUI users who use applications deeply switch to Hot Key navigation anyway, skipping the mouse.

What a true GUI demands is that all input is Pickable. This means that No Keyboard is the rule. This, in turn, requires a complete re-thinking of data semantics. The application data must be sliced and diced into bite sized pieces which can be iconized and presented to the user. The user must not be required to *produce input*, only choose input. This is a major shift. Given that GUI developers didn't do much to the semantics of applications during The Era of the Mouse, they've got a lot of territory to cross. The alternative is, as some have suggested, that legacy applications (and it's worth remembering that lots of Fortune X00 applications remain COBOL/VSAM mainframe ports, some with data transferred to RDBMS) will continue in the Corporation, just because "it still works". Whether anyone in the CTO/CIO offices will have the gonads to start over is a question, almost certainly, NO.


The relevance to this endeavour is as I have said many times before: the database controls the data, while the "terminal" just paints a pretty picture and takes input. An iPad-centric application must have easily pickable data, not dependent on keyboard (which is the way mouse-centric GUI's should have been defined in the first place) typing. This sounds, to me at least, to be a perfect fit for a BCNF database. Nicely sliced and diced into bite size morsels. I find it supremely ironic that a GUI device should be the final impetus for intelligent data design.

IBM Builds a Sand Castle

IBM is wriggling its little toesies in the Sand(Force). Here's an article and another, fresh off the presses, about IBM using SandForce controllers. Neither say which, if any, vendor supplied the SSD's. It could be that IBM built them in-house from parts. This one indicates that's just what they did.

What I like about the stories is that IBM made the announcement TPC-C benched. Not that a TPC-C database is necessarily fully normalized, but it brings the point home: SSD is about relational databases. Very cool. And about bloody time.

Do It Yourself SSDs: It Had to Happen

Zsolt does it again, with this article about a storage vendor cutting out the middleman. I, too, considered that likely, given that the value of an SSD is in the controller, while the NAND is nothing but commodity.

Here's the money quote (from the point of view of this endeavor):

Unlike SSD ASAPs - which are designed to accelerate hard disk arrays - the name of the game with the new Nimbus product line is to make it attractive for users to place all their critical IOPS intensive data into SSD.


What this implies for pure SSD versus SSD/HDD hybrids is not clear. Nimbus is, whether they know it or not, making the case for putting databases in SSD. They're a company I'll spend some time investigating. May be I can convince them they need a RDBMS Evangelist. Always loved the smarminess of that word.

Whichever way that works out, the SSD vendors have to be wondering, especially the "enterprise" variety, whether there's anything to be gained from bespoke controllers.

Too Little, Too Late

Out of the mouths of babes. I keep track of the PostgreSQL site, and today it has this to offer. And here's the money quote, from one of the comments:

My opinion is that - DB procedures should by developed by DB people , typical PHP/Java developer knows to little to create optimal DB queries.

Obviously, not a native English speaker, but his heart is in the right place.

PostgreSQL and SSD

I visit the PostgreSQL site pretty often, and yesterday there was a link to a post on Bruce Momjian's blog (he's a Big Wig in the PostgreSQL world) about SSD. I was moved to comment, and then today saw that AnandTech has just published a review of a new SSD. Herewith my next comment, as it's relevant to this endeavor and I'll assume that y'all don't visit Bruce as a matter of course.


Just for grins, and because it's timely (published today), here's the latest AnandTech SSD review: http://www.anandtech.com/show/3656/corsairs-force-ssd-reviewed-sf1200-is-very-good .

What's important about this review:
- it's for a SandForce 1200 controller, which is intended to be SF's vanilla retail controller
- it's really fast
- it uses no external DRAM cache, which is material to design decisions about how to build an SSD, which makes SF based SSD materially different from all others, retail or "enterprise"
- one can see the playing field of most retail SSD and top notch retail HDD in the tables

SSD are not yet commodity parts, unlike HDD. Evolution continues; hopefully so will decisions about how best to utilize them in RDBMS.

It's Hardware, Stupid

Vindication is comforting, even sweet. Sometime back, I postulated that Oracle had reasons for acquiring Sun, and said reasons were not those from the usual suspects/pundits. The reason is simple: Oracle is after the last significant market segment it doesn't currently hold, IBM's mainframe customer. For that, Oracle requires mainframe power machines, and Sun has such. Along comes Brian Aker at O'Reilly with his take on the buyout. TaDa, hardware. Schweeeeeeeet.