If you're of a certain age, "solid, man", has a certain meaning (if you go here, and open up the list and then go to the bottom. SolidFire is a company which claims to be building SSD in the cloud; somehow or other I got on the early announcement list.
According to their press section, they've been in business since January of this year. It'll be interesting to see whether they make the connection between the value of SSD and the value of the RM/SQL/RDBMS. Minimize footprint, wear SSD galoshes.
31 May 2011
24 May 2011
Do the Limbo Rock
There's been some whoopla recently about OCZ's latest drives, and the SandForce controller used. Today, AnandTech looks at the latest of the latest, the Agility 3. Of most interest to this endeavor is the background on NAND architecture.
What's it all mean, Mr. Natural? Well, with respect to Enterprise (or even SMB) systems, not much I expect. OCZ and SandForce remain, so far as I can determine, firmly in the consumer/prosumer territory. Until SF drives start showing up from a major vendor, of course (there's not been an announcement from SF, yet). I don't see that happening, what with the implementation of encrypted/compressed data in industrial strength databases. Workgroup/internal document storage, may be.
What's it all mean, Mr. Natural? Well, with respect to Enterprise (or even SMB) systems, not much I expect. OCZ and SandForce remain, so far as I can determine, firmly in the consumer/prosumer territory. Until SF drives start showing up from a major vendor, of course (there's not been an announcement from SF, yet). I don't see that happening, what with the implementation of encrypted/compressed data in industrial strength databases. Workgroup/internal document storage, may be.
05 May 2011
Mr. Wonka's Factory
Here's a post on simple-talk which was dormant for most of a month (it's down to the last place on the front page today), then got really popular the last few days.
The subject: cleavages; well no, but I've liked that line since Lou Gottlieb used it to introduce a song lo those many years ago. Well, may be, actually, in a manner of speaking.
The subject is database refactoring. The post and discussion started out blandly, but then opened up (cleaved, see?) that long festering wound of front-end vs. back-end design/development. Simple-talk subjects and discussions tend toward a coder perspective, I suppose because T/SQL is often germane to topics, so a certain amount of self-selection exists both for authors and readers.
The idea of refactoring a database, especially given the tripe espoused by the likes of Ambler (some of his stuff), has been hijacked by the kiddie koders. Refactoring, for a RDBMS means getting more normal. It doesn't mean twisting the schema to fit some single access path, a la IMS or xml (hierarchies). That's not why Dr. Codd made the effort. He made the effort because he saw the mess that IMS was making; he'd been there when IMS was released and devised the RM a couple years later. In other words, it didn't take a math guy very long to identify both the problem and the solution.
Now that we have high-core machines with SSD as primary datastore, we can implement BCNF (at least) schemas/catalogs with no worries about "let's denormalize for speed". Those days are truly history.
The subject: cleavages; well no, but I've liked that line since Lou Gottlieb used it to introduce a song lo those many years ago. Well, may be, actually, in a manner of speaking.
The subject is database refactoring. The post and discussion started out blandly, but then opened up (cleaved, see?) that long festering wound of front-end vs. back-end design/development. Simple-talk subjects and discussions tend toward a coder perspective, I suppose because T/SQL is often germane to topics, so a certain amount of self-selection exists both for authors and readers.
The idea of refactoring a database, especially given the tripe espoused by the likes of Ambler (some of his stuff), has been hijacked by the kiddie koders. Refactoring, for a RDBMS means getting more normal. It doesn't mean twisting the schema to fit some single access path, a la IMS or xml (hierarchies). That's not why Dr. Codd made the effort. He made the effort because he saw the mess that IMS was making; he'd been there when IMS was released and devised the RM a couple years later. In other words, it didn't take a math guy very long to identify both the problem and the solution.
Now that we have high-core machines with SSD as primary datastore, we can implement BCNF (at least) schemas/catalogs with no worries about "let's denormalize for speed". Those days are truly history.
03 May 2011
Get Offa That Cloud
On more than one occasion, I've criticized all things cloud, since I see cloud as a lowest common denominator storage approach. But then, this is based only on my experience with cloud-like provisioners over the last couple of decades. Well, turns out I'm not the only one, and some of these folks have as much fun with the silliness as I have. The thread is new, so keep track for further hilarity.
01 May 2011
Ruler of All I Survey
There's that old phrase, "master of my own domain", and it is particularly useful in relational databases. While working in the COBOL oriented DB2 world of Fortune X00, I was continually rebuffed whenever I suggested the use of check constraints. I had to sneak them into some of my lesser databases, but that was cool.
In addition to regular check constraints, there is the notion of domains. They're sometimes referred to as user defined types. Here's a Postgres based treatment. Interestingly, Postgres has better support than DB2; PG allows check constraints while DB2 doesn't. Once again, the author's make my point (admittedly, the point made by anyone who takes RDBMS seriously) that control of the data in the database, rather than relying on each application code. Bulk loads, with most engines, enforce constraints so batch data transfers are a breeze. Not to mention that client code can be in any convenient language. And that a smart generator can use domain/UDT definitions whilst doing its thing. I've said that before, I believe.
In addition to regular check constraints, there is the notion of domains. They're sometimes referred to as user defined types. Here's a Postgres based treatment. Interestingly, Postgres has better support than DB2; PG allows check constraints while DB2 doesn't. Once again, the author's make my point (admittedly, the point made by anyone who takes RDBMS seriously) that control of the data in the database, rather than relying on each application code. Bulk loads, with most engines, enforce constraints so batch data transfers are a breeze. Not to mention that client code can be in any convenient language. And that a smart generator can use domain/UDT definitions whilst doing its thing. I've said that before, I believe.
25 April 2011
He Ain't Superman
Back in the early days of java and the time of the dotcom bust, George Reese was a minor pundit/author (O'Reilly division) in the database part of the world. You can look up his stuff at O'Reilly or Amazon. Not much heard from since then. He would occasionally show up on the O'Reilly site. And he has again.
Here's his take on the Amazon fiasco. What's so intriguing about this missive is the Up is Down meme involved here. The Cloud meme has been promoted as a less: expensive, time, resource, attention answer to the Data Processing Problem, particularly for web sites. Reese spends his few thousand words telling us that the SLA is *our* responsibility, not Amazon's. Ditto for infrastructure design. Ditto for physical design. Ditto for just about everything. Well, you're not allowed RDBMS, but you didn't want that anyway, did you?
He spends all that ink telling us that we have to work around the fragility of Cloud provision, in order to utilize Cloud. And we can't do databases, because, well, Cloud just isn't quite up to that. Where, exactly, is the win for clients who care about their data? He admits that such services won't provision such that there is sufficient excess capacity to support the loss of significant resources. Kind of like what might happen if you ran your own datacenter, only worse.
What's most annoying about his missive is that he makes, nearly explicitly, the assertion that the storage method, Cloud, determines the nature of the datastore. Not only can you not have SSDs as primary store for a BCNF databases, you can't even have *any* sort of RDBMS if you use Cloud. Last time I checked, that's the tail wagging the dog. But knuckleheads who admire the Emperor's New Clothes typically ignore such conflicts.
Oh, and you really should go read the piece. The commenters have a field day with his silliness. Yum.
[UPDATE]
In my haste to get this in words, I neglected to explicitly state the objection to Cloud I (and others) hold: the value proposition for Cloud is that it enables organizations (even just the IT group on its own) to out source an unwanted responsibility at lower cost; don't do it yourself and save money. Reese's treatise, and the failure, deny the existence of that proposition. This, while I gather he doesn't get it, is kind of a Big Deal.
Here's his take on the Amazon fiasco. What's so intriguing about this missive is the Up is Down meme involved here. The Cloud meme has been promoted as a less: expensive, time, resource, attention answer to the Data Processing Problem, particularly for web sites. Reese spends his few thousand words telling us that the SLA is *our* responsibility, not Amazon's. Ditto for infrastructure design. Ditto for physical design. Ditto for just about everything. Well, you're not allowed RDBMS, but you didn't want that anyway, did you?
He spends all that ink telling us that we have to work around the fragility of Cloud provision, in order to utilize Cloud. And we can't do databases, because, well, Cloud just isn't quite up to that. Where, exactly, is the win for clients who care about their data? He admits that such services won't provision such that there is sufficient excess capacity to support the loss of significant resources. Kind of like what might happen if you ran your own datacenter, only worse.
What's most annoying about his missive is that he makes, nearly explicitly, the assertion that the storage method, Cloud, determines the nature of the datastore. Not only can you not have SSDs as primary store for a BCNF databases, you can't even have *any* sort of RDBMS if you use Cloud. Last time I checked, that's the tail wagging the dog. But knuckleheads who admire the Emperor's New Clothes typically ignore such conflicts.
Oh, and you really should go read the piece. The commenters have a field day with his silliness. Yum.
[UPDATE]
In my haste to get this in words, I neglected to explicitly state the objection to Cloud I (and others) hold: the value proposition for Cloud is that it enables organizations (even just the IT group on its own) to out source an unwanted responsibility at lower cost; don't do it yourself and save money. Reese's treatise, and the failure, deny the existence of that proposition. This, while I gather he doesn't get it, is kind of a Big Deal.
24 April 2011
Was A Cloudy Day
As regular readers know, I've not been a fanboy of anything Cloud. My reasons are less to do with security, reliability, and other mundane considerations; rather that Cloud represents lowest common denominator (race to the bottom) disk storage. As a means for storing family vacation photos, well, OK. I'd prefer to keep those on my own storage, but each to his own. But Cloud for serious storage, I've never been a fan. My Yellow Brick Road is paved with SSD running BCNF databases. Unless, and until, Cloud provisioners recognize that it ain't "about just bytes", I'll pass. Some times, if it's too good to be true, it ain't true.
Then Amazon jumped the shark.
Here's another take on the situation. This is from an experienced Cloud provider, of a sort. As he says, the Fortune X0 have been trying to provide a central storage solution for rather a long time, with little obvious superiority. It's worth noting that the IBM Service Bureau service goes back to, at least, the early 1960's. Cloud is neither new nor a walk in the park. I guess Amazon and its clients now know that.
The Service Bureau (and similar) were able to provide some semblance of service over leased lines. The notion that TCP/IP, with HTTP tossed in, over normal phone lines is sufficient is, well, immature. What was that you said? The Emperor has one fine set of threads. Yes, yes he does.
Then Amazon jumped the shark.
Here's another take on the situation. This is from an experienced Cloud provider, of a sort. As he says, the Fortune X0 have been trying to provide a central storage solution for rather a long time, with little obvious superiority. It's worth noting that the IBM Service Bureau service goes back to, at least, the early 1960's. Cloud is neither new nor a walk in the park. I guess Amazon and its clients now know that.
The Service Bureau (and similar) were able to provide some semblance of service over leased lines. The notion that TCP/IP, with HTTP tossed in, over normal phone lines is sufficient is, well, immature. What was that you said? The Emperor has one fine set of threads. Yes, yes he does.
Subscribe to:
Posts (Atom)