Write LRU to database

[Steven Grimm]

Oscar Kené wrote:
> Is there any functionality to make it write these to a mySQL-database 
> instead?

Memcached is typically used to cache data that's already in your 
database to begin with, in which case this becomes unnecessary; if an 
object isn't in your cache, you just hit the database instead.

In my opinion it is not a good idea to *only* store data in memcached. 
Memcached processes can get killed accidentally, your data center can 
have a power outage, your sysadmins can decide they need to move servers 
to different racks, your memcached machines can have hardware glitches 
and spontaneously reboot, etc. (To name some of the things that have 
happened to our memcached servers.) Even if you modified it to write 
data somewhere else at expiration time, you would still be vulnerable to 
the cache getting blown away for whatever reason; you'd lose all the 
non-expired data.

> Right now my data is INSERTed, SELECTed only once and then DELETEd. 
> But every "set" of data is not handled sequentially. So one "set" of 
> data can be INSERTEd but not SELECTed or DELETEd before the entry is 
> subject to the "LRU-rule". I.e. I want to keep the most recent 
> "INSERTs" in memcache as they are the most likely to be operated on 
> first.

If that's generally your usage pattern, then memcached's LRU semantics 
may not even come into play, assuming you're careful to delete items 
from the cache after you're done operating on them (which should be fine 
if you're only reading them once.) Memcached will always reuse space 
from deleted or expired items before it will evict any valid items from 
the cache, so you just need to have enough space in your cache to hold 
your typical backlog of items. If you're constantly reading and deleting 
the most recent items, then the next items you write will just reuse 
that space over and over again.

FYI, memcached's expiration policy is not strictly LRU if your cache 
items are of significantly different sizes; there is a separate LRU 
queue for each range of sizes computed by the slab allocator. In normal 
operation that's usually not noticeable, but if you're trying to do 
something that depends in any way on eviction order, you'll want to be 
aware of that.

-Steve