You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by "Hiller, Dean" <De...@nrel.gov> on 2012/09/10 17:54:51 UTC

any way to prefer just 3 column families for partial row caching

We have 3 tables for all indexing we do called
IntegerIndexing
DecimalIndexing
StringIndexing

playOrm would prefer that only these rows are cached as every row in those tables are indices.  Customers/Clients of playOrm tend to always hit the same index rows over and over as they are using the app because the end customer is typically very related to those indexes.  Some of these rows may have millions of columns though.  That should not be an issue, should it?

With this tuning, we can probably beat our previous query performance of 60ms…we never really want to cache data rows, at least I don't think we want to as I am not sure there would be much benefit but the index rows are constantly hit and when a few of them start to get hit, they get hit repeatedly as the user uses the system in general.

Thanks,
Dean

Re: any way to prefer just 3 column families for partial row caching

Posted by aaron morton <aa...@thelastpickle.com>.
> playOrm would prefer that only these rows are cached as every row in those tables are indices

CF level key and row caching is specified by the "caching" property. It can be either KEY, ROW or BOTH. 

So you can turn on the row cache, but only have some CF's use it.

Cheers


-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 11/09/2012, at 3:54 AM, "Hiller, Dean" <De...@nrel.gov> wrote:

> We have 3 tables for all indexing we do called
> IntegerIndexing
> DecimalIndexing
> StringIndexing
> 
> playOrm would prefer that only these rows are cached as every row in those tables are indices.  Customers/Clients of playOrm tend to always hit the same index rows over and over as they are using the app because the end customer is typically very related to those indexes.  Some of these rows may have millions of columns though.  That should not be an issue, should it?
> 
> With this tuning, we can probably beat our previous query performance of 60ms…we never really want to cache data rows, at least I don't think we want to as I am not sure there would be much benefit but the index rows are constantly hit and when a few of them start to get hit, they get hit repeatedly as the user uses the system in general.
> 
> Thanks,
> Dean