How to delete lots of related keys at once

[Dustin Sallings]

On Sep 19, 2007, at 7:02 , K J wrote:

> I'm facing the same problem here.  From the responses I'm guessing  
> that most of you think it's better to cache each individual  
> "article" and perhaps the article titles for display.  Listings  
> still hit the database directly.  The only savings would be that  
> the app wouldn't have to do another SQL to fetch the article titles/ 
> links/data, as it can get it from the cache.
>
> However, is there no way to cache these pages effectively?  For  
> instance, what if say I set a default expiration time for anything  
> that's not on page 1.  Then whenever an article gets inserted, the  
> first 10 pages are purged, while pages 11 onwards are expired on  
> their own.
>
> What do you guys think of this solution?

	Have you looked at the proposed solutions (i.e. tags and regex)?

	In general, having multiple copies of the same data seems like a bad  
idea.  When you cache the article,  you're avoiding the DB hit.  When  
you cache the page, you're memoizing a template render.  These are  
solving different problems.

On Sep 19, 2007, at 7:07 , K J wrote:

> For instance, I'd like to cache my search pages, as they are really  
> database/cpu intensive.  For instance, on a social networking site  
> someone could be searching based on sex, height, religion, hobbies,  
> location, and other combined criteria.  This sort of query hits the  
> databse hard, and it wouldn't take too many of those to crash the  
> db server.
>
> In this case wouldn't it be great to cache every single search that  
> comes in, so that in a duplicate search the app wouldn't have to  
> hit the database again?

	What do you expect the hit ratio to be on this?  What aspect of your  
search is intensive?  Are you, perhaps pulling too much data out with  
your search results such that you're pulling out information on each  
user that you could look up from cache?

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070919/a067901c/attachment.html