cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10226) Support multiple non-PK cols in MV clustering key when partition key is shared
Date Thu, 10 Sep 2015 12:37:46 GMT


T Jake Luciani commented on CASSANDRA-10226:

bq. 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 your example you have a weak (shadowable) tombstone added at ts=0 then re-add a pk timestamp
of {2, 0}.  The problem is if you need to add another weak tombstone because c is set to null
again you will add another weak tombstone at ts=0 (since it's the min timestamp of the PK)

 If you put the list in the Row.Deletion as well then you can apply the rule to exclude based
on each component (regular tombstone if any tombstone ts is > liveness  offset) vs (shadowable
if all ts are > liveness offsets)  

> Support multiple non-PK cols in MV clustering key when partition key is shared
> ------------------------------------------------------------------------------
>                 Key: CASSANDRA-10226
>                 URL:
>             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

View raw message