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

RAMCloud Project

ramcloud.atlassian.net

Post reply on HN
Print view View original

41–50 of 52 posts

Re: RAMCloud Project

#41

Post by manigandham »

newaccoutnas wrote: post #25
manigandham wrote: post #16

Earlier quoted context omitted.

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

Atlassian is not blogging about it. Someone else created a Confluence wiki site for RAMCloud using the shared *.atlassian.net domain. Anyone can create a site with a subdomain there.

Re: RAMCloud Project

#42

Post by manigandham »

I would recommend Apache Ignite if you want a similar production-ready system today, along with extending datasets automatically to disk, built-in messaging and distributed data structures, and read/write-thru cache options.

Re: RAMCloud Project

#44

Post by Rafuino »

AndrewDucker wrote: post #9

What would be the difference between this and an SSD-based keystore and an instance of memcached with as much RAM as was necessary to hold the whole dataset?

Here's a slide from Dormando (memcached maintainer) who spoke recently at QCon SF. He created extstore, which lets you offload values to SSD and keep keys in memory. With all hits on different types of SSDs, he's seeing near all-DRAM performance in terms of throughput and latency.

https://twitter.com/justincormack/status/1059540644245295105

The NAND SSD (dark blue line) is still hitting good performance but at ~250K queries per second hits P99 latencies above 1ms (a typical SLA Netflix calls out for their own caching using extstore). The Optane SSD (light blue line) stays well below 1ms P99 latencies up to ~500K queries per second.

DRAM alone can handle more throughput but by then you have to take into account what your network can handle.

Re: RAMCloud Project

#46

Post by AndrewDucker »

Rafuino wrote: post #44
AndrewDucker wrote: post #9

What would be the difference between this and an SSD-based keystore and an instance of memcached with as much RAM as was necessary to hold the whole dataset?

Here's a slide from Dormando (memcached maintainer) who spoke recently at QCon SF. He created extstore, which lets you offload values to SSD and keep keys in memory. With all hits on different types of SSDs, he's seeing near all-DRAM performance in terms of throughput and latency. https://twitter.com/justincormack/status/1059540644245295105 The NAND SSD (dark blue line) is still hitting good performance but at ~250K…

Thank you, that's fascinating.

Re: RAMCloud Project

#47

Post by purple_ducks »

dugluak wrote: post #39

RAMCloud sounds cool and superfast, but why is the documentation so slow? Why does it need to be a site with heavy javascript with 482 ajax requests instead of plain old HTML?

480~ odd requests to load a non interactive, static text page is just embarrassing & shameful.

Re: RAMCloud Project

#49

Post by makmanalp »

antics wrote: post #40
erwan wrote: post #30

A 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 th…

Raft is certainly easier to explain , but it's hard to argue that Raft is more practical . For one thing, implementing Raft in a performant way is incredibly difficult. Where paxos has very fine-grained units of consensus ( e.g. , ballots), in Raft, everything happens through leases, and is totally linear. This is one of the major reasons a bunch of (all?) major Raft implementations do unprincipled things like non-qu…

To expand on this point, check out this talk by the CockroachDB VP of engineering[0]: they used raft but found out that it's approximately as complicated as paxos. They also do non-quorum reads, all through the leader replica)

[0] https://atscaleconference.com/videos/scale-2018-run-your-dat...

Re: RAMCloud Project

#50

Post by taco_emoji »

dugluak wrote: post #39

RAMCloud sounds cool and superfast, but why is the documentation so slow? Why does it need to be a site with heavy javascript with 482 ajax requests instead of plain old HTML?

Holy crap, you're not even exaggerating... 460 requests even with uBlock and Ghostery.
Post reply on HN