is bigger really better, when it comes to memcached?

[Josh Berkus]

Adam,

> 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.

Me, I'd intelligently separate the frequently from the infrequently updated 
columns, not just in memcached but in the tables as well.  In fact, I've done 
this for several applications.  Then I go even further and only synch some 
frequently updated information periodically (say, every minute) so that the 
DB isn't getting hit with dozens of transitory updates.   If it's something 
like a last_pageview time, you can really afford to lose a few seconds if it 
cuts your database I/O by 20x.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco