Cassander string caching is not worth it

Question

An example configuration file provided by Cassandra 1.2.2 has row_cache_size_in_mb 0, which completely disables row caching. Given that line caching was touted as an increase in read performance , I was surprised that it does not contain a line cache at all, not even a few dozen MB.

Is it really that line caching is no longer worthwhile for most scenarios? Or was it not worth it for most scenarios? Is it just worth replacing memcached ?

Answer 1

Row caching can help with many reads from relatively small column families. Although otherwise the data will be stored in the OS file system cache, the processor will build less response from the line cache objects than from the cached SSTable. In some tests, I made it 30% faster than reading from the cache of lines, although this will greatly depend on your data model.

Another option for using the row cache is that you want to primarily bind the column family in the cache, rather than relying on the OS cache policy.

However, for unprivileged CFs, line cache can reduce performance. This is probably why it is disabled by default. Therefore, you should only use line caching when you get reasonable speed. You can check this from nodetool info output.

Answer 2

The line cache is now more useful since 2.1, since you do not need to store the entire section in memory. This is done with the number of rows for each section in the table definition. It is best suited for queries in which you select the most recent x and use the clustering order.

http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1