Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RAMCloud puts everything in DRAM

zdnet.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: RAMCloud puts everything in DRAM

#21

Post by stepcut »

jpadkins wrote: post #4
sshirokov wrote: post #3

I'm not exactly sure what's being invented here that doesn't exist already.

can you cite an example of when DRAM is used for persistent storage? I am not aware of any.

acid-state, http://acid-state.seize.it/, which was previously known as happstack-state, and before that HAppS-State, has been doing it since 2005 or so.

acid-state currently lacks replication/multimaster support, but happstack-state has had several experimental implementations of that as well.

acid-state is Haskell specific.. but that is part of the appeal. You can directly store fancy algebraic data structures with acid-state. You are not limited to a simple combination of records integers and strings (for example).

Re: RAMCloud puts everything in DRAM

#24

Post by jasonwatkinspdx »

sshirokov wrote: post #3

I'm not exactly sure what's being invented here that doesn't exist already.

1.) Reading the position paper should help you with that. It cites some prior literature. In particular the DeWitt paper should be a good jumping off point on citeseer or the like. For that matter, reading DeWitt's papers should cover a great deal of academia's exploration of novel database architectures.

2.) It's a position paper. It's not attempting to assert a novel invention from day one, it's staking a claim about the design space (and further that you should fund us to do research in this space).

3.) The project is ongoing, you can see some preliminary results on their wiki. Most notable are some details on very low latency RPC and very rapid recovery. The recovery work rediscovers the same essential prescription as bigtable but does so via a second sharding scheme, which I believe is novel. Whether it's better is open to debate.

Re: RAMCloud puts everything in DRAM

#25

Post by jasonwatkinspdx »

jasonwatkinspdx wrote: post #24
sshirokov wrote: post #3

I'm not exactly sure what's being invented here that doesn't exist already.

1.) Reading the position paper should help you with that. It cites some prior literature. In particular the DeWitt paper should be a good jumping off point on citeseer or the like. For that matter, reading DeWitt's papers should cover a great deal of academia's exploration of novel database architectures. 2.) It's a position paper. It's not attempting to assert a novel invention from day one, it's staking a claim abo…

Sorry if I seem cranky, but I'm damn tired of people doing drive by criticisms of "ALREADY BEEN DONE BRO" on hackernews, particularly when they clearly haven't even read the primary sources.

Novelty or originality are not the only requirements for noteworthiness. A great deal gets done confirming prior experience or making relatively modest and obvious evolutionary extensions of previously well known work.

Re: RAMCloud puts everything in DRAM

#26

Post by mikeryan »

to3m wrote: post #10

Is "DRAM" the new name for "RAM"? Anybody know why the change in terminology? In which circles is this standard?

I think in this case they're using it to explicitly call out that the RAM being used is volatile. If you first mentioned this theory to someone they'd probably assume you're talking about using NVRAM since it would survive a power failure.

Re: RAMCloud puts everything in DRAM

#27

Post by jasonwatkinspdx »

fleitz wrote: post #17

"Imagine a world where data layout doesn’t matter, where apps are optimized for sub-millisecond storage, where 100 byte I/Os are faster and just as efficient as 8KB I/Os. The architectural implications are huge and would take a decade or more to get our heads around." Umm.. I've worked with in memory data structures (who hasn't?) and yeah, layout DOES matter. Especially if your data structure is larger than a cache l…

Note, this is from a database literature perspective. The server doesn't need a complex storage management layer like most RDBMs. If the read/write latency is low enough, all it needs is object framing, and clients can pick their own more complex data models atop this.
Post reply on HN