[
https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731067#comment-14731067
]
Tyler Hobbs commented on CASSANDRA-10261:
-----------------------------------------
This is a pretty nasty problem.
To summarize: rewriting an entire MV row shadows updates to the base row with
older timestamps. Specifically, the tombstone on the MV row causes this.
We cannot detect this condition without doing a read-before-write on the MV.
Even if we did that, we would need to write new (old timestamped) base data to
the MV somewhere special so that the tombstone doesn't affect it.
It seems to me that the other options are to 1) try to remove/negate existing
tombstones when inserting an MV row (using an anti-tombstone?) or 2) to perform
deletions in a way that doesn't prevent future updates with older timestamps.
The anti-tombstone approach might look like a second timestamp in the MV row
marker that would "protect" the cells within the row from tombstones with older
timestamps, even if the cells themselves should be shadowed by the tombstone.
The special deletion handling approach would be similar. I _think_ that we can
count on row markers being present in the MV (please correct me if I'm wrong).
When dealing with MVs, we could treat range tombstones specially so that they
only shadow rows with a lower timestamp in the row marker, regardless of
timestamps on cells within the row.
I haven't really thought through the mechanics or implications of these
approaches yet, but I'm throwing ideas out there to get us started. It doesn't
seem like we have any great options.
> Materialized Views Timestamp issues
> -----------------------------------
>
> Key: CASSANDRA-10261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10261
> Project: Cassandra
> Issue Type: Bug
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Fix For: 3.0.0 rc1
>
>
> As [~thobbs]
> [mentioned|https://issues.apache.org/jira/browse/CASSANDRA-9664?focusedCommentId=14724150&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14724150]
> in CASSANDRA-9664 there are issues dealing with updates to individual cells
> which can mask data from the base table in the view when trying to filter
> data correctly in the view.
> Unfortunately, this same issue exists for all MV tables with regular columns.
> In the earlier versions of MV we did have a fix for this which I now can see
> is ineffective for all situations.
> I've pushed some unit tests to show the issue (similar to tylers) and a fix.
> The idea is we keep the base table's timestamps per cell as it so we can
> *always* tell (per replica) which version of the record is the latest. Since
> the base table *always* writes the entire record to the view (part of our
> earlier partial fix) we can ensure the view record contains *at least* views
> primary key timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
