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

Keith Wright commented on CASSANDRA-6654:
-----------------------------------------

So you're saying that even though we know we can compact away some columns due 
to their TTL, we can't because some other columns have older TTLs?  This seems 
counter intuitive when we are allowed to set per column TTLs.  In the end you 
have a row TTL that matches the column that needs to live the longest.

This severely impacts our Cassandra usage case as we selected Cassandra 
specifically for its ability to size data based on TTL to ensure we do not get 
wide rows.  

> Droppable tombstones are not being removed from LCS table despite being above 
> 20%
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6654
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6654
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: 1.2.13 VNodes with murmur3
>            Reporter: Keith Wright
>            Assignee: Marcus Eriksson
>         Attachments: Screen Shot 2014-02-05 at 9.38.20 AM.png, dtrlog.txt, 
> repro3.py
>
>
> JMX is showing that one of our CQL3 LCS tables has a droppable tombstone 
> ratio above 20% and increasing (currently at 28%).  Compactions are not 
> falling behind and we are using the OOTB setting for this feature so I would 
> expect not to go above 20% (will attach screen shot from JMX).   Table 
> description:
> CREATE TABLE global_user (
>   user_id timeuuid,
>   app_id int,
>   type text,
>   name text,
>   extra_param map<text, text>,
>   last timestamp,
>   paid boolean,
>   sku_time map<text, timestamp>,
>   values map<timestamp, float>,
>   PRIMARY KEY (user_id, app_id, type, name)
> ) WITH
>   bloom_filter_fp_chance=0.100000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.000000 AND
>   gc_grace_seconds=86400 AND
>   read_repair_chance=0.100000 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'sstable_size_in_mb': '160', 'class': 
> 'LeveledCompactionStrategy'} AND
>   compression={'chunk_length_kb': '8', 'crc_check_chance': '0.1', 
> 'sstable_compression': 'LZ4Compressor'}; 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to