Deleting values - expiration with memcachedb

[pubcrawler]

Thanks to Steve and the team at Northscale for all their memcached
contributions.

We are new to memcachedb. Looks like a promising product to keep our
memcached instances always populated (even after restarts/reboots).

Noticed in Steve's complete guide PDF the mention of *NO* expiration.
Want to be clear about what this means and get clarification from
others about how they deal with this issue.

We set expiration values on all of our data in memcached to keep data
fresh and in sync with our MySQL database from where our memcached
data originates. We have some automated cron jobs that run to hot
load memcached every 4 or so hours.

Is the expiration value not utilized/used/adhered to by memcachedb?
Can Steve speak to why the expiration isn't used in memcachedb? Think
it would be good to allow people to have memcachedb deal with
expirations even if it requires a runtime parameter to enable.

How are others dealing with expiring their memcached data in
memcachedb? Is there some way to attach to BerkeleyDB via JDBC/ODBC
and query and purge the stored values?

Thanks!
Paul

[Steve Chu]

Hi, Paul,

There's no expiration in MemcacheDB because we think of it as a
persistent store, not a cache. This may be the first reason. Another
reason is that implementing a good expiration is non-trivial in a
storage environment, this may affect the latency of store which causes
a performance loss.But recently, we know most of users use or want to
use MemcacheDB as a persistent cache. So we may reconsider this topic
and add support in next version. The new version may implement this
using lazy expiration, but still need work to recycle space of expired
item in database in a lightweight way.

Regards,
Steve

> --
>
> You received this message because you are subscribed to the Google Groups "memcachedb" group.
> To post to this group, send email to memca...@googlegroups.com.
> To unsubscribe from this group, send email to memcachedb+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/memcachedb?hl=en.
>
>
>



--
Best Regards,

Steve Chu
http://stvchu.org

[pub crawler]

Steve,

Thanks for the explanation on persistent cache and why expiration is
not a feature in memcachedb - for today.

I fully understand the overhead issues in purging items in memcachedb
due to the database backend. Have you tried doing expiration with
memcachedb yet in your development? What sort of performance hit
have you seen? Imagine the IO issues would go down considerably with
SSDs and other memory based storage devices. We are going to attempt
to run memcachedb on some cheap memory based devices we have -
currently only 8GB of SATA storage.

Can you give me a simple example of how people are purging data from
memcachedb today? Or do you see it as a place to store data and late
update the data - thus always keeping the key entries and just
adjusting the values?

-Paul

[Steve Chu]

On Sat, Dec 12, 2009 at 10:18 PM, pub crawler <pubcraw...@gmail.com> wrote:
> Steve,
>
> Thanks for the explanation on persistent cache and why expiration is
> not a feature in memcachedb - for today.
>
> I fully understand the overhead issues in purging items in memcachedb
> due to the database backend.   Have you tried doing expiration with
> memcachedb yet in your development?   What sort of performance hit
> have you seen?  Imagine the IO issues would go down considerably with
> SSDs and other memory based storage devices.  We are going to attempt
> to run memcachedb on some cheap memory based devices we have -
> currently only 8GB of SATA storage.

Expiration has not be implemented yet. It is only a planned feature of
new version.

>
> Can you give me a simple example of how people are purging data from
> memcachedb today?  Or do you see it as a place to store data and late
> update the data - thus always keeping the key entries and just
> adjusting the values?
>

There are two way you can do,
1. Update your cache directly in your application, I mean when the
source of data changes, change your cache too. (usually mysql trigger
or double write in your application).
2. Use extensive command rget to traversal the db in a non-block way.
Compare the timestamp of your item, delete it if it expires. rget now
only a patched libmemcached support it. See:
http://memcachedb.googlecode.com/svn/clients/libmemcached-0.25-patch/

> -Paul

[Clint Byrum]

On Dec 12, 2009, at 6:30 AM, Steve Chu wrote:

> On Sat, Dec 12, 2009 at 10:18 PM, pub crawler <pubcraw...@gmail.com> wrote:
>> Steve,
>>
>> Thanks for the explanation on persistent cache and why expiration is
>> not a feature in memcachedb - for today.
>>
>> I fully understand the overhead issues in purging items in memcachedb
>> due to the database backend. Have you tried doing expiration with
>> memcachedb yet in your development? What sort of performance hit
>> have you seen? Imagine the IO issues would go down considerably with
>> SSDs and other memory based storage devices. We are going to attempt
>> to run memcachedb on some cheap memory based devices we have -
>> currently only 8GB of SATA storage.
>
> Expiration has not be implemented yet. It is only a planned feature of
> new version.
>
>>
>> Can you give me a simple example of how people are purging data from
>> memcachedb today? Or do you see it as a place to store data and late
>> update the data - thus always keeping the key entries and just
>> adjusting the values?
>>
> There are two way you can do,
> 1. Update your cache directly in your application, I mean when the
> source of data changes, change your cache too. (usually mysql trigger
> or double write in your application).

A variation of this is to parse through the binlogs, or even just write a log in your app..

run_sql(DELETE from sourcetable WHERE id='key1')
write_log_line(delete|memcache-01|key1)

This lets you have a "gentle" process that just goes looking for data to clean up. Unfortunately if the source keys are lost, then rget is the only way to cleanup orphaned keys.

> 2. Use extensive command rget to traversal the db in a non-block way.
> Compare the timestamp of your item, delete it if it expires. rget now
> only a patched libmemcached support it. See:
> http://memcachedb.googlecode.com/svn/clients/libmemcached-0.25-patch/
>

At one point I had to move about 12 million items from a memcachedb instance into tokyo tyrant using rget. It was *painfully* slow because of the slow random access on the source machine's slow SATA RAID1.

[Steve Chu]

It seems tokyo tyrant can not avoid random access due to your slow
SATA RAID1 too, why not enlarge your cache? I think this is the key
solution. Another point, 12 million is some large for single Btree,
may increase the latency(hit more disk). Have you consider do some
partition on it?