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.
17 March 2010
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.
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.
13 March 2010
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.
07 March 2010
A Kindred Soul
04 March 2010
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.
Subscribe to:
Posts (Atom)