[jira] [Commented] (CASSANDRA-8646) Row Cache Miss with clustering key

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283675#comment-14283675 ] 

Sylvain Lebresne commented on CASSANDRA-8646:
---------------------------------------------

This is not a bug in the sense that it's how the code work. But we could check the cache when specific row are queried to see if they are indeed in the cache. It's not too hard but made a bit more complex by 1) the fact that if we have a {{IN}} some rows might be in the cache and so might not and we need to handle that and 2) the fact that currently querying rows by names is actually a multi-slice query and so detecting that we're in that case in the first place will be a tad annoying (of course, we can also wait on CASSANDRA-8099 which will make that last problem go away).

> Row Cache Miss with clustering key
> ----------------------------------
>
>                 Key: CASSANDRA-8646
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8646
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: OS: CentOS 6.5, [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL spec 3.2.0 | Native protocol v3]. Using CQL CLI for query analysis.
>            Reporter: Nitin Padalia
>            Priority: Minor
>             Fix For: 2.1.2
>
>
> Cassandra doesn't hit row cache for first and last row of a partition if we mention cluster keys in where condition. However if we use limit then it hits the row cache for the same rows.
> E.G. I've a column family:
> CREATE TABLE ucxndirdb2.usertable_cache (
>     user_id uuid,
>     dept_id uuid,
>     location_id text,
>     locationmap_id uuid,
>     PRIMARY KEY ((user_id, dept_id), location_id)
> ) WITH CLUSTERING ORDER BY (location_id ASC)
>     AND bloom_filter_fp_chance = 0.01
>     AND caching = '{"keys":"ALL", "rows_per_partition":"3"}'
>     AND comment = ''
>     AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'}
>     AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
>     AND dclocal_read_repair_chance = 0.1
>     AND default_time_to_live = 0
>     AND gc_grace_seconds = 864000
>     AND max_index_interval = 2048
>     AND memtable_flush_period_in_ms = 0
>     AND min_index_interval = 128
>     AND read_repair_chance = 0.0
>     AND speculative_retry = '99.0PERCENTILE';
> It has 3 rows per partition keys enabled for row cache.
> Now for a cached request, if I run:
> select * from usertable_cache WHERE user_id = 7bf16edf-b552-40f4-94ac-87b2e878d8c2  and dept_id = de3ac44f-2078-4321-a47c-de96c615d40d limit 3;
> Then its a cache hit with follow results:
>  user_id                              | dept_id                              | location_id | locationmap_id
> --------------------------------------+--------------------------------------+-------------+--------------------------------------
>  7bf16edf-b552-40f4-94ac-87b2e878d8c2 | de3ac44f-2078-4321-a47c-de96c615d40d |      ABC4:1 | 32b97639-ea5b-427f-8c27-8a5016e2ad6e
>  7bf16edf-b552-40f4-94ac-87b2e878d8c2 | de3ac44f-2078-4321-a47c-de96c615d40d |     ABC4:10 | dfacc9fc-7a6a-4fb4-8a4f-c13c606d552b
>  7bf16edf-b552-40f4-94ac-87b2e878d8c2 | de3ac44f-2078-4321-a47c-de96c615d40d |    ABC4:100 | 9ba7236a-6124-41c8-839b-edd299f510f7
> However If I run:
>  select * from usertable_cache WHERE user_id = 7bf16edf-b552-40f4-94ac-87b2e878d8c2  and dept_id = de3ac44f-2078-4321-a47c-de96c615d40d and location_id = 'ABC4:1';
> or 
>  select * from usertable_cache WHERE user_id = 7bf16edf-b552-40f4-94ac-87b2e878d8c2  and dept_id = de3ac44f-2078-4321-a47c-de96c615d40d and location_id = 'ABC4:100';
> Then its a cache miss. However for following its hit for following
>  select * from usertable_cache WHERE user_id = 7bf16edf-b552-40f4-94ac-87b2e878d8c2  and dept_id = de3ac44f-2078-4321-a47c-de96c615d40d and location_id = 'ABC4:10';
> and this behavior is consistent by increasing/decreasing rows_per_partiton setting. Cache is miss for only first and last record of the partition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)