Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: unknown (nike.apache.org: error in processing during lookup of
 jonas@borgstrom.se)
Message-ID: <4F7959C9.7030807@borgstrom.se>
Date: Mon, 02 Apr 2012 09:48:25 +0200
From: =?UTF-8?B?Sm9uYXMgQm9yZ3N0csO2bQ==?= <jonas@borgstrom.se>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Re: sstable2json and resurrected rows
References: <4F72CA92.2000504@borgstrom.se> <4F75A97D.3070307@borgstrom.se>
 <CAF7KpS8fgfm=Dy337GGiEk0WSzdV1L097sQM-ctG1bqhk6b0MA@mail.gmail.com>
In-Reply-To: 
 <CAF7KpS8fgfm=Dy337GGiEk0WSzdV1L097sQM-ctG1bqhk6b0MA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2012-03-31 08:45 , Zhu Han wrote:
> Did you hit the bug here?
>
> https://issues.apache.org/jira/browse/CASSANDRA-4054

Yes looks like it. But what confuses me most is not the sstable2json bug 
but why the major compaction does not replace the deleted row data with 
a tombstone.

Is that a bug or a feature?

To me it just looks like a wast of disk space...

/ Jonas

>
> best regards,
>
> 坚果云 <https://jianguopuzi.com/>, 最简捷易用的云存储
> 无限空间, 文件同步, 备份和分享!
>
>
> 2012/3/30 Jonas Borgström <jonas@borgstrom.se <mailto:jonas@borgstrom.se>>
>
>     Let me rephrase my question:
>
>     Is it true that deleted rows will still be present in the sstable
>     after a major compaction with 1.0.8 (not just tombstones)?
>
>     Or did I mess up my test below?
>
>     / Jonas
>
>
>
>     On 2012-03-28 10:23 , Jonas Borgström wrote:
>
>         Hi all,
>
>         I've noticed a change in behavior between 0.8.10 and 1.0.8 when
>         it comes
>         to sstable2json output and major compactions. Is this a bug or
>         intended
>         behavior?
>
>         With 1.0.8:
>
>         create keyspace ks;
>         use ks;
>         create column family foo;
>         set foo[1][1] = 1;
>         nodetool -h localhost flush
>         sstable2json foo-hc-1-Data.db =>
>         {
>         "01": [["01","01",1332920802272000]]
>         }
>         del foo[1];
>         set foo[2][2] = 2;
>         nodetool -h localhost flush
>         sstable2json foo-hc-2-Data.db =>
>         {
>         "01": [],
>         "02": [["02","02",1332920843090000]]
>         }
>         nodetool -h localhost compact ks foo
>
>         So far so good. But now I expect the resulting sstable to look like
>         foo-hc-2 (the way 0.8.10 behaves) but instead it looks like the
>         deleted
>         foo[1] has been resurrected (foo[1] is still deleted when using the
>         thrift api):
>
>         sstable2json foo-hc-3-Data.db =>
>         {
>         "01": [["01","01",1332920802272000]]__,
>         "02": [["02","02",1332920843090000]]
>         }
>
>         So why is the full foo[1] row included in the sstable2json
>         output and
>         not just a tombstone?
>
>         This is both a wast of disk space and makes it impossible to
>         trust the
>         sstable2json output.
>
>         / Jonas
>
>
>