cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8646) Row Cache Miss with clustering key
Date Tue, 20 Jan 2015 10:23:35 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-8646:
----------------------------------------
    Assignee: Marcus Eriksson

> 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
>            Assignee: Marcus Eriksson
>            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)

Mime
View raw message