cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Tolbert (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-11068) Entire row is compacted away if remaining cells are tombstones expiring after gc_grace_seconds
Date Mon, 25 Jan 2016 19:24:39 GMT

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

Andy Tolbert updated CASSANDRA-11068:
-------------------------------------
    Description: 
Assuming the following schema:

{code}
CREATE TABLE simple.data (
    k text PRIMARY KEY,
    v int
) WITH gc_grace_seconds = 300;
{code}

And the following queries:

{code}
insert into simple.data (k, v) values ('blah', 1);
delete v from simple.data where k='blah';
{code}

Performing a {{select *}} from this table will return 1 row with a null value:

{code}
cqlsh> select * from simple.data;

         k | v
-----------+---------
      blah |    null
{code}

Prior the 3.0, if I were to do a flush, the sstable representation of this table would include
an empty cell and a tombstone:

{code}
[
{"key": "blah",
 "cells": [["","",1453747038457027],
           ["v",1453747112,1453747112383096,"d"]]}
]
{code}

As my gc_grace_seconds value is 300, if I wait 5 minutes and perform a compaction, the new
sstable would omit the tombstone, but the empty cell would still be present:

{code}
[
{"key": "blah",
 "cells": [["","",1453747038457027]]}
]
{code}

Performing the {{select *}} query would still yield the same result because of this.

However, in 3.2.1 this does not seem to be the behavior, after deleting the 'v' cell, performing
a flush and then waiting 5 minutes and doing a compact, what ends up happening is that the
sstable completely disappears (presumably because there is no remaining data) and the select
query emits 0 rows:

{code}
cqlsh> select * from simple.data;

         k | v
-----------+---------

(0 rows)
{code}

I'm unsure if this is by design or a bug, but it does represent a change between C* versions.

-I have not tried this for a table with clustering columns yet, but I assume that the behavior
will be the same.- (The problem only manifests for tables with no clustering columns).

  was:
Assuming the following schema:

{code}
CREATE TABLE simple.data (
    k text PRIMARY KEY,
    v int
) WITH gc_grace_seconds = 300;
{code}

And the following queries:

{code}
insert into simple.data (k, v) values ('blah', 1);
delete v from simple.data where k='blah';
{code}

Performing a {{select *}} from this table will return 1 row with a null value:

{code}
cqlsh> select * from simple.data;

         k | v
-----------+---------
      blah |    null
{code}

Prior the 3.0, if I were to do a flush, the sstable representation of this table would include
an empty cell and a tombstone:

{code}
[
{"key": "blah",
 "cells": [["","",1453747038457027],
           ["v",1453747112,1453747112383096,"d"]]}
]
{code}

As my gc_grace_seconds value is 300, if I wait 5 minutes and perform a compaction, the new
sstable would omit the tombstone, but the empty cell would still be present:

{code}
[
{"key": "blah",
 "cells": [["","",1453747038457027]]}
]
{code}

Performing the {{select *}} query would still yield the same result because of this.

However, in 3.2.1 this does not seem to be the behavior, after deleting the 'v' cell, performing
a flush and then waiting 5 minutes and doing a compact, what ends up happening is that the
sstable completely disappears (presumably because there is no remaining data) and the select
query emits 0 rows:

{code}
cqlsh> select * from simple.data;

         k | v
-----------+---------

(0 rows)
{code}

I'm unsure if this is by design or a bug, but it does represent a change between C* versions.

I have not tried this for a table with clustering columns yet, but I assume that the behavior
will be the same.


> Entire row is compacted away if remaining cells are tombstones expiring after gc_grace_seconds
> ----------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-11068
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11068
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Andy Tolbert
>
> Assuming the following schema:
> {code}
> CREATE TABLE simple.data (
>     k text PRIMARY KEY,
>     v int
> ) WITH gc_grace_seconds = 300;
> {code}
> And the following queries:
> {code}
> insert into simple.data (k, v) values ('blah', 1);
> delete v from simple.data where k='blah';
> {code}
> Performing a {{select *}} from this table will return 1 row with a null value:
> {code}
> cqlsh> select * from simple.data;
>          k | v
> -----------+---------
>       blah |    null
> {code}
> Prior the 3.0, if I were to do a flush, the sstable representation of this table would
include an empty cell and a tombstone:
> {code}
> [
> {"key": "blah",
>  "cells": [["","",1453747038457027],
>            ["v",1453747112,1453747112383096,"d"]]}
> ]
> {code}
> As my gc_grace_seconds value is 300, if I wait 5 minutes and perform a compaction, the
new sstable would omit the tombstone, but the empty cell would still be present:
> {code}
> [
> {"key": "blah",
>  "cells": [["","",1453747038457027]]}
> ]
> {code}
> Performing the {{select *}} query would still yield the same result because of this.
> However, in 3.2.1 this does not seem to be the behavior, after deleting the 'v' cell,
performing a flush and then waiting 5 minutes and doing a compact, what ends up happening
is that the sstable completely disappears (presumably because there is no remaining data)
and the select query emits 0 rows:
> {code}
> cqlsh> select * from simple.data;
>          k | v
> -----------+---------
> (0 rows)
> {code}
> I'm unsure if this is by design or a bug, but it does represent a change between C* versions.
> -I have not tried this for a table with clustering columns yet, but I assume that the
behavior will be the same.- (The problem only manifests for tables with no clustering columns).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message