I'm going to bite the bullet, so to speak, and get an SSD for this machine and do some personal experimenting. I've been putting it off for a while due to: the time devoted to getting work (which is way too time consuming), the time needed to be a stock tycoon, and my less than stellar view of what's been available. What I want is a device that's under a grand, has enough capacity to simulate a real-world (commercial) system, and is a no brainer to install on ubuntu. I've long since lost interest in doing hardware installs just for laughs.
I think I've found what I want. It's the Fusion-io ioXtreme. It was reported to be shipping in July, but looking at the Fusion-io site, they're in sign up to be the first on your block to own one mode. Sigh. But the price, $895 for 80gig in a PCIe card, is in the proper ballpark, and it won't be rattling around in the machine. More than the X-25M, about the same as the X-25E, $$/gig anyway.
While I was wandering around the Fusion-io site, I came across this from July. Now, it doesn't read as though they went ahead and normalized the data, just moved it to the SSD. (It's a TPC-H database and likely some form of star/snowflake.) I can live with that; folks are still taking baby steps along the Yellow Brick Road. It does demonstrate, if one accepts the notion of validity of TPC benchmarks, that SSD can save money while being faster and less filling.
18 September 2009
17 September 2009
Blood in the Street
There be carnage out there. I've been keeping a periodic eye gazing at the SSD stocks (and the increasing number of privates), with STEC being the "acknowledged leader" in enterprise drives. So their PR always says. It is true that STEC was, if not the first, certainly early and often qualified. Their list includes EMC, IBM, Sun, Compellent, HP.
It's been a week since I looked at the stock (I spend much of my stock time tracking biotech; more money more faster), and to my wondering eyes do appear but a true crash. Last I looked the share was over $40. Today it closed at $31.53. Trust me, stock promotion is not a factor in this endeavor, but it is undeniable that the current state of SSD in the enterprise is because of STEC's efforts to make itself rich, which it has.
The management of the company has been singing the "ain't nobody can do what we do" song for the last couple years, and in the last 12 months has signed up with the aforementioned companies. All the while deflecting questions about the likelihood of other suppliers of SSD. I never bought it. This site has been tracking the SSD world for more than a decade; since before flash was even used. Spending some time there makes it clear that STEC isn't the only game in town, and never was.
So, what happened? Turns out that Pliant Technology released its version of enterprise SSD a few days ago, which prompted some of the analysts to reduce their opinions of STEC.
The reason all this matters is that having multiple credible sources of enterprise SSD (what that term means is still open to discussion) is better for real relational database implementations. Which is what this endeavor is really all about. The SSD aspect is merely the implementation detail that makes it all possible.
What's bad for the Wall Street casino players is actually good for folks who are working at building useful things, and not merely engaging in zero sum games with each other.
It's been a week since I looked at the stock (I spend much of my stock time tracking biotech; more money more faster), and to my wondering eyes do appear but a true crash. Last I looked the share was over $40. Today it closed at $31.53. Trust me, stock promotion is not a factor in this endeavor, but it is undeniable that the current state of SSD in the enterprise is because of STEC's efforts to make itself rich, which it has.
The management of the company has been singing the "ain't nobody can do what we do" song for the last couple years, and in the last 12 months has signed up with the aforementioned companies. All the while deflecting questions about the likelihood of other suppliers of SSD. I never bought it. This site has been tracking the SSD world for more than a decade; since before flash was even used. Spending some time there makes it clear that STEC isn't the only game in town, and never was.
So, what happened? Turns out that Pliant Technology released its version of enterprise SSD a few days ago, which prompted some of the analysts to reduce their opinions of STEC.
The reason all this matters is that having multiple credible sources of enterprise SSD (what that term means is still open to discussion) is better for real relational database implementations. Which is what this endeavor is really all about. The SSD aspect is merely the implementation detail that makes it all possible.
What's bad for the Wall Street casino players is actually good for folks who are working at building useful things, and not merely engaging in zero sum games with each other.
11 September 2009
Larry Finally Speaks, and.... I'm Right
For all of you out there who've been saying that Larry wants Sun for java or Solaris or MySql, here's what he said yesterday in the Wall Street Journal:
We're in it to win it.
IBM, we're looking forward to competing
with you in the hardware business.
Larry Ellison
How dare you all doubting me. I've been doing this for a long time. He wants to kill Armonk's mainframe business. He always has. (See 28 August for the most recent discussion.)
Update (15 September):
OK, so today Oracle/Sun announced the new Oracle Database Machine. Oracle had previously been building the Exadata machine on HP hardware. No longer. Of particular interest to the readers of this endeavor is this:
The Sun Oracle Database Machine also includes Sun's new FlashFire technology to cache 'hot' data for dramatically improved transaction response times and throughput.
So, what is FlashFire? According to Sun, it's their implementation ofSSD flash cache and system software for same.
From the PR:
You get ten times faster I/O response time and use ten times fewer disks for business applications from Oracle as well as third-party providers.
Larry's not interested in hardware. Nope. Armonk, you've got a problem.
We're in it to win it.
IBM, we're looking forward to competing
with you in the hardware business.
Larry Ellison
How dare you all doubting me. I've been doing this for a long time. He wants to kill Armonk's mainframe business. He always has. (See 28 August for the most recent discussion.)
Update (15 September):
OK, so today Oracle/Sun announced the new Oracle Database Machine. Oracle had previously been building the Exadata machine on HP hardware. No longer. Of particular interest to the readers of this endeavor is this:
The Sun Oracle Database Machine also includes Sun's new FlashFire technology to cache 'hot' data for dramatically improved transaction response times and throughput.
So, what is FlashFire? According to Sun, it's their implementation of
From the PR:
You get ten times faster I/O response time and use ten times fewer disks for business applications from Oracle as well as third-party providers.
Larry's not interested in hardware. Nope. Armonk, you've got a problem.
03 September 2009
Persistent Myth: Bandwidth is Infinite
There exists, still, the myth of infinite bandwidth. The myth exists in support of the notion that "web" applications can and should be just like desktop applications. But there is a problem: what is a desktop application? In the beginning, 1982, the IBM PC provided a standalone little computer, which was expected to be programed just like the 370, only for smaller problems related to the work of the individual.
That fairy tale came to an end with Lotus 1-2-3, which turned the PC into a toaster: an appliance which did some computing (itself done by programs written by professional assembly language programmers) upon some data entered, or made available, by the individual. Then came typing programs, later renamed word processing. The toaster syndrome was in full swing.
Then came Netware, and its ilk, to lead us to a kind of client/server environment. This is what "desktop application" really means these days: a local PC connected to a semi-local big computer. The VT-100 connected to a *nix database machine is the precursor to that.
AJAX, and so on, are attempts to take the 3270 behaviour of the web and turn it into the VT-100, albeit with pixels and graphics. In order to do that, the link to the outside world has to behave like fast RS-232.
So, today The New York Times runs this story. Infinite bandwidth, my eye. A bloody phone brings the net to its knees. When will people learn what your Mama told you, "what kind of world would we have if everybody behaved like you?". Nothing is infinite, stupdity likely excepted.
Update II:
There is the olde canard about tapes in a station wagon. Here is a new and even more amusing example.
Update:
In response to some questions from readers elsewhere, I'm led to pontificate further.
I missed out the obvious point (to me, anyway). There are two expenses in getting an image on the screen: computation and transfer of the image. With a 1982 desktop, what could be computed was memory mapped to the screen, so transfer was instantaneous (mostly).
With local networks and VT-100 to RS-232 to database, the screen is still a memory map in the server; all that goes over the wire is the characters in the screen image.
With GUI-ed screens in a local network, it's still manageable with Ethernet on wire.
With GUI-ed screens in the cell tower, not so much. Given that HTTP is about lots of request/response between the client (iPhone) and the server (Google machine, or whatever), the "virtual wire" gets overloaded. And will always be.
It's the same with building highways or subways or ...; traffic overwhelms infrastructure.
With an HTTP based internet, it's not possible to have a (mostly) passive (memory mapped) screen with all the computation at the server. Fact is, increasing computational power is a couple of orders of magnitude cheaper than I/O. And the web is about the least efficient form of I/O ever invented. It's not being used the way Cerf had designed it.
Abuse leads to breakdown, and the web is broke. The iPhone just makes it obvious, but not the reason.
That fairy tale came to an end with Lotus 1-2-3, which turned the PC into a toaster: an appliance which did some computing (itself done by programs written by professional assembly language programmers) upon some data entered, or made available, by the individual. Then came typing programs, later renamed word processing. The toaster syndrome was in full swing.
Then came Netware, and its ilk, to lead us to a kind of client/server environment. This is what "desktop application" really means these days: a local PC connected to a semi-local big computer. The VT-100 connected to a *nix database machine is the precursor to that.
AJAX, and so on, are attempts to take the 3270 behaviour of the web and turn it into the VT-100, albeit with pixels and graphics. In order to do that, the link to the outside world has to behave like fast RS-232.
So, today The New York Times runs this story. Infinite bandwidth, my eye. A bloody phone brings the net to its knees. When will people learn what your Mama told you, "what kind of world would we have if everybody behaved like you?". Nothing is infinite, stupdity likely excepted.
Update II:
There is the olde canard about tapes in a station wagon. Here is a new and even more amusing example.
Update:
In response to some questions from readers elsewhere, I'm led to pontificate further.
I missed out the obvious point (to me, anyway). There are two expenses in getting an image on the screen: computation and transfer of the image. With a 1982 desktop, what could be computed was memory mapped to the screen, so transfer was instantaneous (mostly).
With local networks and VT-100 to RS-232 to database, the screen is still a memory map in the server; all that goes over the wire is the characters in the screen image.
With GUI-ed screens in a local network, it's still manageable with Ethernet on wire.
With GUI-ed screens in the cell tower, not so much. Given that HTTP is about lots of request/response between the client (iPhone) and the server (Google machine, or whatever), the "virtual wire" gets overloaded. And will always be.
It's the same with building highways or subways or ...; traffic overwhelms infrastructure.
With an HTTP based internet, it's not possible to have a (mostly) passive (memory mapped) screen with all the computation at the server. Fact is, increasing computational power is a couple of orders of magnitude cheaper than I/O. And the web is about the least efficient form of I/O ever invented. It's not being used the way Cerf had designed it.
Abuse leads to breakdown, and the web is broke. The iPhone just makes it obvious, but not the reason.
28 August 2009
Larry, Darryl, or Darryl
Remember Larry, Darryl, and that other brother Darryl? The question, from our point of view, is: are we looking at Larry or one of the Darryl's? The question comes up again in an article in Fortune yesterday. The article argues that this is Darryl (one of them, anyway) we're dealing with, the one who cares only about software.
What's interesting is that among the commenters (by my count, the heavy majority agreeing with my thesis that Sun's value is the hardware business) is this link. In sum, Larry is calling IBM/DB2 out into the street for a gunfight. Which is the sheriff and which the bad guy?? Depends on which coast you live, I guess.
Larry has known for a long time that Oracle is faster than DB2, in the arenas he cares about. And that it is better adapted to the web world.
As I've said a few times: Larry has always wanted to bury the 370. With Sun's hardware business, he now has the equivalent of IBM's infrastructure. They've had that infrastructure, in one form or another, since the mid 1950's when Univac took months to decide on a name for their machine. That infrastructure has always been based on CPU's, files, and COBOL (on the mainframe, DB2 is just a veil over VSAM, which is one reason Oracle is a dog there; the notion that the 360 could do the full circle of computing from scientific to business didn't last very long ending with an early 370 one-off - it's a COBOL machine). Larry now has an infrastructure based on CPU's, a database, and java. IBM is facing the first threat to its mainframe cash cow, ever. Armonk, you have a problem.
What's interesting is that among the commenters (by my count, the heavy majority agreeing with my thesis that Sun's value is the hardware business) is this link. In sum, Larry is calling IBM/DB2 out into the street for a gunfight. Which is the sheriff and which the bad guy?? Depends on which coast you live, I guess.
Larry has known for a long time that Oracle is faster than DB2, in the arenas he cares about. And that it is better adapted to the web world.
As I've said a few times: Larry has always wanted to bury the 370. With Sun's hardware business, he now has the equivalent of IBM's infrastructure. They've had that infrastructure, in one form or another, since the mid 1950's when Univac took months to decide on a name for their machine. That infrastructure has always been based on CPU's, files, and COBOL (on the mainframe, DB2 is just a veil over VSAM, which is one reason Oracle is a dog there; the notion that the 360 could do the full circle of computing from scientific to business didn't last very long ending with an early 370 one-off - it's a COBOL machine). Larry now has an infrastructure based on CPU's, a database, and java. IBM is facing the first threat to its mainframe cash cow, ever. Armonk, you have a problem.
24 August 2009
A Bird on the Plate is Worth Two in the Cloud
There is a report today which amounts to a small, tiny, fledgling crow. Yummy, lightly saute'd with a good chianti.
It is a discussion of Clouding with SSD. As I have talked about here, I never expected Clouding to go SSD, just because the allure of Cloud is cheap and dirty. SSD is neither of those. Although, the justification given in the article is not the nirvana I have discussed, BCNF databases, but simple brute force speed with existing bloated data.
The discussion is also not a vindication of STEC, the loudest (well in some parts of the world, anyway) proponent. In fact, they talk about PCIe form factor, and that is in the wheelhouse of Fusion-io. My suspicion that the distributed machine with attached SSD in the PCIe slot will be at least as important as massive arrays of the EMC/IBM/Sun style looks to be getting stronger. Of course, it too could end up being a bit feathery in a few months.
The nature of the discussion is in terms, not of open Clouds (Amazon, et al), but of MySpace and the like. In other words, providers of Cloudy stuff to their own users. Who happen to want to store their data off-site. To me, that isn't quite what Cloud means, but redefining words to fit reality is characteristic.
I guess you can't have everything, but it does amount to a foot in the door. In time, the smart database folks will see the opportunity to have their cake and eat it too: SSD serving BCNF data will always be faster than serving the un-normalized stuff.
Another couple of steps forward.
It is a discussion of Clouding with SSD. As I have talked about here, I never expected Clouding to go SSD, just because the allure of Cloud is cheap and dirty. SSD is neither of those. Although, the justification given in the article is not the nirvana I have discussed, BCNF databases, but simple brute force speed with existing bloated data.
The discussion is also not a vindication of STEC, the loudest (well in some parts of the world, anyway) proponent. In fact, they talk about PCIe form factor, and that is in the wheelhouse of Fusion-io. My suspicion that the distributed machine with attached SSD in the PCIe slot will be at least as important as massive arrays of the EMC/IBM/Sun style looks to be getting stronger. Of course, it too could end up being a bit feathery in a few months.
The nature of the discussion is in terms, not of open Clouds (Amazon, et al), but of MySpace and the like. In other words, providers of Cloudy stuff to their own users. Who happen to want to store their data off-site. To me, that isn't quite what Cloud means, but redefining words to fit reality is characteristic.
I guess you can't have everything, but it does amount to a foot in the door. In time, the smart database folks will see the opportunity to have their cake and eat it too: SSD serving BCNF data will always be faster than serving the un-normalized stuff.
Another couple of steps forward.
18 August 2009
It was a Cloudy day, not a Sun was in the sky
Well, mangled Paul Simon a bit there, but this tid bit (via O'Reilly) from one Carl Hewitt set off the "The Thought Leaders Have Finally Figured Out the Obvious" bell:
As Jim Gray noted in "Distributed Computing Economics" (MSR-TR-2003-24) there is a growing imbalance between the computation power of billions of cores in aggregator datacenters and the relatively feeble fiber optic communications coming out of aggregator datacenters. This problem has now become so severe that Amazon has been forced to introduce a commercial service that lets users of their cloud import and export data through the post--as in, put it on storage devices and ship it by land, sea, or air.
For those who haven't been following along, I am among those who've been calling bullshit on the whole "we'll put our data in the (Amazon/Google/Microsoft/Grace L. Ferguson) cloud, save lots of money, and not have to worry about the annoying data any more" crowd. One needs to consider the bait and switch tactic of hucksters. Just because Google's motto is "don't be evil" doesn't mean they aren't. They are young and naive, and quite greedy. Their corporate clients are just greedy, and generally stupid. Witness the meltdown they have caused.
It used to be that business schools taught from a prime directive: don't buy (or outsource, same difference) your core competence. The same is true of your data. It is the life blood of your business (or life, if you are just a person). The dumbest thing you can do is hand it over to "the others". There will be hell to pay for those that do.
Read the article, and the comments. Some are intelligent, others very much less so.
An Update:
here is today's next step along the way to dissipating the Clouds so we have just the sky. The argument boils down to what those of us who were around when Service Bureaus (the real first one was created before my time by IBM) were all the rage: you can't have it both ways. You can't have interchangeable resources and anything like performance and security specific to each client. They all have to accept lunch as "Cheeseburger, Cheeseburger, no Coke, Pepsi", no hot dogs or quiche. And Cloud will fail for that reason. Well, it is failing in the sense that those who would be providers continue to backpedal. And they will keep doing it. Suits are such knuckleheads. How DID they get to make decisions?
Update II:
TheStreet.com has a story on 3 September about Boeing. Toward the end is this:
As far as the extensive 787 program outsourcing to suppliers, [CEO Jim] McNerney was asked whether he would do it the same way again. He said he would not.
As Jim Gray noted in "Distributed Computing Economics" (MSR-TR-2003-24) there is a growing imbalance between the computation power of billions of cores in aggregator datacenters and the relatively feeble fiber optic communications coming out of aggregator datacenters. This problem has now become so severe that Amazon has been forced to introduce a commercial service that lets users of their cloud import and export data through the post--as in, put it on storage devices and ship it by land, sea, or air.
For those who haven't been following along, I am among those who've been calling bullshit on the whole "we'll put our data in the (Amazon/Google/Microsoft/Grace L. Ferguson) cloud, save lots of money, and not have to worry about the annoying data any more" crowd. One needs to consider the bait and switch tactic of hucksters. Just because Google's motto is "don't be evil" doesn't mean they aren't. They are young and naive, and quite greedy. Their corporate clients are just greedy, and generally stupid. Witness the meltdown they have caused.
It used to be that business schools taught from a prime directive: don't buy (or outsource, same difference) your core competence. The same is true of your data. It is the life blood of your business (or life, if you are just a person). The dumbest thing you can do is hand it over to "the others". There will be hell to pay for those that do.
Read the article, and the comments. Some are intelligent, others very much less so.
An Update:
here is today's next step along the way to dissipating the Clouds so we have just the sky. The argument boils down to what those of us who were around when Service Bureaus (the real first one was created before my time by IBM) were all the rage: you can't have it both ways. You can't have interchangeable resources and anything like performance and security specific to each client. They all have to accept lunch as "Cheeseburger, Cheeseburger, no Coke, Pepsi", no hot dogs or quiche. And Cloud will fail for that reason. Well, it is failing in the sense that those who would be providers continue to backpedal. And they will keep doing it. Suits are such knuckleheads. How DID they get to make decisions?
Update II:
TheStreet.com has a story on 3 September about Boeing. Toward the end is this:
As far as the extensive 787 program outsourcing to suppliers, [CEO Jim] McNerney was asked whether he would do it the same way again. He said he would not.
Subscribe to:
Posts (Atom)