Reputation: 48644
The example configuration file provided with Cassandra 1.2.2 has a row_cache_size_in_mb
of 0, which switches off row caching entirely. Given that row caching has been touted as giving read performance gains, I was surprised is sets aside no row cache at all, not even a few tens of MB.
Is it actually the case that row caching is no longer worthwhile for most scenarios? Or was it never worthwhile for most scenarios? Is it only worthwhile as a replacement for memcached
?
Upvotes: 4
Views: 4019
Reputation: 7305
The row cache is now more useful since 2.1 as you do not have to store the entire partition in memory. This is accomplished with the number of rows per partition setting on table definition. It works best for queries where you pick the x most recent and use clustering order by.
http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1
Upvotes: 3
Reputation: 11100
Row caching can help when doing many reads from relatively small column families. Although the data would otherwise be stored in the OS filesystem cache, it is less CPU to build the response from the row cache objects than from the cached SSTable. In some tests I did it was 30% faster reading from the row cache although this will depend a lot on your data model.
Another use case for the row cache is when you want to preferentially pin a column family in the cache rather than rely in the OS caching policy.
However, for uncachable CFs the row cache can decrease performance. This is probably why it is off by default. You should therefore only use row caching when you get a reasonable hit rate. You can check this from the nodetool info output.
Upvotes: 4