Memory-based storage? Yes, please

Memory-based storage? Yes please, And I'm not talking about flash memory here; well, not in the way we usually use flash, at least. I wrote about this a long time ago: in-memory storage makes sense. Not only does it make sense now, but it's becoming a necessity. The number of applications taking advantage of large memory …

[asdf]

What no mention of the memristor? Sorry can't resist taking pot shots at HP on this topic.

[Steve Davies 3]

Only Violin?

What about the many other 'hot-stuff storage' that seem to get a mention/plug here almost every week?

can't leave them out can we eh?

[Mark 110]

Re: Only Violin?

Its a fair point. I have been starting to wonder for a while if El Reg is starting to just feed at the trough rather than Bite the hand. But then that PR at Violin may give amazing hea . . .

[asdf]

Re: Only Violin?

HP bet the farm (R&D wise) on the memristor and the Machine though and that is a significantly bigger farm than most of the other players. Ironic that the Machine if it ever does become anything but vaporware will only do so because of these other technologies. We will get another Duke Nukem game before we get memristors at consumer prices.

[Someone_Somewhere]

Cold-boot Attack

Thanks for the leg-up - made snaffling your crypto-keys/whatever else I find /that/ much easier.

[Anonymous Coward]

I always wonder why is not possible to manufacture RAM slower than (anytime) current standards but on the cheap. Slow as it could get it would always be faster than flash.

[Steve Chalmers]

What you see today is stepping stones on a long technology journey

Application performance many times, but not always, is really limited by the latency of writes to persistent storage. For example, neglecting the optimizations of the last few decades, the inherent transaction limit of an Oracle-like database is the latency of a log write, each of which must be persisted before the next begins.

This whole concept of persistent memory in servers is about making available to the application tools which have been available within disk arrays for decades, and as a result allowing the application to persist data far faster than can be achieved using traditional storage devices through traditional storage software stacks (both on the host and in the storage system). Evolving software, including application software, to figure out what hardware is optimal and how software can in practice use it optimally is a really hard (research) problem. There is great value in that goal, and also value in the intermediate steps we will be taking as an industry along the way.

Enrico is right, we should be paying a lot of attention here. But as each of us draws our own conclusions, let's not confuse the research aspects, with the technology competition to replace worldwide DRAM sales comparable to the GDP of a respectable sized country, with the stepwise spinoffs of those efforts coming to market now and over the next few years.

@FStevenChalmers

(speaking for self, works for Hewlett Packard Enterprise)

[Someone_Somewhere]

Is this

/really/ a superior solution to an obscenely large DRAM RAMdisk and frequent flushing of new/modified data to a standard SSD solution?

Or is it merely a solution to a problem that has already been solved by, oh, I don't know, just off the top of my head, an obscenely large DRAM RAMdisk and frequent flushing of new/modified data to a standard SSD solution?