Memcached limitations

[Brad Fitzpatrick]

There's no support for values accessible by multiple keys.  I suppose it'd
be possible, but it's just not in there.

LiveJournal has keys for username and userid, so we can lookup either way,
but we just store the item twice, since the value is small (~1k).  It's
your call:  indirection takes less memory, but has a tiny bit more
latency.  Storing twice is bigger, but faster.

Don't worry about number of keys.

Looking at our stats now, LiveJournal stores 5.2 million keys per 2GB
memcache and half that for our 1GB memcaches.



On Fri, 24 Oct 2003, Richard Jones wrote:

> Hi,
> I have a bunch of user objects memcached, accessible via key "user:123" where
> 123 is the user.id  I also need to reference users by a profile.id (one user
> can have many profiles). Currently i lookup in the database the user id
> associated with a given profile id, then fetch the user object from memcached
> using the user.id from the datbase lookup
>
> What i need is the ability to use multiple keys pointing to the same value.
> For example, user:123  and profile:789 point to the same cached value because
> user123 has a profile with id 789 - no such thing as a profile object, i just
> use profile ids to find users.
>
> Any clever tricks i can use to simulate this in a speedy way?
>
> I plan to store key/vals  "profile:789 --> 123" so that i can first lookup the
> user.id  using the profile.id, and then retreive the value at user:123.
>
> Just wanted to ask if there is a better way to do this..
>
> As an aside, how many keys can memcache cope with before performance suffers,
> or is it just a case of having enough ram?
>
> How much overhead is there involved in storing (say) 200,000   profile:789 -->
> 123  type items in memcached? should i mainly be focussing on storing bigger
> items, or doesn't it matter?
>
> Thanks,
> Richard.
>
>
>
>
>