Suitable use cases for GroupCache

[John Wesonga]

I'm interested in using GroupCache having stumbled upon it from bradfitz talk http://talks.golang.org/2013/oscon-dl.slide#44 Brad points out that it's a "memcached alternative/replacement" but in a thread https://groups.google.com/forum/#!searchin/golang-nuts/groupcache/golang-nuts/ITxRD9FLOoU/L1LalClpaHEJ on the group someone pointed out:

Groupcache is great when the cost of producing the data is high, eg. it needs to be fetched from somewhere else, or it needs to spend minutes or hours being computed, or it requires local access to a large amount of data that isn't easy to transfer to all the nodes.

If the cost of querying a remote server and fetching the result is higher than the cost of computing the result then groupcache isn't what you want.

It's a completely different usecase to memcache and I think that confuses people.

I wanted to get some inputs from the group on suitable use cases for GroupCache, which problem does it solve well?

[Matthew Zimmerman]

I've never used it, but have read the same threads/presentations you
have. Have you also read the README for the project? I think it
explains what it's purpose is fairly well.

https://github.com/golang/groupcache

I would disagree that it's a *completely* different use case but
that's a relative statement anyway.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Benjamin Measures]

On Wednesday, 19 February 2014 13:35:37 UTC, John Wesonga wrote:

[...] in a thread https://groups.google.com/forum/#!searchin/golang-nuts/groupcache/golang-nuts/ITxRD9FLOoU/L1LalClpaHEJ on the group someone pointed out:

[...]

If the cost of querying a remote server and fetching the result is higher than the cost of computing the result then groupcache isn't what you want.

I'd say the above statement is more true when applied to memcached (than for groupcache).

Unlike memcached, groupcache:
... supports automatic mirroring of super-hot items to multiple processes. This prevents memcached hot spotting where a machine's CPU and/or NIC are overloaded by very popular keys/values.

https://github.com/golang/groupcache

This means that hot items don't always have to go over the network.

It's a completely different usecase to memcache and I think that confuses people.

Well, seeing as Brad Fitzpatrick, the author of groupcache, was also the author of memcached, I trust him when he states:

groupcache is a caching and cache-filling library, intended as a replacement for memcached in many cases.

https://github.com/golang/groupcache

 

I wanted to get some inputs from the group on suitable use cases for GroupCache, which problem does it solve well?

It solves the problem of a scale-out distributed cache (just like memcached). However, unlike memcached which can often have the problem of hot keys and thundering herds, groupcache is architected in a way that solves these related problems. See <https://github.com/golang/groupcache> for more explanation.

OTOH, groupcache has neither cache invalidation (one of the "three" hard problems in computer science) nor value updating, which keeps its implementation considerably simpler and enables a key feature. AFAICT, this is the main reason for it being said that it is "a replacement for memcached /in many cases/" (emphasis mine). In practice though, this isn't anything that can't be taken care of in application code by careful key formulation.

Judging by sources of the quotes above, you should probably have a browse of groupcache's project page <https://github.com/golang/groupcache>. The code is an excellent read also.

[david...@gmail.com]

OTOH, groupcache has neither cache invalidation (one of the "three" hard problems in computer science) nor value updating, which keeps its implementation considerably simpler and enables a key feature. AFAICT, this is the main reason for it being said that it is "a replacement for memcached /in many cases/" (emphasis mine). In practice though, this isn't anything that can't be taken care of in application code by careful key formulation.

It looks nice, but given that it doesn't support invalidation any ideas as to an approach to dealing with stale cache entries or a bad cache entry that needs to be replaced?  An example problem:

Suppose I render a template with some database contents and store the output under key "X".  Now the database changes, or someone entered the data incorrectly so I don't need to deliver the bad cached copy any more.

I've never dealt directly with cache API's that didn't support updates or deletions so I'm unfamiliar how to approach the above problem.

[Caleb Spare]

I've never used groupcache but it sounds like you need to find a way to represent your data as immutable blobs. So, you can do something like append a hash of the contents to the key.

--

[David Symonds]

Groupcache can effectively do time-based cache invalidation by making
a quantised timestamp part of the key. When you stop requesting a key
it'll eventually drop out of the cache. You can do the same thing with
epoch counters. But it sounds like your situation might not be exactly
what groupcache is for.

[Fabrizio Milo aka misto]

I was looking for a good library to use as a local cache for appengine
and in case of miss to delegate to memcache. Would this be possible
using groupcache ?

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
LinkedIn: http://linkedin.com/in/fmilo
Twitter: @fabmilo
Github: http://github.com/Mistobaan/
-----------------------
Simplicity, consistency, and repetition - that's how you get through.
(Jack Welch)
Perfection must be reached by degrees; she requires the slow hand of
time (Voltaire)
The best way to predict the future is to invent it (Alan Kay)

[egon]

You get similar problems with databases that support updates/deletions. Let's say user A gets some content X, then user B gets the same content X. Now user A thinks a little and submits a change (Z) to X. Now the user B has also figured out what to do and submits a different change (W) to X. Essentially you have a write collision.

The simple solution is that you need to verify the "X" as being properly the base state... i.e. you submit a change X->Z, X->W... During the second update "X->W" you can check whether the data really is "X" and decide whether to override or show an error.

Martin Fowler has a quite simple overview of it: http://www.youtube.com/watch?v=qI_g07C_Q5I#t=1562.

Even more, if you have structured your program that way, you don't have to worry that much about invalidation, because you can already deal with "old data". You can look at http://www.youtube.com/watch?v=GKrTMSMbN4w to see benefits from "immutable databases".

+ egon

[Matthew Zimmerman]

On Thu, Feb 20, 2014 at 2:16 PM, Fabrizio Milo aka misto
<mist...@gmail.com> wrote:
> I was looking for a good library to use as a local cache for appengine
> and in case of miss to delegate to memcache

Look at https://github.com/mjibson/goon for this - that's exactly what it does.

[dave...@gmail.com]

On Thursday, February 20, 2014 at 1:25:46 AM UTC-5, David McCurley wrote:

OTOH, groupcache has neither cache invalidation (one of the "three" hard problems in computer science) nor value updating, which keeps its implementation considerably simpler and enables a key feature. AFAICT, this is the main reason for it being said that it is "a replacement for memcached /in many cases/" (emphasis mine). In practice though, this isn't anything that can't be taken care of in application code by careful key formulation.

In Unix (and Linux), we used to* atomically "mv" a new binary or library into place, and the OS would garbage-collect the old one's disk blocks when there were no remaining references to it. 

If I add a datestamp or other versiuon identifier to the groupcache key, I get the same behavior.  Old clients use the old copy, new ones use the new copy, and old copies get flushed out / garbage collected when no-one's using them. 

--dave

[* many folks have forgotten this]