cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terje Marthinussen <>
Subject Re: Cassandra as storage for cache data
Date Tue, 02 Jul 2013 23:41:03 GMT
If this is a tombstone problem as suggested by some, and it is ok to turn of replication as
suggested by others, it may be an idea to do an optimization in cassandra where

if replication_factor < 1:
   do not create tombstones


On Jul 2, 2013, at 11:11 PM, Dmitry Olshansky <> wrote:

> In our case we have continuous flow of data to be cached. Every second we're receiving
tens of PUT requests. Every request has 500Kb payload in average and TTL about 20 minutes.
> On the other side we have the similar flow of GET requests. Every GET request is transformed
to "get by key" query for cassandra.
> This is very simple and straightforward solution:
> - one CF
> - one key that is directly corresponds to cache entry key
> - one value of type bytes that corresponds to cache entry payload
> To be honest, I don't see how we can switch this solution to multi-CF scheme playing
with time-based snapshots.
> Today this solution crashed again with overload symptoms:
> - almost non-stop compactifications on every node in cluster
> - large io-wait in the system
> - clients start failing with timeout exceptions
> At the same time we see that cassandra uses only half of java heap. How we can enforce
it to start using all available resources (namely operating memory)?
> Best regards,
> Dmitry Olshansky

View raw message