I see. Thanks, Arvydas! In terms of eviction policy in the row cache, does a write operation invalidates only the row(s) which are going be modified or the whole partition? In older version of Cassandra, I believe the whole partition gets invalidated even if only one row is modified. Is that still true for the latest release (3.10). I browsed through many online articles and tutorials but cannot find information on this.
On Sun, Mar 12, 2017 at 2:25 PM, Arvydas Jonusonis < arvydas.jonuso...@gmail.com> wrote: > You can experiment quite easily without even needing to restart the > Cassandra service. > > The caches (row and key) can be enabled on a table-by-table basis via a > schema directive. But the cache capacity (which is the one that you > referred to in your original post, set to 0 in cassandra.yaml) is a global > setting and can be manipulated via JMX or nodetool (nodetool > setcachecapacity > <https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSetCacheCapacity.html> > ). > > Arvydas > > On Sun, Mar 12, 2017 at 9:46 AM, preetika tyagi <preetikaty...@gmail.com> > wrote: > >> Thanks, Matija! That was insightful. >> >> I don't really have a use case in particular, however, what I'm trying to >> do is to figure out how the Cassandra performance can be leveraged by using >> different caching mechanisms, such as row cache, key cache, partition >> summary etc. Of course, it will also heavily depend on the type of workload >> but I'm trying to gain more understanding of what's available in the >> Cassandra framework. >> >> Also, I read somewhere that either row cache or key cache can be turned >> on for a specific table, not both. Based on your comment, I guess the >> combination of page cache and key cache is used widely for tuning the >> performance. >> >> Thanks, >> Preetika >> >> On Sat, Mar 11, 2017 at 2:01 PM, Matija Gobec <matija0...@gmail.com> >> wrote: >> >>> Hi, >>> >>> In 99% of use cases Cassandra's row cache is not something you should >>> look into. Leveraging page cache yields good results and if accounted for >>> can provide you with performance increase on read side. >>> I'm not a fan of a default row cache implementation and its invalidation >>> mechanism on updates so you really need to be careful when and how you use >>> it. There isn't much to configuration as there is to your use case. Maybe >>> explain what are you trying to solve with row cache and people can get into >>> discussion with more context. >>> >>> Regards, >>> Matija >>> >>> On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <preetikaty...@gmail.com >>> > wrote: >>> >>>> Hi, >>>> >>>> I'm new to Cassandra and trying to get a better understanding on how >>>> the row cache can be tuned to optimize the performance. >>>> >>>> I came across think this article: https://docs.datastax >>>> .com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html >>>> >>>> And it suggests not to even touch row cache unless read workload is > >>>> 95% and mostly rely on machine's default cache mechanism which comes with >>>> OS. >>>> >>>> The default row cache size is 0 in cassandra.yaml file so the row cache >>>> won't be utilized at all. >>>> >>>> Therefore, I'm wondering how exactly I can decide to chose to tweak row >>>> cache if needed. Are there any good pointers one can provide on this? >>>> >>>> Thanks, >>>> Preetika >>>> >>> >>> >> >
