cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Daum <r...@thimbleware.com>
Subject Re: Memcached protocol?
Date Mon, 05 Apr 2010 17:19:12 GMT
Are these applications using memcached for caching or for something else?

I don't see the point in putting Cassandra in as a level 1 or 2 cache
replacement? Especially given as it does not support any reasonable
expiration policy that would be of use in those circumstances.

Ryan

On Mon, Apr 5, 2010 at 1:08 PM, Paul Prescod <prescod@gmail.com> wrote:

> On Mon, Apr 5, 2010 at 5:29 AM, Ryan Daum <ryan@thimbleware.com> wrote:
> > It seems pretty clear to me that the full memcached protocol is not
> > appropriate for Cassandra. The question is whether some subset of it is
> of
> > any use to anybody. The only advantage I can see is that there are a
> large
> > number of clients out there that can speak it already; but any app that
> is
> > making extensive use of it is probably doing so in a way that would
> preclude
> > Cassandra+Jmemcached from being a "drop-in" addition.
>
> Here are a couple of example projects for info.
>
> Django:
>
> http://docs.djangoproject.com/en/dev/topics/cache/
>
> It says of "increment/decrement": "incr()/decr() methods are not
> guaranteed to be atomic. On those backends that support atomic
> increment/decrement (most notably, the memcached backend), increment
> and decrement operations will be atomic. However, if the backend
> doesn't natively provide an increment/decrement operation, it will be
> implemented using a two-step retrieve/update."
>
> add() is implied to be atomic.
>
> Django itself does use add() in exactly one line of code that I can
> find. I believe it is just an optimization (don't bother saving this
> object if it already exists) and is not semantically meaningful. In
> fact, I don't believe that there is a code path to the add() call but
> I'm really not investigating very deeply.
>
> Rails:
>
>
> http://github.com/rails/rails/blob/master/actionpack/lib/action_controller/caching/actions.rb
>
> Here is the complete usage of the cache_store object in Rails.
>
> actionpack/lib/action_controller/caching/fragments.rb
> 44:          cache_store.write(key, content, options)
> 55:          result = cache_store.read(key, options)
> 66:          cache_store.exist?(key, options)
> 94:            cache_store.delete_matched(key, options)
> 96:            cache_store.delete(key, options)
>
> actionpack/lib/action_controller/caching.rb
> 79:        cache_store.fetch(ActiveSupport::Cache.expand_cache_key(key,
> :controller), options, &block)
>
> Fetch is an abstraction on top of read. delete_matched is not
> supported by the memcached plugin and not used by Rails.
>
> So as far as I can see, Rails only uses write, read, exist? and delete.
>
> It does expose more functions to the actual application, but the Rails
> framework does not use them. Most of them (including
> increment/decrement) are not even documented, and not supported with
> most cache stores.
>
>  *
> http://api.rubyonrails.org/classes/ActiveSupport/Cache/Store.html#M001029
>
> I checked a few of my own apps. They use get/set/add/delete, but the
> add is almost always used as an optimization.
>
>  Paul Prescod
>

Mime
View raw message