skylos at gmail.com
Sat Feb 5 16:39:17 PST 2005
I'd have to wonder, though - are you then going to query all the
memcached servers in the cluster, individually, for the list of keys
they have - which may be quite extensive... and the accompanied
overhead in transmitting that list could be quite significant, times
the number of servers you have.
and then I've never looked at the code - does the individual servers
even normally *keep* a list of available keys? I can't imagine they
have any good reason to - they never iterate over their keys, why
bother? They're either in the data structure, or they're not....
But what do I know? :)
On Sat, 5 Feb 2005 16:27:16 -0800 (PST), christopher at baus.net
<christopher at baus.net> wrote:
> > It seems to make sense to add a hasKey method.
> > For a lot of operations I just want to do quick existence checks and get
> back a boolean yes or no. We're doing a LARGE amount of queries and
> doing a get() and getting back the data just doesn't make sense.
> > Also... if the objects you are storing are large it also make sense even
> if you're not doing to many of them.
> > I realize that memcached is fast but for a lot of situations this could
> offload the network and the CPU on the client.
> > Kevin
> For the application I am working on it would be useful to query the keys
> in the cache and perform set operations on them as well. For instance:
> delete the keys not in the intersection of the current keys and the new
> set. I've been looking through the server code and it seems like the
> protocol is pretty straight forward. It might not be that bad to add
> these types of operations.
More information about the memcached