When is fast not so fast? One of my pet sites, storagesearch, has a new article on SSD performance, with some historical background. Check it out.
Here is the money quote:
If repeat writes to the same small address range (same flash blocks) is interspersed with read operations (the play it again Sam scenario - which occurs in database tables) the performance outcome varies significantly between fat and skinny flash SSDs. A fat flash SSD may produce results which more closely follow the behavior seen in HDDs and RAM SSDs - as predicted by the write IOPS spec. But performance in most skinny flash SSD designs will collapse.
The meaning of skinny and fat is explained here. So, for the purposes of what this endeavor advocates, the fat should be on the fire.
18 December 2009
10 December 2009
Coal in Your Stocking for Christmas?
Could we be witnessing the rapid burnout of a star? A supernova of IT? STEC could be in serious difficulty. The latest news from Fusion-io, whom STEC management has dissed in the past, is a design in with IBM. Here's the announcement and IBM's. As I type, the share has fallen still further from my previous posting: into the $11's.
Why this is important: Fusion-io set out on a separate path, leveraging the PCIe connector, where STEC and storage rack vendors (EMC, for example) didn't. Early on in this endeavor, I pointed out that Fusion-io was adopting the Google paradigm rather than the mainframe/server paradigm of external mass storage. The mass of servers way rather than the mass of drive racks has other implications. In particular, what will database systems look like? The knee jerk reaction is: distributed. On the other hand, may be not in the way that has been before. Fusion-io still (they haven't changed their tune, so far as I know) is on the path to terabytes on the slot. For my beloved BCNF databases which are orders of magnitude more compact than flatfile/xml messes, that is perfectly fine.
Of note in the announcements is that Fusion-io mounts an additional NAND chip for data protection. Not only is STEC threatened, but so are all the storage rack vendors. To the extent that the PCIe vendors can mount so much SSD in the board, which is faster still, and the notion of a room full of servers rather than a room full of drives taking over... Too bad Fusion-io is still private; a few shares might make for a more comfortable, and early, retirement. For those who crave retirement, anyway.
Why this is important: Fusion-io set out on a separate path, leveraging the PCIe connector, where STEC and storage rack vendors (EMC, for example) didn't. Early on in this endeavor, I pointed out that Fusion-io was adopting the Google paradigm rather than the mainframe/server paradigm of external mass storage. The mass of servers way rather than the mass of drive racks has other implications. In particular, what will database systems look like? The knee jerk reaction is: distributed. On the other hand, may be not in the way that has been before. Fusion-io still (they haven't changed their tune, so far as I know) is on the path to terabytes on the slot. For my beloved BCNF databases which are orders of magnitude more compact than flatfile/xml messes, that is perfectly fine.
Of note in the announcements is that Fusion-io mounts an additional NAND chip for data protection. Not only is STEC threatened, but so are all the storage rack vendors. To the extent that the PCIe vendors can mount so much SSD in the board, which is faster still, and the notion of a room full of servers rather than a room full of drives taking over... Too bad Fusion-io is still private; a few shares might make for a more comfortable, and early, retirement. For those who crave retirement, anyway.
01 December 2009
More Testing
AnandTech has updated its SSD review. Have a wander over there, if you haven't lately (the piece is dated 17 November).
30 November 2009
He Who Rests, Rusts
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".
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".
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.
Subscribe to:
Posts (Atom)
