Nitin Padalia created CASSANDRA-8646:
----------------------------------------
Summary: For Column family
Key: CASSANDRA-8646
URL: https://issues.apache.org/jira/browse/CASSANDRA-8646
Project: Cassandra
Issue Type: Bug
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)
