[
https://issues.apache.org/jira/browse/CASSANDRA-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14737560#comment-14737560
]
Tyler Hobbs commented on CASSANDRA-10226:
-----------------------------------------
It seems like when we include multiple non-PK columns in the view PK, we
fundamentally have to accept that the view row's existence depends on multiple
timestamps. I propose that we solve this by using a set of timestamps for the
row's LivenessInfo. In the example above, this set would include the
timestamps for {{c}} and {{d}}.
Regular tombstones (for base row deletions) would delete a view row if _any_
timestamp in the set is lower than the tombstone's timestamp. Essentially, the
deletion of any cell in the base row (that corresponds to the view row's PK)
should result in the view row being deleted.
The special behavior is that weak tombstones (used for view cleanup only) would
only delete a view row if _all_ timestamps in the set are lower. In the
example above, the row would be re-inserted with a timestamp set of {{\{2,
0\}}}, so the weak tombstone with a timestamp of 1 would not shadow it.
There's also the question of whether the base row's PK timestamp should be
included in the timestamp set. I believe the answer is that it only needs to
be included when there are no non-PK columns in the view's PK, but I need to
confirm that more rigorously.
> Support multiple non-PK cols in MV clustering key when partition key is shared
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-10226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10226
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Tyler Hobbs
> Labels: materializedviews
> Fix For: 3.0.0 rc1
>
>
> This issue is similar to CASSANDRA-9928, but with one key limitation: the MV
> partition key must match the base table's partition key. This limitation
> results in the base replica always pairing with itself as the MV replica.
> Because of this pairing, if the base replica is lost, any MV rows that would
> otherwise be ambiguous are also lost. This allows us to avoid the problem
> described in 9928 of not knowing which MV row to delete.
> Although this limitation has the potential to be a bit confusing for users, I
> believe this improvement is still worthwhile because:
> * The base table's partition key will often be a good choice for the MV
> partition key as well. I expect it to be common for users to partition data
> the same way, but use a different clustering order to optimize for (or allow
> for) different queries.
> * It may take a long time to solve the problems presented in 9928 in general
> (if we can solve them at all). On the other hand, this is straightforward
> and is a significant improvement to the usability of MVs.
> I have a minimal prototype of this that works well, so I should be able to
> upload a patch with thorough tests within the next few days.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
