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

[Hiller, Dean]

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

[aaron morton]

 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 dean.hil...@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