is bigger really better, when it comes to memcached?

[Adam Michaels]

Lets say you have a users table with 50 columns. You do a select * from users where user_id = 1 and cache the result in memcached as a serialized object. Each time a value in that user's row gets updated your cache gets expired. If you had a few columns which was updated frequently, think of a last_active column or something like that, you cache hit rate would be low due to frequent expiration.

On the other hand, lets say you have a users table with 50 columns. You do a select * from users where user_id = 1. But instead of caching the entire result as a serialized object in memcache, you break the result set into 5 memcache objects, with 10 column attributes in each. When you want to fetch the cache for that user, you now are doing a multiget for 5 memcache objects or if you only need part of the user's data, you fetch less of it. But when only an attribute in one of the cache objects is updated, only that cache object needs to be expired.

Given the situation, which solution would you guys prefer? Bigger objects that expire more frequently with the benefit of only needing 1 memcache call? Or Multiple smaller objects that individually expire less often but require the use of a multiget? 


This is mostly a theoretical exercise on how to use memcached to its fullest but it would be nice to hear everyone's thoughts on the issue. 

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070628/27ae29a3/attachment.html