Hacker News Reader

Comment by boulos | Hacker News Reader

Disclaimer: I admit to only reading the blog post and not looking at the code yet.

I really enjoyed this write-up as well! But I couldn't tell from the post: does it have a distributed mode like groupcache? (I think the answer is no). I think nearly all decisions in groupcache are because of the word "group" :).

Similarly, it would be great if there's a "safe mode" instead of the (IIUC) "start dropping Set requests when overloaded". You'd naturally want most applications to be prepared for your cache to get blown away, so you should be prepared for it to be lossy, but I'd certainly want a knob for that :).

View on HN

By using a cache with an eviction policy, you sort of already accept that the data you write at "t" might not exist at "t+1". So that solves the semantics and expectations part.

For the part where an overloaded cache drops Set requests, the most frequent Set requests are the one most likely to be admitted in between the dropped ones, so I guess this is also sort of taken care of.

I have no affiliation with the project, but reading and asking myself the same question as you, I reasoned what I wrote above.

Glad you liked it!

> does it have a distributed mode like groupcache?

Not at the moment, no. Though it could, theoretically, be used within groupcache. We'll look into that as it has been brought up a few times now.

> it would be great if there's a "safe mode" instead of the (IIUC) "start dropping Set requests when overloaded".

We could definitely look into adding a config flag for that. I'd love to know: in what situations would lossless Sets be important to you? We already have guaranteed updates, so the only Sets that are dropped are new items.

Also, if we guarantee that every Set is accepted, it goes against the idea that the Estimate of the incoming key must be higher than the Estimate of the key getting evicted.

Of course, one way to ensure every key goes in is to have a cache of infinite MaxCost. But, that’s an orthogonal idea, I guess.

Ahh! I missed that only new items are dropped, while updates are always accepted. That avoids the “umm, I have stale data” issue. That was my main worry!

Here is the code for groupcache:

https://github.com/golang/groupcache

There is no "distributed mode" as far as I can see. It is an in memory library for a K/V cache that you use in your code. That's it.

The description is somewhat clumsy (I’ll have Bradfitz update it) but “peers” allows for distributed. There are lots of things I don’t like about groupcache (e.g., immutability / need to version) but it is where the “group” part comes from.

Can't believe I missed that! Thanks for clarifying that.

Reply on news.ycombinator.com