How to delete lots of related keys at once
dustin at spy.net
Wed Sep 19 16:34:31 UTC 2007
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached