Thank God Almighty

As Dr. King said, we're free at last. AnandTech (and lots of other sites) are reporting on Korea and Samsung's new SSD initiatives. You should go off and read up on them. At your favourite site.

However, regular reader should note the list of quotes which open this endeavour, and that the first was the first and always will be the first. It's the most important, even though we're nearly a decade since it was stated.

While this is something relatively new, it is not on the 840 Evo, but as part of the summit today it is worth some discussion. The principle behind NVMe is simple -- command structures like IDE and AHCI were developed with mechanical hard-disks in mind. AHCI is still compatible with SSDs, but the move to more devices based on the PCIe requires an update on the command structure in order to be used with higher efficiency and lower overhead. There are currently 11 companies in the working group developing the NVMe specifications, currently at revision 1.1, including Samsung and Intel.

The first step, really, to file systems which assume flash. By the time we get there, flash may be replaced by some other form of NVM, but I don't think anybody will quibble.

Hello, Joe

In some of my more somber moments, I've whined that Joe Stiglitz has been conspicuous in his absence of late. And yesterday's Times didn't arrive. Fortunately Groklaw had an off-topic link (may be not so off topic, really) to his piece on Myriad, and how Myriad and the patent regime of the US is good for the few and bad for the rest.

Give Me a Minute

The June Fed (FOMC, Federal Open Market Committee, which sets the Fed Funds rate) meeting minutes (which they really aren't) have been posted (here's the wiki describing the FOMC). Given that the Fed's intentions have been roiling the economy since then, it is instructive to have a read. This is the sort of Black Swan event that gives quants the heebie jeebies: how to stuff the information into some logistic regression model, or such? Hehe. Policy always trumps data.

Phasers on Obliterate!!

Recent discussions about pair programming and cloud lead me to conclude that cloud, in particular, depends on a peculiar reality. The attractiveness of cloud, from a client point of view, is that one need not store inventory of hardware (on-line or off-line) to deal with (un-)expected peaks in demand. Cloud vendors, at least apocryphally, provide instant access (and de-access) to resources. In order to do that, of course, the cloud vendors have to hold the necessary inventory against demands of hundreds or thousands of clients. If said clients are Mom & Pop Shops, who've little buying power for hardware, then cloud vendors, with the aggregate demand with which to bargain, should be able to eke out a small profit on the delta.

But what about the steady state? Where the business will, presumably, be spending most of its life? In that circumstance, how does the cloud vendor keep its head above water? Well, near as I can tell, peaks in demand from half of the clients have to be exactly in phase with troughs in demand (or that "gentlemen, phasers on obliterate!!") from the remainder; two sine waves 180 degrees out of phase. Otherwise, cloud vendors, just like their clients previously did, will continue to add inventory resources as the organizations grow. If they don't grow, then they provide the cloud vendor with declining revenue, and the cloud vendor goes looking for a bigger cloud vendor to palm off clients. A rock and a hard place. Moreover, where's superior value add of a cloud vendor? Other than a box of parts, what do they bring to the table?

Who's Integrated and Who's Not?

Minyanville isn't a site I read with much frequency. There's a piece linked from Oracle's Yahoo! page that can't go unremarked. Tech press is so tech ignorant. I think it's because so much of tech press is made by freshers, who've no memory of tech history nor any evident reading of it. If something is new relative to yesterday, it must be new incarnate. Not often true.

So, in the piece, the author makes a big deal of Oracle's fully integrated offerings versus Salesforce.com's a la carte (or may be it isn't?) menu. Having been in the packaged software business for most of my adult life (not using Oracle, though), I've been on both sides of the vertical integrated package software world; as maker and buyer. What doesn't happen is that

[Intel and Oracle] both have a long history of over-serving their customers -- of selling comprehensive, high-performance products that almost never get used to their full potential.

That's not how it actually works. Yes, the vendor will have as many parts as it thinks it can sell profitably. But, no, those parts are not woven together as a single quilt. The clients do buy some core module (oft times described as some number of integrated modules, but that can't be disassembled). After that, it's a matter of adding what you need, if and when you need it. HR functions are most obvious. Most of the time the real sticking point is the semantics of the core: how does it do the accounting, how does it do the product assembly, and so forth.

Then, the author contradicts himself

Although the cloud possesses the aura of technological freshness, in many ways, it's a throwback to the days of mainframes, when computing was so expensive that sharing it was necessary. Today, the great recession has once against brought expense to the forefront, and raised difficulties for the old over-serving approach.

Sound familiar?? It should. It's been the driving theme of this endeavour from the beginning. Now, whether it makes sense to out-source such a business model isn't driven by the semantics, but by cost and security. Cloud providers can only make money (and the author asserts that they don't, yet) if they can acquire the hardware in greater bulk discount than their clients. For generic Mom & Pop clients, they likely can. For the Fortune X00, not so much. A private cloud is just the old glass house with 3270's, just longer wires. Even if cloud vendors target M&P by the thousands, being able to provision new resources in a snap of the fingers means the cloud vendor has the inventory on site. That costs money. Being able to spread the load to keep all the hardware loaded, but not overloaded, requires that usage spikes be uniformly distributed (with countervailing troughs) over some span of time and space. Also, not likely in the real world. Whether the continuing security breaches are just a flash in the pan, or a true issue remains to be seen. Given that EULAs are always in favour of the vendor, a backlash is inevitable.

The one lever that cloud has: explicit non-ownership of software. Most EULAs (without a source license), are just rental agreements, but without a lot of teeth. Whether real clients will accept rental with teeth has yet to be determined.

Moreover, the author fails to distinguish among the eras of computing:
- mainframe with terminal, where application code (COBOL/RPG/PL1 and files) is executed on mainframe (with some rudimentary editing on a dumb terminal, possibly)
- client/server, where application is partially/wholly executed on client and files stored on server (the engineering workstation on LAN)
- the *nix (and Windows, to a lesser extent) database (usually RDBMS, but not commonly relational schema) with VT-X00 terminal
- webby client/server, where the application is in a browser and is mostly executed on client; data is commonly in RDBMS but not relational
- post industrial computing, where much of "new" development is infotainment, sometimes coerced as business support; RDBMS, if used, is file image

To the extent that smartStuff is limited to using its smarts to manage its screen, we're back to mainframe semantics or *nix/database/VT-X00. As I've been arguing from the beginning. Then, the issue becomes whether we revert to 1960s COBOL (file storage) style mainframe development for applications, or move forward with RDBMS in Organic Normal Form™ as the basis. Angry Birds may make some people some money and attract the bulk of freshers for employment, but it isn't relevant to how Oracle Applications (and their presumptive replacements) are built. To replace an existing Oracle Application (using Oracle as universal surrogate for legacy applications) means having a superior (for some definition of "superior") industrial application. Oracle has been slurping up its clients (who wrote those verticals for end users) with abandon for about a decade. Does the world need yet another GL? Not if it's just a re-hash of the thousands made since 1960. So, Oracle buys its clients in the realization that new ones aren't clamouring at the door. Micro (corporate) growth with macro (economy) stagnation. And the freshers go off to make some other pointless iStuff app. Just repeating COBOL/VSAM structure won't be enough. Touch based, and therefore disaggregated data based, versions mean either leveraging ONF™ RDBMS or writing the equivalent in code/files from scratch. Today's news that Facebook is re-inventing relationalism is kind of quaint. The young-uns never know. I'll be a quid that, like nearly everything else on the net, it will soon turn into a porn dating mechanism.

Superman, Up in the Sky

A while back, in some venue (may be even here), I opined that the coder cabal is the apotheosis of destroyed productivity. That building Organic Normal Form™ relational databases on a $10K Xeon machine, at 1/10 the annual cost of a cowboy coder, is where the real productivity lies. If The Suits (ever the bureaurats, looking only to fatten their org chart) would only look past the ends of their noses. Fat chance.

Anyway, the $10K number was actually kind of old and arbitrary; I haven't been on the lookout for such a machine here. But then, looky here. AnandTech does a (Brit) look at a Supermicro quad Xeon machine. The nature of the test presented doesn't have much direct bearing on RDBMS, that's true. I spent some time at the Supermicro site, but didn't see price lists. However, one of the comments allowed as how the machine in question was £16K. So, a bit more than the $10K, but still.

Time For the Cattle Prod [update]

The transition to Organic Normal Form™, propelled by MultiProcessor/Core/Thread/SSD, hasn't been as seamless as I've hoped/predicted. More like Rory McIlroy's recent golf game. Ah well. But the truth will out, in truth.

Since I'm not a MS sort of guy for some time, I'm only recently aware of Hekaton. Boy howdy! Now, not by any means the first in-memory engine (or partial engine) from an industrial strength RDBMS (TimesTen/Oracle, SAP/HANA, and solidDB/IBM come to mind), but SS does serve a larger population of installs (that's speculative, since sources such as IDC charge a pretty penny for their data, although "According to Microsoft officials, 46 percent of the databases deployed worldwide are now SQL Server, and customers are running 300,000 SQL Azure databases in Windows Azure" [here]). The point, of course, is that if SS goes in-memory, the pressure to normalize goes up a tad, what with all those SMB OLTP systems (existing and under development) that benefit from minimum footprint supplemented by joins. This could be the straw and camel moment.

Here's hoping.

Here's a Microsoft Research page. While it doesn't push the normal form benefits of Hekaton, just have a look at that pix of the developers. THEY'RE OLD FARTS!!!!! Take that, Kiddie Koders. It generally helps one in making something that is truly new to know what, exactly, was the Olde Stuffe. Had the Kiddies paid attention, we might have been spared all things xml and NoSql. ISM/VSAM variants to the hilt.

"We had an 'aha' moment," Lomet recalls, "when we realized that a single table that maps page identifiers to page locations would enable both latch-free page updating and log-structured page storage on flash memory. The other highlight, of course, was when we got back performance results that were stunningly good."

Here's a hot off the presses report. Read it, and lick your chops. Note that FK constraints (but doesn't say whether FK can be defined for access path purposes; yes, there already exist RDMBS engines* that support such an option) aren't yet supported.

Or, as one of Red Gate's (my favorite SS/RDBMS site) bloggers put it:

My biggest disappointment with the initial version is that it does not support foreign key constraints or check constraints. For a database designer/developer, "let the application handle data quality" is like fingernails on a chalkboard.

Nice to know that some people vote for Abbie Normal.

So, half a loaf. But, I strongly suspect that FKs will show up soon enough; if only to have a sensible OLTP engine. After all, an RDBMS targeted for OLTP, as MicroSoft states, can't be truly serious without that.

Hmm. SSD to support buffer pools? I have to finally admit defeat and run Windows?? While I've always had a hankering for SS, I just can't abide Windows. Scylla and Charybdis.

[update]
* Informational constraints tell the database manager what rules the data conforms to, but the rules are not enforced by the database manager. However, this information can be used by the DB2® optimizer and could result in better performance of SQL queries.

here