cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ZhaoYang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-13409) Materialized Views: View cells are resurrected
Date Thu, 04 May 2017 11:00:10 GMT

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

ZhaoYang edited comment on CASSANDRA-13409 at 5/4/17 10:59 AM:
---------------------------------------------------------------

Thanks. I didn't think about compaction with sub-group

1. deleted cell + shadowable row tombstone:   deleted cells should be kept even if there is
more recent shadowable row-tombstones, this could be done without changing storage format

since it's after gc_grace_seconds, it's less critical.

2. regular row tombstone + shadowable row tombstone: if shadowable is newer, only most recent
regular row tombstone plus shadowable should be kept. maybe have to change storage format.
eg. extra flag to indicate extra deletion.

it's critical..


was (Author: jasonstack):
Thanks. I didn't think about compaction with sub-group

deleted cell + shadowable row tombstone:   deleted cells should be kept even if there is more
recent shadowable row-tombstones, this could be done without changing storage format

regular row tombstone + shadowable row tombstone: if shadowable is newer, only most recent
regular row tombstone plus shadowable should be kept. maybe have to change storage format.
eg. extra flag to indicate extra deletion.

> Materialized Views: View cells are resurrected
> ----------------------------------------------
>
>                 Key: CASSANDRA-13409
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths, Materialized Views
>            Reporter: Duarte Nunes
>            Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk@0f054fee5c:
> {code:xml}
> echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
1};" | bin/cqlsh
> echo "create table ks.base (p int primary key, v1 int, v2 int) with gc_grace_seconds
= 1;" | bin/cqlsh
> echo "create materialized view ks.my_view as select * from ks.base where p is not null
and v1 is not null primary key (v1, p);" | bin/cqlsh
> echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "select * from ks.my_view;" | bin/cqlsh
>  v1 | p | v2
> ----+---+----
>   1 | 3 |  3
> (1 rows)
> echo "select * from ks.base;" | bin/cqlsh
>  p | v1 | v2
> ---+----+------
>  3 |  1 | null
> (1 rows)
> {code}
> As you can see, this incorrectly brings back cell v2=3. 
> There is one definitive problem and a potential one:
> * Merging rows must be commutative. If a shadowable tombstone is applied after a row
tombstone, it will replace that tombstone; if a row marker shadows the shadowable tombstone
before the row containing the original data is applied, then any dead cells in said data will
be resurrected;
> * Shadowable tombstones shouldn't compact away previous row tombstones or even deleted
cells; if the relevant tombstones have been GCed from the base table, then a base table update
won't carry them anymore (alongside a newer row marker).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message