A Production SQL Server goes SSD

As I have mentioned occasionally, SQL Server Central is good place to pick up information, even though I don't run SQL Server here. Today they have an article about moving Fusion-io cards into a production system, and the glitches they encountered.

Fusion-io no longer even refers to their cards as "SSD", since they're not connected on a standard I/O channel, and are not yet bootable (a special driver, not yet scheduled for *nix, is still not available for win*).

And, as usual, this attempt did nothing to refactor the databases, so it's a pure I/O strategy. It was still considered worthwhile, though.

Touching Me, Touching You

For years, and recently in my writings here and elsewhere, I've made the point that GUIs are inefficient and even inferior to the keyboard when input is shared with the keyboard. The iPad will now have the opportunity to prove that a computer like device can be run usefully and happily only on pointing.

Whether Stevie knew it or not, he gets to observe a watershed event with his own money.

Update:
Here's a page from the AnandTech Review. I love when I'm right.

Current News

A couple of articles came into view today, one hot off the presses and the other not so much.

StorageSearch is a site I visit fairly regularly; Zsolt pushes the envelope. His new article makes the case for gargantuan storage. I'm still not sure that capacity is the point of SSD, as I've written before.

The other is a story/press release about Unity Semiconductor. I found Unity some time ago, but haven't visited in a while. They're about building a better NAND substitute. I suspect that this bit of hardware will be more important than petabyte units. We'll see.

NoSql <<- No Brainer

The NoSql squad is on the loose again, therefore it is time once again to slay that particular dragon. Andy Oram, of O'Reilly fame writes about a recent NoSql conference (prior to it). The usual suspects are listed.

The hallmark (or carbuncle) of the NoSql "databases" is that they have no structured access, no transactional support, and no data reduction. You get all those, and more, with relational (sql, mostly) databases. What these NoSql (Oram's list: Cassandra, CouchDB, HBase, HypergraphDB, Hypertable, Memcached, MongoDB, Neo4j, Riak, SimpleDB, Voldemort) datastores do is just what files did with your grandfather's COBOL code; store data in an application specific format. You can browse through them at your leisure.

What they have in common is the use of key/value pairs for data. The proponents fail to comprehend that their "data" is just what an index is in a relational database. And it's nothing new. Back in the 1960's random access was supported by the "fully inverted file" paradigm. Here's what Joe Celko has to say ("Joe Celko's Data and Databases"): "In an inverted file, every column in a table has an index on it. It is called an inverted file structure because columns become files." Nothing new here, please move on. Gad, these young-uns persist in re-inventing square wheels.

SQL Server does SSD

For those who do SQL Server, SQL Server Central has begun a series on SSD. This first installment is dirt basic, but there may be something useful down the line. The other side of SSC, Simple Talk, is generally first rate. I'll be following it, and recommend it.

A Kindred Soul

Every now again I come across a site or blog which sounds like a kindred soul. Today is such a day. For the record, I found this linked to from the main PostgreSQL site. Enjoy the read.

Is That the Emerald City?

Imagine my surprise. I finally found a site that marries the relational database to SSD, RethinkDB. I just found it, so I'm still a bit giddy. Goody, goody, goody. There may be intelligent life on the planet Mr. Spock.