Violin and Fusion separation lessening
With both suppliers becoming able to offer in-(flash)-memory databases the difference between them is diminishing.
Is it? Really?
This topic was created by Chris Mellor 1 .
These new announcements/rumors (in Violin's case) that Violin and Fusion-io can accelerate in-memory databases by bringing them into their storage platforms do make the suppliers look similar, and potentially superior to others... but only for that class of applications. It is clear that Violin and Fusion-io are interested in reaching further into the software stack, which is a net win if you're betting on differentiated software.
Still, I would wager that most enterprise datacenters are not focusing on in-memory databases as their biggest IT priority, with the exception of shops like high-frequency traders and some HPC environments.
Re: "With both suppliers becoming able to offer in-(flash)-memory databases..."
There is no such thing as an 'in-(flash)-memory database. That is because CPU cannot operate directly on Flash.
"In-memory database" means, "In RAM Memory Database". Any statement to the contrary is marketing malarky.
Ah, not so fast mister, not so fast. Violin has cut-through SW so app SW can read and write data to flash memory without going through the host O/S I/O subsystem. The database data is in what they call another tier of memory and not in a storage tier. It's in-flash-memory which is slower than RAM but it is in memory rather than in storage.
Fusion-io should I think be able to get roughly the same sort of advantage. So, granted it's not in (DRAM) memory but it is in (flash) memory and that's a helluva lot faster than it being in disk storage.
I rest m' case m'lud.
With all due respect Chris, this is just more malarky. No matter what layers of sw crap you put between the CPU and NAND Flash, NAND FLASH IS FUNDAMENTALLY A BLOCK DEVICE.
That means, regardless of where these snake-oil salesmen try to hide it, there will always be a Block-level IO subsystem hiding in there, somewhere.
Check with any computer engineer on this. CPU cannot use Flash like DRAM or SRAM, ever. Period. End of story.
Actually, this is not malarky.
On the Fusion-io side, they don't do any block access on the hardware side, everything is addressed via memory addresses. The block layer for them is all done in software at the OS side, but that software can be swapped out, or developed on your own.
They recently released an SDK with memory libraries/etc. so that you can actually transparently page to flash vs dram from your applications.
Check it out: http://www.fusionio.com/products/iomemorysdk/
-AC
from the looks of it FIO's octal tops out at 10TB for a single card. The cost of such a card makes it worth while to have a server that has a lot of horsepower, say something like a quad socket system that has, nearly a dozen PCIe slots, e.g. DL58G7 which could get 4x10TB cards(PCIe 16x), and a few more 1-2TB cards (PCIe 8x) cards in it at the same time.
Or go bigger with an 8-way DL980 -
http://www.fusionio.com/blog/-fusion-io-powers-new-hp-data-accelerator-solution-for-oracle/
I would think the distinction of the fusion method is you can use pretty much any server hardware you want - even blades (in HP's case anyways since they have FIO modules for their blades), and don't need to wait for the fully integrated stacks to emerge, get the added speed now (assuming you need it - I sure as hell don't!)
Also I'd assume it's easier to get up and going with Fusion - since you can start small(160GB), and grow more later.
Though fusion certainly has a lot more competition now than a few years ago!
Fusion offers a direct plug-in PCIe card solution.
Violin offers a direct plug-in PCIe solution. (Check their site, Each array can be direct attached to a single or multiple servers).
In Nate's example - You could have a DL580 with 4 10TB cards (not sure if you could add more due to power).
Or
you can add 10 Violin Arrays to a DL580 G7. ( 10 5TB Arrays or 10 10TB Arrays or 10 20TB arrays or 10 16TB arrays or 10 32TB arrays)
And each Violin array is fully hot serviceable - I was at Collaborate a few years back when one of the Violin Guys demoed this to some people from TMS....
As for in-memory databases (rumors aside), Oracle has been performing all of it's work in-memory for years. Just ask Mike Ault, he will confirm that storage, flash or otherwise is for only for DB persistence..
Maybe I have this wrong but would love some feedback.It seems that SAP/Violin looks more like the Oracle exadata path.Meanwhile Fusionio seems to be seeding the market for a more commodity based storage architecture that probagates the vsl software, hence the sdk.Does Violin have anything like the vsl?Many thanks.
Thanks.I just reviewed Violin's presentation (Goldick)at sss conference and it seems as though they want the specialty box with everything inside as the building block-platform rather than the commodity server box makers with the cut through OS inside theirs.I think if you review the evolution of DOS then the bottoms up commodity methods wins out.Any thoughts?