Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-8646

Row Cache Miss with clustering key

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Low
    • Resolution: Unresolved
    • 2.1.x
    • None
    • None
    • 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.

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            nitinpadalia Nitin Padalia
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated: