Sometimes, reading other sites leads to "Ah, hah!!" moments, sometimes a chuckle, and sometimes a WTF!!! Here we have them all rolled into one.
The "Ah, hah!!" comes from this quote:
A newly graduated developer might perform database operations at the application layer instead of the database layer. This will put the processing on the application and not server. Further, this would also put the database at risk of data integrity issue and receive bad data.
A coder (I surmise) who gets data. How unusual.
The chuckle comes from the subtitle of the site: Simple solutions for complex problems. For those who haven't just fallen off the turnip truck, simple solutions to complex problems are inherently wrong. H. L. Menken is generally credited with the seminal quote, "For every complex problem there is an answer that is clear, simple, and wrong."
The WTF comes from an ad on the site (you might not see it, depending): Web programmers $10/hour. I wonder whether the author of the site even realizes how stupid this is. Pay bottom dollar, get bottom results. Mon dieu.
21 December 2009
18 December 2009
Fast Eddy Felson
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.
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.
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).
Subscribe to:
Posts (Atom)