Google's recently announced operating system to be, Chrome OS, is to support only SSD. Hallelujah?? Well, yes and no. The OS is designed to run on netbooks, with most data on the Google machine at the other end of the wire. Oh, and that's where the programs will reside, too. So, in such a limited venue, supporting only SSD makes perfect sense. The device is therefore fully solid state, and therefifth totally rugged; the most vulnerable part being the screen.
Whether this decision has much impact on SSD adoption at the datastore, not much, I'm afraid. But it does get the attention of OEM's. And to the extent that storage production moves more to SSD by units shipped, and thus lowering the price of SSD's globally, then that's a Good Thing. We, and I count you Dear Reader in that plural, have to educate the Pointy Haired Bosses to the benefit of SSD as a refactoring opportunity, not just as another storage option. Now, let's get out there with the pickets: "Down with Rust!!! Up with Sand!!! Yeah, Yeah, Yeah".
30 November 2009
25 November 2009
Fusion-io Ups the Ante, Gauntlet Tossed
Last week Fusion-io raised the bar considerably. While I don't normally quote much from sources, this time I can't resist:
Achieving a 1TB/s sustained bandwidth with existing state-of-the-art storage technologies requires close to 55,440 disk drives, 396 SAN controllers, 792 I/O servers and 132 racks of equipment. Fusion-io can achieve this same bandwidth with a mere 220 ioDrive Octal cards, housed in Infiniband-attached I/O servers running the Lustre parallel file system. This 1TB/s Fusion-io based solution requires only six racks or less than 1/20th the rack space of an equivalent, high-performance, hard disk drive-based storage system.
What's important about this quote is its specificity: .5% of the number of drives, and ancillary gear. The other important point is that Fusion-io adapted their PCIe cards to an external rack. The rackable folk (STEC in particular) won't have as easy a task of taking their drives to the slot. Whether the controller does the job of wear leveling and the like, only time will tell.
And then there's the air of mystery, "two presently undisclosed government organizations" are the buyers. Could it be CIA/NSA doing a real-time database??? Only The Shadow Knows.
Achieving a 1TB/s sustained bandwidth with existing state-of-the-art storage technologies requires close to 55,440 disk drives, 396 SAN controllers, 792 I/O servers and 132 racks of equipment. Fusion-io can achieve this same bandwidth with a mere 220 ioDrive Octal cards, housed in Infiniband-attached I/O servers running the Lustre parallel file system. This 1TB/s Fusion-io based solution requires only six racks or less than 1/20th the rack space of an equivalent, high-performance, hard disk drive-based storage system.
What's important about this quote is its specificity: .5% of the number of drives, and ancillary gear. The other important point is that Fusion-io adapted their PCIe cards to an external rack. The rackable folk (STEC in particular) won't have as easy a task of taking their drives to the slot. Whether the controller does the job of wear leveling and the like, only time will tell.
And then there's the air of mystery, "two presently undisclosed government organizations" are the buyers. Could it be CIA/NSA doing a real-time database??? Only The Shadow Knows.
14 November 2009
MySql is a Threat to Oracle
This past week, the Times, in one day, provided two really stupid stories. I wrote a screed, which they've not published (no surprise there), so here's the one for DrCodd. The background: they ran a story about why Oracle and Sun should or should not merge, and the reasons why the EU objections are wrong. Not directly about SSD, except that Oracle really needs Sun's hardware if it has a chance of stealing IBM's mainframe customer base; I suspect that SSD, either in real drive form or the faux form now on display, is integral to accomplishing that.
The objection by the EU rests on facts which neither today's, nor any other I've read in The Times, deign to tell the reader. First and foremost: MySql is *not*, repeat *not*, Open Source as that term is understood. From the beginning, MySql has held a dual license, one of which is Open Source. As MySql stands today, this minimalist version is used by lots of web site and amateur developers. This version is and can be used without being beholden to MySql/Sun/Oracle.
There is, however, the commercial license version. This version, as explicitly stated countless times by the original developers, was the source of funding the Open Source version. Oracle, as I understand it now, is not compelled to continue this largesse by the DoJ. Oracle could simply abandon the Open Source version of MySql.
It gets better. The heart of database software is known as the engine. MySql's original (and still the Open Source version) engine is primitive in the extreme. No serious database developer would use it for anything serious. It is not a threat to Oracle, or any industrial strength database.
But, then Oracle bought, and maintains, an engine which is syntactically equivalent to Oracle itself. It is called InnoDB. While InnoDB is Open Source in origin, it is maintained by a separate company (owned by Oracle), Innobase OY in Finland.
Here's where the potential conflict arises: before now, Oracle, through Innobase OY, had an arm's length contractual relationship with MySql in providing InnoDB for MySql. With the merger, Oracle *could* abandon InnoDB in MySql, and thus force users to take up Oracle database, since the SQL access to a MySql/InnoDB database matches Oracle, and not the SQL that would be used with Open Source MySql. That's why, in my estimation, the EU is concerned.
Oracle has reason to do so: MySql/InnoDB *is* a low cost threat to Oracle.
The objection by the EU rests on facts which neither today's, nor any other I've read in The Times, deign to tell the reader. First and foremost: MySql is *not*, repeat *not*, Open Source as that term is understood. From the beginning, MySql has held a dual license, one of which is Open Source. As MySql stands today, this minimalist version is used by lots of web site and amateur developers. This version is and can be used without being beholden to MySql/Sun/Oracle.
There is, however, the commercial license version. This version, as explicitly stated countless times by the original developers, was the source of funding the Open Source version. Oracle, as I understand it now, is not compelled to continue this largesse by the DoJ. Oracle could simply abandon the Open Source version of MySql.
It gets better. The heart of database software is known as the engine. MySql's original (and still the Open Source version) engine is primitive in the extreme. No serious database developer would use it for anything serious. It is not a threat to Oracle, or any industrial strength database.
But, then Oracle bought, and maintains, an engine which is syntactically equivalent to Oracle itself. It is called InnoDB. While InnoDB is Open Source in origin, it is maintained by a separate company (owned by Oracle), Innobase OY in Finland.
Here's where the potential conflict arises: before now, Oracle, through Innobase OY, had an arm's length contractual relationship with MySql in providing InnoDB for MySql. With the merger, Oracle *could* abandon InnoDB in MySql, and thus force users to take up Oracle database, since the SQL access to a MySql/InnoDB database matches Oracle, and not the SQL that would be used with Open Source MySql. That's why, in my estimation, the EU is concerned.
Oracle has reason to do so: MySql/InnoDB *is* a low cost threat to Oracle.
04 November 2009
Humpty Dumpty Had a Great Fall
Our bellwether company, STEC, reported last night; and boy howdy, was it bad. Not too surprisingly, this endeavor had been predicting less than wonderful news. The share dropped to below $16 in after hours yesterday, and this morning is a bit above that number as I type. The point of this endeavor isn't stock tips, of course, but the fortunes of Real World producers of SSD is of significance to what does matter: the transition to BCNF databases on SSD multi-core/processor machines.
The accounting for the 3rd quarter was what the analysts predicted. The news that has sent the share in the toilet is the revelation (which could have been discovered earlier) that EMC, which accounts for "90%" (according to one news report) of the ZeusIOPS demand, would stretch its current stock into 1st quarter 2010. This news pretty much contradicts what had been in the wind, that EMC was taking all the STEC SSD it could get.
Not surprisingly, the emerging news and analysis boils down to: SSD isn't replacing HDD in the enterprise at warp speed after all. I will gloat here. I had mentioned in earlier posts that the transition from HDD --> SSD had already morphed to HDD --> SSD+HDD. While none of the reports have explicitly stated this as the reason that EMC has enough SSD for the time being, such would be the rosier outlook.
The less rosy outlook is that the storage system business isn't going to expand at nearly the rate a growing economy warrants. Dum da dum dum. Dum.
Truth be told, my earlier surmise, that SSD multi-machines will be adopted more by the VAR networks where they control both the software and hardware as a package, remains my conviction. The enterprise is still populated by brontosaurs.
The accounting for the 3rd quarter was what the analysts predicted. The news that has sent the share in the toilet is the revelation (which could have been discovered earlier) that EMC, which accounts for "90%" (according to one news report) of the ZeusIOPS demand, would stretch its current stock into 1st quarter 2010. This news pretty much contradicts what had been in the wind, that EMC was taking all the STEC SSD it could get.
Not surprisingly, the emerging news and analysis boils down to: SSD isn't replacing HDD in the enterprise at warp speed after all. I will gloat here. I had mentioned in earlier posts that the transition from HDD --> SSD had already morphed to HDD --> SSD+HDD. While none of the reports have explicitly stated this as the reason that EMC has enough SSD for the time being, such would be the rosier outlook.
The less rosy outlook is that the storage system business isn't going to expand at nearly the rate a growing economy warrants. Dum da dum dum. Dum.
Truth be told, my earlier surmise, that SSD multi-machines will be adopted more by the VAR networks where they control both the software and hardware as a package, remains my conviction. The enterprise is still populated by brontosaurs.
31 October 2009
Dahling, You Have to Read This
Shooting fish in a barrel, and criticizing xml, are congruent. The difference is that shooting fish is a one step process, while dealing with the zits of xml is a life long ordeal. Thus, I've only made a few random comments. The effort to build a new coherent jeremiad simply didn't feel worth the effort.
Then I ran across this. While I think he gives xml too much credit, in that "documents" intended to be consumed into my beloved BCNF database really don't need the structure (metadata information). A csv file will do. Pascal has written about that years ago. He was right then, and he's still right.
What I find mind boggling is this quote:
It's pretty popular these days to kick XML, all the cool kids are doing it and they don't seem to discriminate between its 'good' purposes and 'bad' uses.
I guess I'm not lucky enough to live in his world, 'cause where I've been, xml-ness is still au courant. XML Spy, ACORD, and the like remain in control. I need a new life!!
Then I ran across this. While I think he gives xml too much credit, in that "documents" intended to be consumed into my beloved BCNF database really don't need the structure (metadata information). A csv file will do. Pascal has written about that years ago. He was right then, and he's still right.
What I find mind boggling is this quote:
It's pretty popular these days to kick XML, all the cool kids are doing it and they don't seem to discriminate between its 'good' purposes and 'bad' uses.
I guess I'm not lucky enough to live in his world, 'cause where I've been, xml-ness is still au courant. XML Spy, ACORD, and the like remain in control. I need a new life!!
29 October 2009
Double, Double Toil and Trouble
There's been a hurricane of consternation on the Yahoo! (and I strongly expect, other) message board for STEC, our resident poster child of high performance SSD. The share has cratered from its high ~$40 to ~$20 yesterday. Today it's up a bit. Message boards have some interest, since a small fraction of the stream is intelligent. No, I don't hold any STEC, nor do I care whether they get rich. I do want them, or a company doing what they do, to continue.
One piece of intelligence is reference to this blog, at IBM. It doesn't navigate very well, and I'm sure not going to regurgitate it here, except to say that IBM has, if this fellow speaks for the company, backed off somewhat from the PCIe (Fusion-io) approach and reverted to straight SSD; STEC according to what he has written. The posting of interest talks about why PCIe went away, and SAS drives came back.
OK, one quote, from the 18 Sep entry:
Another interesting side note can be seen when you add the areal density of silicon, which to this day has tracked almost scarily to Moores Law. If for example, the GMR [giant magnetoresistive] head had not been invented by Stuart Parkin, then we'd probably have had mainstream solid state drives in the mid 90's. If nothing else comes along to push spinning rust back to the heady days of 65-100% CAGR[compound annual growth rate], then by 2015 solid state density will overtake magnetic density - in a bits per square inch term.
Now, this is important. The transition from HDD to SSD has changed, based on public pronouncements from the vendors, since January of this very year. Up until then, the notion was that HDD arrays would be replaced by (smaller unit count) SSD (mirrored?) arrays. The higher cost of SSD would be mitigated by the lower unit count resulting from not requiring striping (and possibly, mirroring) units in the array. (Aside, and from refactoring databases to BCNF; thus jettisoning at least an order of magnitude of those bytes.) Now, the notion being promoted is "disk caching", with some small number of SSD fronting the existing HDD array. I'm still not convinced this makes much sense, but there you are. The major impact of this approach is to simply not deal with data bloat, and thus get maximum benefit from SSD, but to garner "good enough" improvement.
If we are headed to a cross over in data density (but not necessarily cost/bit), then preparing for, and building now, pure SSD systems isn't implausible. While I don't relish the "disk caching" approach as the end game, if it serves to jam a size 12 brogan in the door; I'll take it.
One piece of intelligence is reference to this blog, at IBM. It doesn't navigate very well, and I'm sure not going to regurgitate it here, except to say that IBM has, if this fellow speaks for the company, backed off somewhat from the PCIe (Fusion-io) approach and reverted to straight SSD; STEC according to what he has written. The posting of interest talks about why PCIe went away, and SAS drives came back.
OK, one quote, from the 18 Sep entry:
Another interesting side note can be seen when you add the areal density of silicon, which to this day has tracked almost scarily to Moores Law. If for example, the GMR [giant magnetoresistive] head had not been invented by Stuart Parkin, then we'd probably have had mainstream solid state drives in the mid 90's. If nothing else comes along to push spinning rust back to the heady days of 65-100% CAGR[compound annual growth rate], then by 2015 solid state density will overtake magnetic density - in a bits per square inch term.
Now, this is important. The transition from HDD to SSD has changed, based on public pronouncements from the vendors, since January of this very year. Up until then, the notion was that HDD arrays would be replaced by (smaller unit count) SSD (mirrored?) arrays. The higher cost of SSD would be mitigated by the lower unit count resulting from not requiring striping (and possibly, mirroring) units in the array. (Aside, and from refactoring databases to BCNF; thus jettisoning at least an order of magnitude of those bytes.) Now, the notion being promoted is "disk caching", with some small number of SSD fronting the existing HDD array. I'm still not convinced this makes much sense, but there you are. The major impact of this approach is to simply not deal with data bloat, and thus get maximum benefit from SSD, but to garner "good enough" improvement.
If we are headed to a cross over in data density (but not necessarily cost/bit), then preparing for, and building now, pure SSD systems isn't implausible. While I don't relish the "disk caching" approach as the end game, if it serves to jam a size 12 brogan in the door; I'll take it.
27 October 2009
Swimming the Amazon Upstream
News from the jungle. Amazon is now offering an explicit relational database cloud service, RDS. It is MySql 5.1, so calling it "relational" is a bit of a stretch, but it is some good news.
I had the temerity to suggest that they offer SSD storage as an explicit option, so that real database wonks can build real BCNF applications. Got back a personalized auto reply, which said that "An AWS representative will reach out as soon as possible to address your questions about cloud computing and Amazon Web Services." I am on tenterhooks.
I had the temerity to suggest that they offer SSD storage as an explicit option, so that real database wonks can build real BCNF applications. Got back a personalized auto reply, which said that "An AWS representative will reach out as soon as possible to address your questions about cloud computing and Amazon Web Services." I am on tenterhooks.
Subscribe to:
Posts (Atom)