cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hÓra <>
Subject Re: row cache
Date Fri, 23 Aug 2013 17:58:07 GMT
I can't emphasise enough testing row caching against your workload for 
sustained periods and comparing results to just leveraging the 
filesystem cache and/or ssds. That said. The default off-heap cache can 
work for structures that don't mutate frequently, and whose rows are not 
very wide such that the in-and-out-of heap serialization overhead is 
minimised (I've seen the off-heap cache slow a system down because of 
serialization costs). The on-heap can do update in place, which is nice 
for more frequently changing structures, and for larger structures 
because it dodges the off-heap's serialization overhead. One problem 
I've experienced with the on-heap cache is the cache working set 
exceeding allocated space, resulting in GC pressure from sustained 

Neither cache seems suitable for wide row + slicing usecases, eg time 
series data or CQL tables whose compound keys create wide rows under the 


On 2013/08/23 17:30, Robert Coli wrote:
> On Thu, Aug 22, 2013 at 7:53 PM, Faraaz Sareshwala
> < <>> wrote:
>     According to the datastax documentation [1], there are two types of
>     row cache providers:
> ...
>     The off-heap row cache provider does indeed invalidate rows. We're
>     going to look into using the ConcurrentLinkedHashCacheProvider. Time
>     to read some source code! :)
> Thanks for the follow up... I'm used to thinking of the
> ConcurrentLinkedHashCacheProvider as "the row cache" and forgot that
> SerializingCacheProvider might have different invalidation behavior.
> Invalidating the whole row on write seems highly likely to reduce the
> overall performance of such a row cache. :)
> The criteria for use of row cache mentioned up-thread remain relevant.
> In most cases, you probably don't actually want to use the row cache.
> Especially if you're using ConcurrentLinkedHashCacheProvider and
> creating long lived, on heap objects.
> =Rob

View raw message