It is my understanding that row cache is on the memory (Not on disk). It could live on heap or native memory depending on the cache provider? Is that right?
-SC > Date: Fri, 23 Aug 2013 18:58:07 +0100 > From: b...@dehora.net > To: user@cassandra.apache.org > Subject: Re: row cache > > 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 > thrash/evictions. > > Neither cache seems suitable for wide row + slicing usecases, eg time > series data or CQL tables whose compound keys create wide rows under the > hood. > > Bill > > > On 2013/08/23 17:30, Robert Coli wrote: > > On Thu, Aug 22, 2013 at 7:53 PM, Faraaz Sareshwala > > <fsareshw...@quantcast.com <mailto:fsareshw...@quantcast.com>> 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 >
