memcached Digest, Vol 37, Issue 2

[James Byers]

One strategy is to increment location-version variables in memcached
for key generation.  There's some added complexity, but you'll only
have to perform one memcached operation for each invalidation.  Note
that this strategy has been mentioned on the list before, but I can't
find the reference.

- For each cached location (country+postalcode?), store a transient
version number in memcached.
- Use the version number to generate compound keys of country,
postalcode, radius, version.
- When a location is affected by a new post, increment its version.
If the location doesn't yet have version, just ignore the failed
increment.
- Let LRU clear out the now-unreferenced old versions for you.

The downside is that you'll have to query the version before you can
check the cache.  This adds a round-trip, but gets you from 500
deletes to 100 increments in your example.  Hopefully this version
check also keeps it in the cache at least as long as the keys
generated from it.

James
Wikispaces.com

>
> CALL get_offers(theCountry,thePostalCode,theRadius)
> ...
> When a new offer is posted or its status changes I run a function to
> remove the potentially stale data. I first look at the postal code and
> country that the offer is in. Then, I query the database to return a
> list of all postal codes within a 50mile radius. This can sometimes be
> hundreds of postal codes if you are located in a very dense area. Once I
> have that list I loop through it and delete the keys of every possible
> cached stored procedure call like this:
>
> delete(MD5("CALL get_offers(theCountry,thePostalCode,50)"));
>...