The row cache saves partition data off-heap, which means that every cache hit require copying/deserializing the cached partition into the heap, and the more rows per partition you cache, the long it will take. Which is why it's currently not a good cache too much rows per partition (unless you know what you're doing).
On Wed, Jan 21, 2015 at 1:15 PM, nitin padalia <padalia.ni...@gmail.com> wrote: > Hi, > > With two different families when I do a read, row cache hit is almost > 15x costlier with larger rows (10000 rows per partition), in > comparison to partition with only 100 rows. > > Difference in two column families is one is having 100 rows per > partition another 10000 rows per partition. Schema for two tables is: > CREATE TABLE table1_row_cache ( > user_id uuid, > dept_id uuid, > location_id text, > locationmap_id uuid, > PRIMARY KEY ((user_id, location_id), dept_id) > ) > > CREATE TABLE table2_row_cache ( > user_id uuid, > dept_id uuid, > location_id text, > locationmap_id uuid, > PRIMARY KEY ((user_id, dept_id), location_id) > ) > > Here is the tracing: > > Row cache Hit with Column Family table1_row_cache, 100 rows per partition: > Preparing statement [SharedPool-Worker-2] | 2015-01-20 > 14:35:47.540000 | x.x.x.x | 1023 > Row cache hit [SharedPool-Worker-5] | 2015-01-20 > 14:35:47.542000 | x.x.x.x | 2426 > > Row cache Hit with CF table2_row_cache, 10000 rows per partition: > Preparing statement [SharedPool-Worker-1] | 2015-01-20 16:02:51.696000 > | x.x.x.x | 490 > Row cache hit [SharedPool-Worker-2] | 2015-01-20 > 16:02:51.711000 | x.x.x.x | 15146 > > > If for both cases data is in memory why its not same? Can someone > point me what wrong here? > > Nitin Padalia >
