Mods please update title to reflect year (2009). Thanks!
RAMCloud Project
21–30 of 52 posts
Re: RAMCloud Project
#22Re: RAMCloud Project
#23Re: RAMCloud Project
#24> Durability: RAMCloud replicates all data on nonvolatile secondary storage such as disk or flash, so no data is lost if servers crash or the power fails. How does this work if someone is doing multiple sequential writes? Doesn't backup-ing to disk take a lot longer than writing to _RAM_ meaning some writes could get lost?
You can distribute writes over multiple disks.
Re: RAMCloud Project
#25Earlier quoted context omitted.
Sure, but the URL is for Atlassian.net
They just host the site, it is their wiki product called Confluence. The same way Github hosts pages at github.io but has nothing to do with content that people host there.
Oh, I know, I administer Confluence, Jira and Bitbucket. Bar from bitbucket, the other two hosted versions are woefully slow. Don't get me started about the Jira Calendar.
If they're blogging about some tech, maybe they need to dogfood that first.. especially when it's due to performance
Re: RAMCloud Project
#26Mods please update title to reflect year (2009). Thanks!
It's still under active development afaik.
Edit: Double checked, and it is - somewhat - for sure. Including "2009" in the title would be misleading.
Re: RAMCloud Project
#27Is this still maintained? It's a really cool project, it's just so insanely fast. I once implemented a MariaDB storage engine that used RAMCloud for storage, and it was an eye-opening experience. With blazingly fast reads and writes, latency was the number one performance issue for us.
I think it is. I regularly receive digests from the mailing-list.
Re: RAMCloud Project
#28How does it replicate all the data on disk or flash while maintaining the write latency of DRAM? I'm thinking there must be a delay during which loss of power will result in loss of data that was acknowledged as written. Is this something that RAMCloud overcomes in a novel way, or is the answer simply that the data is replicated across many nodes? How about the problem of raw bandwidth? If you keep sending writes to…
Not knowing anything about how the project works, they state their read latency is on the order of 5us and write latency is on the order of 15us. On this synopsis, they also mention that one mechanism they deal with is scale. So, I think your guess correct in that they likely replicate writes across multiple nodes. Then if any single node goes down, they still have a valid valid for a given key. Writes could then be persisted to disk asynchronously.
Re: RAMCloud Project
#29Would be interesting to know how this compares/contrasts with Apache Ignite.
Re: RAMCloud Project
#30A cool tiny bit of trivia about RAMCloud: that's from this project that the Raft consensus algorithm emerged! (https://raft.github.io/raft.pdf)
Right now, I think that the algo is used in RAMCloud via LogCabin (https://github.com/logcabin/logcabin).
Raft is more practical (as in "well specified") than Paxos and closest to its lesser known cousin, VR (Viewstamped Replication). Beyond the academic genealogy of the project, what is interesting here is the fact that usability is a first-class concern. Clearly the fact that it was born out of a real/breathing project was a driving factor.
It wasn't just an academic being creative. To pick a notorious example, have a quick look at Leslie Lamport's paper on Paxos: you are never quite sure whether what you are reading is a distributed systems paper or a vintage edition of the Holy Bible.
So Raft had great timing too. It came after decades of clumsy (because novel!) systems research on consensus algos and from a laboratory of practitioners, hence its designers knew exactly how previous attempts were deficient with respect to their own needs. And it turns out these overlapped with a lot of people's. There is wisdom to be learnt from this.
Also, on another note I think that's funny because this narrative reads exactly like a startup-story!