cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4396) Subcolumns not removed when compacting tombstoned super column
Date Fri, 29 Jun 2012 18:04:44 GMT

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

Jonathan Ellis updated CASSANDRA-4396:
--------------------------------------

             Reviewer: yukim
    Affects Version/s:     (was: 1.1.1)
                       1.0.0
        Fix Version/s: 1.1.3
                       1.0.11
             Assignee: Jonathan Ellis

This code in removeDeletedSuper is intended to address this scenario:

{code}
.               // remove subcolumns if
                // (a) the subcolumn itself is tombstoned or
                // (b) the supercolumn is tombstoned and the subcolumn is not newer than it
                if (subColumn.timestamp() <= minTimestamp
                    || subColumn.getLocalDeletionTime() < gcBefore)
                {
                    subIter.remove();
                }
{code}

Unclear why it's not actually working here.
                
> Subcolumns not removed when compacting tombstoned super column
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-4396
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4396
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.0.0
>            Reporter: Nick Bailey
>            Assignee: Jonathan Ellis
>             Fix For: 1.0.11, 1.1.3
>
>
> When we compact a tombstone for a super column with the old data for that super column,
we end up writing the deleted super column and all the subcolumn data that is now worthless
to the new sstable. This is especially inefficient when reads need to scan tombstones during
a slice.
> Here is the output of a simple test I ran to confirm:
> insert supercolumn, then flush
> {noformat}
> Nicks-MacBook-Pro:12:20:52 cassandra-1.0] cassandra$ bin/sstable2json ~/.ccm/1node/node1/data/Keyspace2/Super4-hd-1-Data.db

> {
> "6b657931": {"supercol1": {"deletedAt": -9223372036854775808, "subColumns": [["737562636f6c31","7468697320697320612074657374",1340990212532000]]}}
> }
> {noformat}
> delete supercolumn, flush again
> {noformat}
> [Nicks-MacBook-Pro:12:20:59 cassandra-1.0] cassandra$ bin/nodetool -h localhost flush
> [Nicks-MacBook-Pro:12:22:41 cassandra-1.0] cassandra$ bin/sstable2json ~/.ccm/1node/node1/data/Keyspace2/Super4-hd-2-Data.db

> {
> "6b657931": {"supercol1": {"deletedAt": 1340990544005000, "subColumns": []}}
> }
> {noformat}
> compact and check resulting sstable
> {noformat}
> [Nicks-MacBook-Pro:12:22:55 cassandra-1.0] cassandra$ bin/nodetool -h localhost compact

> [Nicks-MacBook-Pro:12:23:09 cassandra-1.0] cassandra$ bin/sstable2json ~/.ccm/1node/node1/data/Keyspace2/Super4-hd-3-Data.db

> {
> "6b657931": {"supercol1": {"deletedAt": 1340990544005000, "subColumns": [["737562636f6c31","7468697320697320612074657374",1340990212532000]]}}
> }
> [Nicks-MacBook-Pro:12:23:20 cassandra-1.0] cassandra$ 
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message