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] [Commented] (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: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)

Mime
View raw message